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

[Tim Hollebeek <[e-mail]>]

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

> -----Original Message-----
> From: Curdle <[e-mail]> On Behalf Of Jim Schaad
> Sent: Wednesday, April 17, 2019 3:48 PM
> To: 'Lijun Liao' <[e-mail]>; 'Daniel Migault'
> <[e-mail]>; 'Santosh Chokhani'
> <[e-mail]>; 'Russ Housley' <[e-mail]>
> Cc: 'Roman D. Danyliw' <[e-mail]>; 'Simon Josefsson'
> <[e-mail]>; [e-mail]; 'Rich Salz' <[e-mail]>;
> 'Ben Kaduk' <[e-mail]>; 'RFC Editor' <[e-mail]>
> Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (5696)
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Lijun Liao <[e-mail]>
> > Sent: Wednesday, April 17, 2019 7:53 AM
> > To: Daniel Migault <[e-mail]>; 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]; 'Ben Kaduk' <[e-mail]>
> > Subject: RE: [Curdle] [Technical Errata Reported] RFC8410 (5696)
> >
> > 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
> >
> 
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle