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

[Lijun Liao <[e-mail]>]

Hi Daniel,

Thank you for your reply.

I think the definition of "CA" is clearly to be an entity which issues certificates. See below:

------
I am with Santosh.

As the definition of RFC 5280 Section 5:

"   CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
   that has been authorized by the CA to issue CRLs.  CAs publish CRLs
   to provide status information about the certificates they issued.
   However, a CA may delegate this responsibility to another trusted
   authority.
"

If a CA only issues CRL, then
"CAs publish CRLs
   to provide status information about the --certificates they issued---."
conflicts itself.

Lijun
________________________________________

-----Original Message-----
From: Daniel Migault [mailto:[e-mail]] 
Sent: 2019年4月17日 16:42
To: Santosh Chokhani <[e-mail]>; 'Russ Housley' <[e-mail]>
Cc: 'RFC Editor' <[e-mail]>; 'Roman D. Danyliw' <[e-mail]>; 'Simon Josefsson' <[e-mail]>; 'Rich Salz' <[e-mail]>; 'Jim Schaad' <[e-mail]>; [e-mail]; Lijun Liao <[e-mail]>; 'Ben Kaduk' <[e-mail]>
Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696)

Hi, 

Thank you Lijun Liao for the comment and taking the time to improve our documents. 

I believe the confusion is that certificate authority are not restricted to emit certificate with KeyCertSign usage and cA constraint. For example, they could emit a certificate that is used *only* to validate CRLs. This certificate will have the keyUsage set to cRLSign. nonRepudiation, digitalSignature, cRLSign would not be selected as it indicates the key could be used for other purposes. Other combinations using may consider one or a combination of keyUsage KeyCertSign. nonRepudiation, digitalSignature, cRLSign.

If my understanding is correct, mandating KeyCertSign is not correct and the current text catches all possibilities. The text could have explicitly mentioned that certificate may emit certificate that are only restricted to the validation of certificate signature. However, I am not sure that would clarify the purpose of the document nor justify an errata. Thus, I am wondering if we can agree the issue has been solved and close the request for errata.

Yours, 
Daniel 


 



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

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