Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

[Dmitry Belyavsky <[e-mail]>]

Hello,

I've just uploaded the new version of my draft.

The main difference from the previous one is more or less described syntax
of
specific limitations mentioned in text.

The answers on the question raised by Nikos are below.

=================
A new version of I-D, draft-belyavskiy-certificate-limitation-policy-05.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:           draft-belyavskiy-certificate-limitation-policy
Revision:       05
Title:          Certificate Limitation Policy
Document date:  2017-11-25
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-belyavskiy-
certificate-limitation-policy-05.txt
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-
certificate-limitation-policy/
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-certificate-
limitation-policy-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-belyavskiy-
certificate-limitation-policy-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-
certificate-limitation-policy-05

Abstract:
   The document provides a specification of the application-level trust
   model.  Being provided at the application level, the limitations of
   trust can be distributed separately using cryptographically protected
   format instead of hardcoding the checks into the application itself.
==================

On Thu, Oct 12, 2017 at 3:03 PM, Nikos Mavrogiannopoulos via
dev-security-policy <[e-mail]> wrote:

> On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <[e-mail]>
> wrote:
> > Dear Nicos,
> >
> > Sorry for the delay with my response.
> >
> > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <
> [e-mail]>
> > wrote:
> >>
> >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <[e-mail]>
> >> wrote:
> >>
> >
> > Well, the specification I suggest should allow applying CLPs issued by
> major
> > vendors (Mozilla etc).
> > For this purposes the CLPs should be validable => signed.
>
> Hi,
>  If mozilla or any other organization is willing to deploy such PKI,
> that would be great. However for the majority of software, I'd expect
> that such files are distributed using the same channel as software,
> and thus using the same authentication mechanism for it rather than a
> new PKI. For a software distributor to use that optional signing could
> work.
>

I got your point. I'll think about allowing local CLPs to be unsigned.


>
> >> One problem with that is the fact that the existing CRL extensions are
> >> about extending attributes of the CRL, rather than adding/removing
> >> attributes to the certificate in question.
> > For this purposes I implied that the limitations are provided not by
> > extensions,
> > but as SEQUENCE of limitations related to the certificates.
> >
> > Was I wrong in the ASN1 scheme in the current version of my draft?
>
> I do not think that the presented ASN.1 description is valid.
> The "limitations          SEQUENCE," doesn't define anything in ASN.1
> (i..e, it is a sequence of what?).
>

I (hopefully) clarified the ASN.1 description in the new version.


>
> >>
> >> To bring the stapled extensions to your proposal, you'd need the
> >> Extensions and Extension fields from RFC5280, and
> >> add into limitedCertificates structure (I'll split it on the example
> >> below for clarity) the following field.
> >>
> >> LimitedCertificates  ::=   SEQUENCE OF LimitedCertificate
> >>
> >> LimitedCertificate ::= SEQUENCE {
> >>                 userCertificate         CertificateSerialNumber,
> >>                 certificateIssuer       Name,
> >>                 limitationDate          Time,
> >>                 limitationPropagation   Enum,
> >>                 fingerprint SEQUENCE {
> >>                     fingerprintAlgorithm AlgorithmIdentifier,
> >>                     fingerprintValue     OCTET STRING
> >>                                      } OPTIONAL,
> >>                 limitations          SEQUENCE,
> >>                                    } OPTIONAL,
> >>                                  };
> >>
> >>
> >>                 stapledExtensions Extensions; <----- NEW
> >> }
> >
> >
> > Sorry, I do not get the difference between the purposes of the field
> > 'limitations'
> > and 'stapledExtensions'.
>
> I cannot answer this as I cannot see the syntax of the limitations
> field. I thought it was a field intended to spark discussion rather
> than anything specific.
>

Now, when the syntax is provided, I hope it's specific enough to continue
the discussion.

-- 
SY, Dmitry Belyavsky