RFC Errata
Found 10 records.
Status: Verified (2)
RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008
Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549
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.
Errata ID: 7658
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Mullan
Date Reported: 2023-09-26
Verifier Name: Roman Danyliw
Date Verified: 2024-01-11
Section 7.1 says:
The hyperlink to "Section 2.6.1" of RFC 4158 in this text is incorrect:
* In step 6, Insignificant Character Removal, perform white space
compression as specified in Section 2.6.1, Insignificant Space
Handling, of [RFC4518].
It currently points to https://www.rfc-editor.org/rfc/rfc5280#section-2.6.1
It should say:
It should point to https://www.rfc-editor.org/rfc/rfc4518#section-2.6.1
Notes:
Simple fix to correct an incorrect hyperlink.
Status: Reported (8)
RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008
Note: This RFC has been updated by RFC 6818, RFC 8398, RFC 8399, RFC 9549
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.
Errata ID: 6830
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2022-02-02
Section Appendix A.1 says:
-- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets, or twice the specified -- upper bound, whichever is the larger, should be allowed for -- TeletexString. For UTF8String or UniversalString at least four -- times the upper bound should be allowed.
It should say:
-- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets, or twice the specified -- upper bound, whichever is the larger, should be allowed for -- TeletexString. For UTF8String or UniversalString, four -- times the upper bound should be allowed.
Notes:
"at least four times" is likely a holdover from RFC 3280, as the same text exists in that RFC. In RFC 3280, the definition of UTF-8 in UTF8String was normatively referencing RFC 2279, which allowed for a maximum of 6 octets to represent a single Unicode character in UTF-8. However, RFC 5280 was updated to normatively reference RFC 3629, which restricts the allowed set of characters in a UTF-8 string to match those allowed in UTF-16 (i.e., the BMP and 16 supplementary planes as opposed to all 32k planes). As a result, the maximum length for a single RFC 3629 UTF-8 character is 4 octets, rendering the guidance of "at least four times" wholly unnecessary; "four times" is sufficient in all cases.
Errata ID: 7164
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Gable
Date Reported: 2022-10-14
Section 5.2.5 says:
If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.
It should say:
If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer.
Notes:
The removed phrase does not appear in the original text that this requirement is derived from, ITU-T Rec. X.509 (08/2005) Section 8.6.2.2: "If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer."
The removed phrase does not serve to create a stricter requirement; rather it creates a looser requirement which allows a CRL which does contain entries for all revoked unexpired certificates *within its scope* to not include the distributionPoint field. Given that the distributionPoint field serves an important security purpose in preventing substitution attacks, it is unlikely that this loosening was the intent of the original authors.
Errata ID: 7634
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Harper
Date Reported: 2023-09-08
Section 4.1 says:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
It should say:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
Notes:
The definition in section 4.1 disagrees with the definition in appendix A.1 (page 116) on whether the name of the field containing the signature is "signatureValue" or "signature". This error appears in RFC 3280 and RFC 2459 as well.
The versions of X.509 in force when RFCs 2459, 3280, and 5280 were published use neither of those names. (Those versions of X.509 considered a signature to be an encrypted hash and called the field "encrypted".) The current version, ITU-T X.509 (10/2019), defines this field to be "signature" in section 6.2.1. (X.509 defines the Certificate type using a component type of SIGNATURE, which has two fields named "algorithmIdentifier" and "signature".)
In addition to changing the field name in the definition of the Certificate type in section 4.1, the title and text of subsection 4.1.1.3 should be updated to replace "signatureValue" with "signature".
Errata ID: 7661
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Strauss
Date Reported: 2023-09-28
Section 3.5 says:
(g) cross-certification: Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a
certificate issued by one CA to another CA that contains a CA
signature key used for issuing certificates.
It should say:
(g) cross-certification: Two CAs exchange information used in
establishing a cross-certificate.
Notes:
The removed sentence is factually inaccurate and misleading: "A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates."
A "signature key used for issuing certificates" would be a private key. A certificate simply does not contain a private key. A definition of "cross-certificate" for the purpose of this RFC is already provided in section 3.2, so there is no point in elaborating here.
(The definition given in section 3.2 conflicts with the narrower, and more generally used, definition given in RFC 4949, but that is beside the point.)