RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

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

Reported By: Timothy J. Miller
Date Reported: 2013-04-03
Verifier Name: Sean Turner
Date Verified: 2013-04-05

Section 4.2.1.4 says:

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

It should say:

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

Notes:

ASN.1 type references must begin with an upper case character. Schema in A.2 is correct.

Status: Reported (4)

RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

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

Reported By: Sandra Murphy
Date Reported: 2014-05-13

Section 4.1.1.3 says:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.  This
   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

It should say:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function. The 
   output of the signature function is encoded as a BIT STRING and 
   included in the signatureValue field.  The details of this process 
   are specified for each of the algorithms listed in [RFC3279], 
   [RFC4055], and [RFC4491].

Notes:

The "included in the signature field" should have been "included in the signatureValue field". A field called "signature" does exist in the 5280 structure, but it is not intended to hold the value of the result of the signature function. The sentence was reworded for word flow (and to avoid using "signature value" and "signatureValue" in the same sentence).

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

Reported By: Nikos Mavrogiannopoulos
Date Reported: 2019-08-06

Section 4.2.1.12 says:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

It should say:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

Notes:

The proposed change removes the WWW part of the description. In practice these object identifiers are used for server and client applications, but not necessarily web applications. In particular:
- openssl verification considers them unconditionally even if the server is not a web server or the client a web client
- There is no object identifier that can be used for protocols like SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed with the identifiers for WWW
- Standards like common criteria assume that these object identifiers are for generic server and clients [0].

[0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1

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

Reported By: Yuting Chen
Date Reported: 2019-12-15

Section 6.1 says:

The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on the public key of the trust anchor. In most cases, the target

It should say:

  The primary goal of path validation is to verify the binding between
| a subject distinguished name and/or a subject alternative name and
  subject public key, as represented in the target certificate, based
  on the public key of the trust anchor. In most cases, the target

Notes:

The correction conforms to the first paragraph, Sec. 6, "Certification
path processing verifies the binding between the subject distinguished
name and/or subject alternative name and subject public key."

In addition, it is not very clear in RFC 5280, given a certificate with
a non-empty subject DN and an SAN extension instance (critical or
non-critical), which one (the subject DN, the SAN extension, or they
both) should be bound to the subject public key during path validation.
More explanations are needed.

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

Reported By: Rob Stradling
Date Reported: 2021-01-28

Section 4.2.1.12 says:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

It should say:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or (keyEncipherment or keyAgreement)

Notes:

In https://github.com/zmap/zlint/issues/553 there's been some disagreement and confusion about how to correctly interpret the "or" in the Original Text. "You can only set one of these three bits" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.

However, digitalSignature+keyEncipherment makes sense for an RSA leaf certificate, and digitalSignature+keyAgreement makes sense for an ECC leaf certificate. Both are widely used, to enable ephemeral and non-ephemeral TLS ciphersuites in conjunction with a single server certificate.

Given that RFC5480 section 3 explicitly permits digitalSignature+keyAgreement in an ECC leaf certificate, I think it's likely that my proposed Corrected Text conveys the RFC5280 authors' intended meaning.

Report New Errata