RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (2)

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Source of RFC: curdle (sec)

Errata ID: 5696
Status: Reported
Type: Technical

Reported By: Lijun Liao
Date Reported: 2019-04-17

Section 5 says:

   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.

It should say:

   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.

Errata ID: 5707
Status: Reported
Type: Editorial

Reported By: Lijun Liao
Date Reported: 2019-04-29
Edited by: Benjamin Kaduk
Date Edited: 2019-05-06

Section 10.2 says:

-

It should say:

-

Notes:

In the example certificate, the critical-field of extensions keyUsage and subjectKeyIdentifier are of default value 'false'. They should not be included according to DER encoding rule.

Status: Held for Document Update (1)

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Source of RFC: curdle (sec)

Errata ID: 5459
Status: Held for Document Update
Type: Editorial

Reported By: Conrado Gouvea
Date Reported: 2018-08-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-08-13

Section 7 says:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY------

It should say:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY-----

Notes:

Should be five dashes instead of six, at the end

Status: Rejected (1)

RFC 8410, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", August 2018

Source of RFC: curdle (sec)

Errata ID: 5709
Status: Rejected
Type: Editorial

Reported By: Lijun Liao
Date Reported: 2019-04-29
Rejected by: Benjamin Kaduk
Date Rejected: 2019-05-06

Section 10.2 says:

-

It should say:

-

Notes:

The example certificate is a self-signed certificate containing X25519 public key. Unlike standard EC public key, the public key for key exchange is NOT the same as the one for digital signature in curve25519. That means, for the same private key, the public keys for X25519 and for Ed25519 are different. As a result, the public key in the self-signed certificate can NOT be used to verify the signature. In this context, please replace the example certificate by one containing the Ed25519 public key.
--VERIFIER NOTES--
X25519 keys are only capable of key agreement, not signing, so by necessity a self-issued X25519 certificate cannot be self-signed. This document specifies, among other things, how to encode X25519 public keys into X.509 certificates, and so the example is accordingly a self-issued but not self-signed certificate. The issuing certificate has the same subject name but a different key (and key type).

Report New Errata