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

From: RFC Errata System <[email-masked]>
Date: Wed, 17 Apr 2019 06:03:22 -0700 (PDT)

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 <[email-masked]>

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Apr 2019 09:12:19 -0400

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 <[email-masked]> wrote:
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 17 Apr 2019 09:26:47 -0400

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:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, April 17, 2019 9:12 AM
To: RFC Editor <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Simon Josefsson <[email-masked]>;
[email-masked]; Rich Salz <[email-masked]>; Jim Schaad
<[email-masked]>; [email-masked]; [email-masked]; Ben Kaduk
<[email-masked]>
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

> 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".
> 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.
> 
> Title               : Algorithm Identifiers for Ed25519, Ed448, X25519,
and X448 for Use in the Internet X.509 Public Key Infrastructure

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Apr 2019 09:37:59 -0400

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 <[email-masked]> wrote:
> 
> Russ,
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 17 Apr 2019 09:53:42 -0400

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:[email-masked]] 
Sent: Wednesday, April 17, 2019 9:38 AM
To: Santosh Chokhani <[email-masked]>
Cc: RFC Editor <[email-masked]>; Roman D. Danyliw <[email-masked]>;
Simon Josefsson <[email-masked]>; [email-masked]; Rich
Salz <[email-masked]>; Jim Schaad <[email-masked]>;
[email-masked]; [email-masked]; Ben Kaduk <[email-masked]>
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

> 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.
> 
> Cc: Roman D. Danyliw <[email-masked]>; Simon Josefsson 
> <[email-masked]>; [email-masked]; Rich Salz 
> <[email-masked]>; Jim Schaad <[email-masked]>; 
> [email-masked]; [email-masked]; Ben Kaduk <[email-masked]>
> 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 
>> <[email-masked]>
> wrote:
>> 
>> "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use 
>> in the Internet

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Apr 2019 14:41:35 +0000

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 <[email-masked]> 
Sent: Wednesday, April 17, 2019 9:54 AM
To: 'Russ Housley' <[email-masked]>
Cc: 'RFC Editor' <[email-masked]>; 'Roman D. Danyliw' <[email-masked]>; 'Simon Josefsson' <[email-masked]>; Daniel Migault <[email-masked]>; 'Rich Salz' <[email-masked]>; 'Jim Schaad' <[email-masked]>; [email-masked]; [email-masked]' <[email-masked]>; 'Ben Kaduk' <[email-masked]>
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:[email-masked]]
Sent: Wednesday, April 17, 2019 9:38 AM
To: Santosh Chokhani <[email-masked]>
Cc: RFC Editor <[email-masked]>; Roman D. Danyliw <[email-masked]>; Simon Josefsson <[email-masked]>; [email-masked]; Rich Salz <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; Ben Kaduk <[email-masked]>
Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)

Santosh:

Russ

> On Apr 17, 2019, at 9:26 AM, Santosh Chokhani 
> <[email-masked]>

---

From: Lijun Liao <[email-masked]>
Date: Wed, 17 Apr 2019 13:41:34 +0000

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
________________________________________
From: Russ Housley [[email-masked]]
Sent: Wednesday, April 17, 2019 1:37 PM
To: Santosh Chokhani
Cc: RFC Editor; Roman D. Danyliw; Simon Josefsson; [email-masked]; Rich Salz; Jim Schaad; [email-masked]; Lijun Liao; Ben Kaduk
Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)

Santosh:

Russ

---

From: Lijun Liao <[email-masked]>
Date: Wed, 17 Apr 2019 14:53:11 +0000

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.

Lijun

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

Hi, 

Yours, 
Daniel 

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

Santosh:

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 17 Apr 2019 15:47:54 -0700

When I look at this problem I see two cases where not setting the bit makes
sense to me.

1.  A CA certificate which is only intended to be a trust anchor may not
have the bit set because the bit would not be checked in some
implementations so it would not make any difference.

2.  I need to know how you define what a CA is:  If you say that a CA is
identified based only on a Public Key then what is said below makes a degree
of sense.  However, if you say that a CA is identified based on its name
rather than on its key you end up with some other cases where a CA could
have a certificate issued to itself.  A) It uses a separate certificate for
issuing of CRLs so that this can be done online while the certificate
signing needs to be done off-line.  B) It uses a separate certificate for
the purpose of running one of the various enrollment protocols.  In both of
these cases a certificate has been issued to the CA, but that certificate is
not used for the purpose of creating certificates and thus setting a bit to
that effect is incorrect.   I come down in the school that the CA is an
entity based on it's name and not on it's public key.  Rolling over a public
key does not change the fact that it is the same CA.

For both of these reasons I do not believe that the errata is correct.

Jim

> From: Lijun Liao <[email-masked]>
> Sent: Wednesday, April 17, 2019 7:53 AM
> To: Daniel Migault <[email-masked]>; Santosh Chokhani
> <[email-masked]>; 'Russ Housley' <[email-masked]>
> Cc: 'RFC Editor' <[email-masked]>; 'Roman D. Danyliw'
> <[email-masked]>; 'Simon Josefsson' <[email-masked]>; 'Rich Salz'
> <[email-masked]>; 'Jim Schaad' <[email-masked]>;
> [email-masked]; 'Ben Kaduk' <[email-masked]>
> Cc: 'RFC Editor' <[email-masked]>; 'Roman D. Danyliw'
> <[email-masked]>; 'Simon Josefsson' <[email-masked]>; 'Rich Salz'
> <[email-masked]>; 'Jim Schaad' <[email-masked]>;
> [email-masked]; Lijun Liao <[email-masked]>; 'Ben Kaduk'
> <[email-masked]>
> 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
> 
> 
> 
> 
> 
> 
> Cc: 'RFC Editor' <[email-masked]>; 'Roman D. Danyliw'
> <[email-masked]>; 'Simon Josefsson' <[email-masked]>; Daniel Migault
> <[email-masked]>; 'Rich Salz' <[email-masked]>; 'Jim
Schaad'
> <[email-masked]>; [email-masked]; [email-masked]'
> <[email-masked]>; 'Ben Kaduk' <[email-masked]>
seen
> an implementation where a CA does not generate a CRL and does not
not
> issue a CRL.
> Cc: RFC Editor <[email-masked]>; Roman D. Danyliw
> <[email-masked]>; Simon Josefsson <[email-masked]>;
> <[email-masked]>; [email-masked]; [email-masked]; Ben
> Kaduk <[email-masked]>

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 24 Apr 2019 17:42:28 +0000

I agree with Jim's analysis.

Regrettably, it is not explicitly clear what a "certification authority
certificate" is, and as Jim notes, there is a reasonable reading where these
certificates may not be trust anchors.  This is the most reasonable reading
to me, and matches existing practice.

Even if the certificate is a trust anchor, one needs to be very careful
about making explicit requirements about EKUs, as different implementations
handle them in many different ways, and trust anchors often need to be able
to interoperate with a wide variety of systems.

My reading of this errata is that it is requesting a requirements change,
and an errata is not the appropriate method to accomplish that.  If someone
desires such a requirement, it needs to be carefully considered and
analyzed.  But there isn't an error in the current document that requires
correction.

-Tim

> From: Curdle <[email-masked]> On Behalf Of Jim Schaad
> Sent: Wednesday, April 17, 2019 3:48 PM
> To: 'Lijun Liao' <[email-masked]>; 'Daniel Migault'
> <[email-masked]>; 'Santosh Chokhani'
> Cc: 'Roman D. Danyliw' <[email-masked]>; 'Simon Josefsson'
> <[email-masked]>; [email-masked]; 'Rich Salz' <[email-masked]>;
> 'Ben Kaduk' <[email-masked]>; 'RFC Editor' <[email-masked]>
have
> the bit set because the bit would not be checked in some implementations
so
> it would not make any difference.
> 
rather
> than on its key you end up with some other cases where a CA could have a
> certificate issued to itself.  A) It uses a separate certificate for
issuing of CRLs
> so that this can be done online while the certificate signing needs to be
done
> off-line.  B) It uses a separate certificate for the purpose of running
one of the
> various enrollment protocols.  In both of these cases a certificate has
been
> issued to the CA, but that certificate is not used for the purpose of
creating
> certificates and thus setting a bit to
> entity based on it's name and not on it's public key.  Rolling over a
public key
> does not change the fact that it is the same CA.
> 
> > 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.
> > <[email-masked]>; 'Simon Josefsson' <[email-masked]>; Daniel
> > Migault <[email-masked]>; 'Rich Salz' <[email-masked]>;
> > 'Jim
> Schaad'
> > RFC 3279.  If this has confused any implementer over the last decade
> > and a half, I have not heard about it.
> >
> > Russ
> >
> >
> > > 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
> > >
> > >
> > >> 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
> > >> --------------
> > >> 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
> > >> -----
> > >> 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.
> > >>