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

[Jim Schaad <[e-mail]>]

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
>