Re: [lamps] draft-ietf-lamps-8410-ku-clarifications: EE/CRLIssuer Text

[Tadahiko Ito <[e-mail]>]

Hi

As far as I understand, CA certificate and EE certificate are exclusive,
but CRL issuer certificate and EE certificate are not exclusive.
RFC5280 seems to allow CRL issuer certificate be EE certificate in same
time.

So, dividing EE cert, and CRL issuer cert may be confusing.
(well,, we can divide like non-CRLissuer-EE and CRLissuer-EE, but then
people may confuse that if there has been any change on use of KU flags.
Our only change is key encipherment and data encipherment.  so for me, it
is better to write simple, and let people find change easier)

Instead, how about something like following change?
(Erasing description of CRL issuer certificate from first part, and write
as note on the bottom)

----OLD---
If the keyUsage extension is present in an end-entity or CRL issuer
certificate that indicates id-Ed25519 or id-Ed448 in
SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
least one of the following:
     nonRepudiation;
     digitalSignature; and
     cRLSign;

and the following MUST NOT be present:
     keyEncipherment;
     dataEncipherment;
     keyAgreement;
     keyCertSign;
     encipherOnly; and
     decipherOnly.



----NEW---



If the keyUsage extension is present in an end-entity
certificate that indicates id-Ed25519 or id-Ed448 in
SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
least one of the following:


     nonRepudiation;
     digitalSignature; and
     cRLSign;

and the following MUST NOT be present:
     keyEncipherment;
     dataEncipherment;
     keyAgreement;
     keyCertSign;
     encipherOnly; and
     decipherOnly.

Note that EE certificate for CRL issuer can have cRLSign and possibly some
other key usage bits (e.g., indirect CRL described in section 5 of
RFC5280).

--------------

Regards Tadahiko

2022年6月4日(土) 3:25 Jonathan Hammell <[e-mail]>:

> Hi Sean,
> I agree with separating the cases of end-entity certificates and CRL
> issuer certificates.  However, the cRLSign bit should always be set in
> the KeyUsage extension of a CRL issuer certificate.  I believe this is
> implied in the following text of RFC 5280:
>
>    If the keyUsage extension is present, then the subject public key
>    MUST NOT be used to verify signatures on certificates or CRLs unless
>    the corresponding keyCertSign or cRLSign bit is set.
>
> Therefore, aligning with the text for certification authority
> certificates, the following might be more clear for the CRL issuer
> case:
>
> If the keyUsage extension is present in a CRL issuer certificate that
> indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the
> keyUsage extension MUST contain:
>
>   cRLSign;
>
> and zero or more of the following:
>
>   nonRepudiation;
>   digitalSignature; and
>   keyCertSign;
>
> and the following MUST NOT be present:
>
>   keyEncipherment;
>   dataEncipherment;
>   keyAgreement;
>   encipherOnly; and
>   decipherOnly.
>
> ...
>
> Note that this allows keyCertSign for CRL issuer certificates, which
> seems to be implied by the certification authority certificate text in
> the I-D allowing cRLSign.
>
> Best regards,
> Jonathan
>
> On Thu, Jun 2, 2022 at 9:06 AM Sean Turner <[e-mail]> wrote:
> >
> > Hi! During IESG review we got comments from a couple of couple of ADs
> (3) about EE/CRL issue text (note this is NOT a DISCUSS but if we tripped
> up 3 then it’s probably worth having a look at):
> >
> >    If the keyUsage extension is present in an end-entity or CRL issuer
> >    certificate that indicates id-Ed25519 or id-Ed448 in
> >    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
> >    least one of the following:
> >
> >      nonRepudiation;
> >      digitalSignature; and
> >      cRLSign;
> >
> > and the following MUST NOT be present:
> >
> >      keyEncipherment;
> >      dataEncipherment;
> >      keyAgreement;
> >      keyCertSign;
> >      encipherOnly; and
> >      decipherOnly.
> >
> > One way to fix this is to make the following changes to separate out the
> EE and CRL issuer:
> >
> >    If the keyUsage extension is present in an end-entity
> >    certificate that indicates id-Ed25519 or id-Ed448 in
> >    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
> >    least one of the following:
> >
> >      nonRepudiation; and
> >      digitalSignature;
> >
> > and the following MUST NOT be present:
> >
> >      keyEncipherment;
> >      dataEncipherment;
> >      keyAgreement;
> >      keyCertSign;
> >      encipherOnly; and
> >      decipherOnly.
> > ….
> >
> > Also ADD:
> >
> >    If the keyUsage extension is present in an CRL issuer
> >    certificate that indicates id-Ed25519 or id-Ed448 in
> >    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
> >    least one of the following:
> >
> >      nonRepudiation;
> >      digitalSignature; and
> >      cRLSign;
> >
> > and the following MUST NOT be present:
> >
> >      keyEncipherment;
> >      dataEncipherment;
> >      keyAgreement;
> >      keyCertSign;
> >      encipherOnly; and
> >      decipherOnly.
> >
> > Open to other suggestions as well.
> >
> > Cheers,
> > spt
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>