Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)

["Santosh Chokhani" <[e-mail]>]

Agree Russ in the sense that I have never seen a CA not issue CRL also.  It
might delegate CRL issuance to other authorities as well, but I have not
seen an implementation where a CA does not generate a CRL and does not
provide it to at least one RP, be it OCSP Responder.

But if these folks are implementing a CA without CRL issuance, they might
want this.  

On the other hand, I do not see CA having all these other bits as well.
There is no security issue if the CA has CRL issuance bit even if it does
not issue a CRL.

So, I could go either way on this Errata since it does not move the security
needle for me.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, April 17, 2019 9:38 AM
To: Santosh Chokhani <[e-mail]>
Cc: RFC Editor <[e-mail]>; Roman D. Danyliw <[e-mail]>;
Simon Josefsson <[e-mail]>; [e-mail]; Rich
Salz <[e-mail]>; Jim Schaad <[e-mail]>;
[e-mail]; [e-mail]; Ben Kaduk <[e-mail]>
Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)

Santosh:

This is the exact way we have described the appropriate key usage bits since
RFC 3279.  If this has confused any implementer over the last decade and a
half, I have not heard about it.

Russ


> On Apr 17, 2019, at 9:26 AM, Santosh Chokhani <[e-mail]>
wrote:
> 
> Russ,
> 
> But if the CA is using a key to sign CRL, in the context of that key 
> it is not a CA personality but a CRL issuer personality.
> 
> -----Original Message-----
> From: Curdle [mailto:[e-mail]] On Behalf Of Russ 
> Housley
> Sent: Wednesday, April 17, 2019 9:12 AM
> To: RFC Editor <[e-mail]>
> Cc: Roman D. Danyliw <[e-mail]>; Simon Josefsson 
> <[e-mail]>; [e-mail]; Rich Salz 
> <[e-mail]>; Jim Schaad <[e-mail]>; 
> [e-mail]; [e-mail]; Ben Kaduk <[e-mail]>
> Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)
> 
> I do not think this is correct.  A CA could, for example, use one key 
> for signing certificates and a separate key for signing CRLs.
> 
> Russ
> 
> 
>> On Apr 17, 2019, at 9:03 AM, RFC Errata System 
>> <[e-mail]>
> wrote:
>> 
>> The following errata report has been submitted for RFC8410, 
>> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use 
>> in the Internet
> X.509 Public Key Infrastructure".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5696
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Lijun Liao <[e-mail]>
>> 
>> Section: 5
>> 
>> Original Text
>> -------------
>>  If the keyUsage extension is present in a certification authority  
>> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage  
>> extension MUST contain one or more of the following values:
>> 
>>         nonRepudiation;
>>         digitalSignature;
>>         keyCertSign; and
>>         cRLSign.
>> 
>> Corrected Text
>> --------------
>>  If the keyUsage extension is present in a certification authority  
>> certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage  
>> extension MUST contain keyCertSign, and zero, one or more of the  
>> following values:
>> 
>>         nonRepudiation;
>>         digitalSignature; and
>>         cRLSign.
>> 
>> Notes
>> -----
>> The usage keyCertSign must be set in a CA certificate.
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please 
>> use "Reply All" to discuss whether it should be verified or rejected.
>> When a decision is reached, the verifying party can log in to change 
>> the status and edit the report, if necessary.
>> 
>> --------------------------------------
>> RFC8410 (draft-ietf-curdle-pkix-10)
>> --------------------------------------
>> Title               : Algorithm Identifiers for Ed25519, Ed448, X25519,
> and X448 for Use in the Internet X.509 Public Key Infrastructure
>> Publication Date    : August 2018
>> Author(s)           : S. Josefsson, J. Schaad
>> Category            : PROPOSED STANDARD
>> Source              : CURves, Deprecating and a Little more Encryption
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>> 
>> _______________________________________________
>> Curdle mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/curdle
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle