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

[Sean Turner <[e-mail]>]

I will run the options by the IESG. I also thought of another option that merges the two to be slightly more specific in the CRL issuer text to address where the CRL issuer is an EE or CA:

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; and
  digitalSignature;

and the following MUST NOT be present:

  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  encipherOnly; and
  decipherOnly;

and if the CRL issuer is also a certification authority, then the
keyUsage extension MUST also contain:

   keyCertSign.

spt


> On Jun 6, 2022, at 11:42, Tadahiko Ito <[e-mail]> wrote:
> 
> 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