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

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 [housley@vigilsec.com]
Sent: Wednesday, April 17, 2019 1:37 PM
To: Santosh Chokhani
Cc: RFC Editor; Roman D. Danyliw; Simon Josefsson; daniel.migault@ericsson.com; Rich Salz; Jim Schaad; curdle@ietf.org; Lijun Liao; Ben Kaduk
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 <santosh.chokhani@gmail.com> 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:curdle-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Wednesday, April 17, 2019 9:12 AM
> To: RFC Editor <rfc-editor@rfc-editor.org>
> Cc: Roman D. Danyliw <rdd@cert.org>; Simon Josefsson <simon@josefsson.org>;
> daniel.migault@ericsson.com; Rich Salz <rsalz@akamai.com>; Jim Schaad
> <ietf@augustcellars.com>; curdle@ietf.org; LIJUN.LIAO@huawei.com; Ben Kaduk
> <kaduk@mit.edu>
> 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 <rfc-editor@rfc-editor.org>
> 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 <LIJUN.LIAO@HUAWEI.COM>
>>
>> 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
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle