RFC Errata
Found 22 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.)
Status: Held for Document Update (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: 3200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-24
Held for Document Update by: Sean Turner
Section 4.1.2.2 says:
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.
It should say:
The serial number MUST be a positive non-zero integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a positive integer.
Notes:
"positive" and "non-negative" do not mean the same thing. I used the third paragraph of the section as a tie-breaker to decide which of the two terms was intended:
Note: Non-conforming CAs may issue certificates with serial numbers
that are negative or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.
Errata ID: 5876
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Woodhouse
Date Reported: 2019-10-16
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-10-20
Section 4.2.1.6 says:
When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791].
It should say:
When the subjectAltName extension contains an IP address, the address MUST be stored in the iPAddress (an octet string). The address MUST be stored in the octet string in "network byte order", as specified in [RFC791].
Notes:
For email addresses and domain names, this section is very prescriptive:
When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name.
...
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName…
However, for IP addresses, it's possible to interpret the current wording as saying that *if* you happen to choose the iPAddress form for an IP address, then you must represent that as big-endian. I suspect this was a poor choice of wording and the intent was to say that you MUST use the iPAddress form for an IP address.
Errata ID: 5997
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Sleevi
Date Reported: 2020-02-27
Held for Document Update by: Benjamin Kaduk
Date Held: 2020-03-17
Section 4.2.1.10 says:
DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.
It should say:
For DNS names, restrictions MUST use the dNSName syntax in Section 4.2.1.6. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, if the constraint contains host.example.com, then www.host.example.com would satisfy the constraint but host1.example.com would not.
Notes:
Currently, the syntax for a dNSName nameConstraint is left implicit, and thus has resulted in ambiguities in encoding and processing that have resulted in ineroperability issues.
One interpretation is that the dNSName nameConstraint must be a valid "host name" (as discussed in RFC 8499), which is to say must be a Fully-Qualified Domain Name in the preferred name syntax. This interpretation is supported by Section 4.2.1.6, which explicitly states that for the subjectAltName. As 4.2.1.10 does not define an exception to this (as discussed in Appendix B), the interpretation, along with the existing example, would conclude that this field uses preferred name syntax, and that "DNS name" here matches the "host name" interpretation from RFC 8499
A different interpretation is that the dNSName nameConstraint uses the modified syntax similar to the URI nameConstraint. That is, it explicitly permits a leading period to indicate that one or more labels preceding is required in order to satisfy the constraint. This allows subdomains, but does not allow the base domain to match. While the language for the DNS name constraint makes it clear that a host name with no preceding period matches both that host and sub-domains, the existence of a preceding period would constraint it to only subdomains.
Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as the preferred name syntax does not permit leading periods. Alternatively, if the latter interpretation is intended, this section would benefit from making that explicit.
This has been a source of interoperability issues, with additional information and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id=3562
While "running code" has aligned in being permissive with a leading period, implementations have gone and seemingly aligned on a third interpretation:
The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the exception that it MAY contain a leading period. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name, ignoring any leading period, satisfies the name constraint.
This seems to support implementations expecting the first interpretation in the certificates they receive, and seeing leading period as an encoding mistake, not an explicit desire for the second interpretation.
Errata ID: 3466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2013-01-18
Held for Document Update by: Sean Turner
Section 4.2.1.6 says:
If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST | NOT issue certificates with subjectAltNames containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile.
It should say:
If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST | NOT issue certificates with subjectAltName extensions containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile.
Notes:
Certificates do not have "subjectAltNames" but only "subjectAltName extensions", which is the correct wording that is thoroughly used in the document.
Errata ID: 3674
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Piyush Jain
Date Reported: 2013-06-28
Held for Document Update by: Sean Turner
Section 6.3.3 says:
If the distribution point name is present in the IDP CRL extension and the distribution field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP.
It should say:
If the distribution point name is present in the IDP CRL extension and the distributionPoint field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP.
Notes:
Original text refers to the non existent field "distribution" in DP.
Errata ID: 3754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michal Bozon
Date Reported: 2013-10-16
Held for Document Update by: Sean Turner
Date Held: 2013-10-16
Section A.1 says:
-- Naming attributes of type X520countryName (digraph from IS 3166)
It should say:
-- Naming attributes of type X520countryName (digraph from ISO 3166)
Notes:
typo in ASN.1 comment ("IS", should be "ISO")
Errata ID: 4274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ilya V. Matveychikov
Date Reported: 2015-02-19
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-03-25
Section A.1 says:
-- Naming attributes of type X520CommonName: -- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) ... -- Naming attributes of type X520LocalityName: -- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) ... -- Naming attributes of type X520StateOrProvinceName: -- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) ... -- Naming attributes of type X520OrganizationName: -- X520OrganizationName ::= -- DirectoryName (SIZE (1..ub-organization-name)) ... -- Naming attributes of type X520OrganizationalUnitName: -- X520OrganizationalUnitName ::= -- DirectoryName (SIZE (1..ub-organizational-unit-name)) ... -- Naming attributes of type X520Title: -- X520Title ::= DirectoryName (SIZE (1..ub-title)) ... -- Naming attributes of type X520Pseudonym: -- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))
It should say:
-- Naming attributes of type X520CommonName: -- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name)) ... -- Naming attributes of type X520LocalityName: -- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name)) ... -- Naming attributes of type X520StateOrProvinceName: -- X520StateOrProvinceName ::= -- DirectoryString (SIZE (1..ub-state-name)) ... -- Naming attributes of type X520OrganizationName: -- X520OrganizationName ::= -- DirectoryString (SIZE (1..ub-organization-name)) ... -- Naming attributes of type X520OrganizationalUnitName: -- X520OrganizationalUnitName ::= -- DirectoryString (SIZE (1..ub-organizational-unit-name)) ... -- Naming attributes of type X520Title: -- X520Title ::= DirectoryString (SIZE (1..ub-title)) ... -- Naming attributes of type X520Pseudonym: -- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym))
Notes:
Appendix B. ASN.1 Notes says that:
For many of the attribute types defined in [X.520], the
AttributeValue uses the DirectoryString type. Of the attributes
specified in Appendix A, the name, surname, givenName, initials,
generationQualifier, commonName, localityName, stateOrProvinceName,
organizationName, organizationalUnitName, title, and pseudonym
attributes all use the DirectoryString type. X.520 uses a
parameterized type definition [X.683] of DirectoryString to specify
the syntax for each of these attributes. The parameter is used to
indicate the maximum string length allowed for the attribute. In
Appendix A, in order to avoid the use of parameterized type
definitions, the DirectoryString type is written in its expanded form
for the definition of each of these attribute types. So, the ASN.1
in Appendix A describes the syntax for each of these attributes as
being a CHOICE of TeletexString, PrintableString, UniversalString,
UTF8String, and BMPString, with the appropriate constraints on the
string length applied to each of the types in the CHOICE, rather than
using the ASN.1 type DirectoryString to describe the syntax.
There is nothing about DirectoryName type here. So comments in ASN.1 in
A.1 are wrong and DirectoryName should be fixed to DirectoryString.
From Expert PKIX reviewers:
The errata calls for changing "DirectoryName" to "DirectoryString" in the comments
of the ASN.1. Nobody seems to disagree with this correction.
This message triggered a lot of discussion about whether to remove the string size limits.
That discussion ended with consensus to retain the size limits.
Errata ID: 4847
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Annie Yousar
Date Reported: 2016-10-30
Held for Document Update by: Stephen Farrell
Date Held: 2016-10-31
Section A.1 says:
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
| -- arc for extended key purpose OIDS
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- arc for access descriptors
It should say:
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
| -- arc for extended key purpose OIDs
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- arc for access descriptors
Notes:
"Object Identifiers" are abbreviated as "OIDs" and not as "OIDS".
Status: Rejected (4)
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: 1774
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Ito
Date Reported: 2009-05-04
Rejected by: Pasi Eronen
Date Rejected: 2009-05-27
Section 6.3 says:
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
It should say:
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:
(l) Set the reasons_mask state variable to the union of
its previous value and the value of the interim_reasons_mask
state variable.
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
Notes:
This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.
--VERIFIER NOTES--
The correction already appears as step (l), the last step in the loop.
Errata ID: 3693
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Weimer
Date Reported: 2013-08-12
Rejected by: Sean Turner
Date Rejected: 2013-08-14
Section 4.2.1.10 says:
DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.
It should say:
[Add this to the paragraph] If an implementation extracts DNS names from the subject distinguished name, DNS name restrictions MUST be applied to these names as well.
Notes:
When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=394919
--VERIFIER NOTES--
The suggested change is not editorial; it represents a significant
technical change. It also does not accurately reflect the intent of the WG.
Errata ID: 5967
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Maxim
Date Reported: 2020-01-27
Rejected by: Benjamin Kaduk
Date Rejected: 2020-02-02
Section 4.2.2.1. says:
The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears.
It should say:
The authority information access extension indicates how to access information and services of the issuer of the certificate in which the extension appears.
Notes:
When you use "access services for the issuer" you refer to grandparent node for the certificate in certification path. But actually you mean here the parent node in certification path (the services of the CA that has issued the certificate) and that would be "services of the issuer".
--VERIFIER NOTES--
"the issuer of the certificate in which the extension appears" is a precise indication of the parent node and does not refer to the grandparent node.
Errata ID: 3085
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2012-01-06
Rejected by: Sean Turner
Date Rejected: 2012-01-09
Section A.1 says:
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] IMPLICIT NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] IMPLICIT OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
OPTIONAL,
personal-name [5] IMPLICIT PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
OPTIONAL }
-- see also teletex-organizational-unit-names
It should say:
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] IMPLICIT NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL,
organization-name [3] IMPLICIT OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
OPTIONAL,
personal-name [5] IMPLICIT PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
OPTIONAL }
-- see also teletex-organizational-unit-names
Notes:
Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else?
--VERIFIER NOTES--
PrivateDomainName (unlike the other tagged components) is an untagged
CHOICE type.
Quote from X.680:
'30.8 The IMPLICIT alternative shall not be used if the type defined
by "Type" is an untagged choice type or an untagged open type or an untagged
"DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).'