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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <[e-mail]> wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <[e-mail]>
> wrote:
>>
>>
>> 4. How do you handle extensions to this format?
>>
>> Overall, why not use X.509 extensions to store such additional
>> constraints? We already (in the p11-kit trust store in Fedora/RHEL
>> systems) use the notion of stapled extensions to limit certificates
>> [0, 1] and seems quite a flexible approach. Have you considered that
>> path?
>>
>> regards,
>> Nikos
>>
>> [0].
>> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html
>> [1].
>> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html
> I've looked through the specification. It's OK for me, but I do not get
> whether the attached extensions are crypto-protected.

No, as these values are inserted by the administrator of the system,
or us (the distributor of the software), we didn't feel we needed the
introduction of additional PKI.

How do you see the infrastructure on the
draft-belyavskiy-certificate-limitation-policy? Who do you envision
signing these structures? (I assume that distribution of data will be
done by software distributors?)

>> 4. How do you handle extensions to this format?
>>
> Simillary to CRL. Do you have ideas of the extensions?

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.

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
}


Another difference between this profile and the p11-kit one, is that
the extensions/revocation here is done on the certificate, while in
p11-kit is done on the public key. Both approaches have pros and cons.

Another question. I also noticed the fingerprint field above. Is that
to distinguish between same CAs with different keys? In that case
using the SubjectPublicKeyIdentifier may be sufficient, and more
natural as this is how certificates with matching DNs/serials are
distinguished.

regards,
Nikos