RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (3)

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

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 6263
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: David Ireland
Date Reported: 2020-08-24
Verifier Name: Deb Cooley
Date Verified: 2024-10-30

Section 7 says:

NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in [RFC7748].

It should say:

NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in [RFC5958].

Notes:

RFC7748 does not define or even mention OneAsymmetricKey. The correct reference should be RFC5958 "Asymmetric Key Packages"

Errata ID: 7384
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Russ Housley
Date Reported: 2023-03-12
Verifier Name: Deb Cooley
Date Verified: 2024-04-11

Section 9 says:

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

It should say:

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

   sa-Ed448 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-Ed448
       PARAMS ARE absent
       PUBLIC-KEYS {pk-Ed448}
       SMIME-CAPS { IDENTIFIED BY id-Ed448 }
   }

   pk-Ed448 PUBLIC-KEY ::= {
       IDENTIFIER id-Ed448
       -- KEY no ASN.1 wrapping --
       PARAMS ARE absent
       CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                       keyCertSign, cRLSign}
       PRIVATE-KEY CurvePrivateKey
   }

Notes:

The definitions for sa-Ed448 and pk-Ed448 are missing from RFC 8410.

Errata ID: 6738
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Daniel Minder
Date Reported: 2021-11-16
Verifier Name: Benjamin Kaduk
Date Verified: 2021-12-03

Section 7 says:

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] IMPLICIT Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
      ...
   }

It should say:

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] PublicKey OPTIONAL ]],
      ...
   }

Notes:

This is an incorrect quote from RFC 5958.

Status: Reported (3)

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

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 6229
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: David von Oheimb
Date Reported: 2020-07-12

Section 10.2 says:

An example of a self-issued PKIX certificate using Ed25519 to sign an
X25519 public key would be

Notes:

The given example certificate is self-issued but not self-signed (which is fine because its public key cannot be used for signing).
It includes a subjectKeyIdentifier but not an authorityKeyIdentifier.

For not self-signed certificates RFC 5280 requires in section 4.2.1.1 (https://tools.ietf.org/html/rfc5280#section-4.2.1.1) that the authorityKeyIdentifier is present.

Thus for such an example certificate the authorityKeyIdentifier MUST be added in order to be a conforming certificate.
Otherwise, cert chain validation will be mislead to assume that the certificate is self-signed (while usually not actually verifying this supposition).

Errata ID: 6936
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ryan Culpepper
Date Reported: 2022-04-16

Section 10.2 says:

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

It should say:

(re-encode certificate)

Notes:

The example certificate violates RFC 5280. Specifically, the
certificate contains a BasicConstraints extension that explicitly
encodes the cA field with a value of FALSE, but that is the default
value of the cA field, and the Extension extnValue is required to be
encoded using DER, which forbids including a field set to its default
value.

In addition, the PEM-encoded certificate violates RFC 7468, which
requires lines to be wrapped to 64 characters, but the example is
wrapped to 66-character lines.

Errata ID: 7070
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alex Gaynor
Date Reported: 2022-08-02

Section 10.2 says:

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

It should say:

A corrected encoding of the certificate.

Notes:

In addition to the mis-encoding described in 6936, there are additional misencodings. The critical field of X.509 extensions have `DEFAULT FALSE` (per RFC 5280). Default field values shall not be encoded in a DER sequence, but in the certificate encoding presented there these critical fields are encoded.

Status: Held for Document Update (4)

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

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 5696
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Lijun Liao
Date Reported: 2019-04-17
Held for Document Update by: Roman Danyliw
Date Held: 2022-04-25

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: 7848
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Corey Bonnell
Date Reported: 2024-03-12
Held for Document Update by: Deb Cooley
Date Held: 2024-04-11

Section 6 says:

Certificate  ::=  SEQUENCE  {
           tbsCertificate       TBSCertificate,
           signatureAlgorithm   AlgorithmIdentifier,
           signatureValue       BIT STRING  }

...


For the Certificate structure, the signature value is
   wrapped in the "signatureValue" BIT STRING field.

It should say:

Certificate  ::=  SEQUENCE  {
           tbsCertificate       TBSCertificate,
           signatureAlgorithm   AlgorithmIdentifier,
           signature            BIT STRING  }

...

For the Certificate structure, the signature value is
   wrapped in the "signature" BIT STRING field.

Notes:

There is no field with the name "signatureValue" in the Certificate SEQUENCE. It is instead named "signature" according to the ASN.1 module in RFC 5280 A.1 as well as the ASN.1 module in section 14 of RFC 5912.

Errata ID: 5459
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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

Errata ID: 5707
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Lijun Liao
Date Reported: 2019-04-29
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-05-25

Section 10.2 says:


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: Rejected (1)

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

Note: This RFC has been updated by RFC 9295

Source of RFC: curdle (sec)

Errata ID: 5709
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

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



Advanced Search