RFC Errata
Found 10 records.
Status: Verified (3)
RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012
Note: This RFC has been updated by RFC 7318, RFC 8209
Source of RFC: sidr (rtg)
Errata ID: 3205
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-27
Verifier Name: Stewart Bryant
Date Verified: 2013-09-19
Section 5 says:
An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed.
It should say:
An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed. The extensions mentioned above MUST NOT appear more than once each.
Notes:
The clarification:
"The extensions mentioned above MUST NOT appear more than once each."
is added.
Errata ID: 3238
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Kent
Date Reported: 2012-05-31
Verifier Name: Stewart Bryant
Date Verified: 2013-01-11
Section 6.3 says:
ExtendedKeyUsage The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and cRLSign if present, as long as this is consistent with the BasicConstraints SubjectType sub-field, when specified.
It should say:
ExtendedKeyUsage The CA MAY honor ExtendedKeyUsage extensions in requests for EE certificates that are issued to routers or other devices, consistent with values specified in Standards Track RFCs that adopt this profile and that identify application-specific requirements that motivate the use of such EKUs.
Notes:
The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text
for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
EKU MAY be used in RPKI certificates.
Errata ID: 4080
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2014-08-12
Verifier Name: Alia Atlas
Date Verified: 2014-12-04
Section 6.1.1 says:
This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances.
It should say:
This field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances.
Notes:
Submitted after consultation with the responsible AD and WG chairs.
The subject field included in the PKCS#10 request can't be omitted because the ASN.1 in RFC 2986 doesn’t allow subject to be omitted - there’s no “OPTIONAL” in the ASN.1:
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}
In other words, four fields are included in every certificate request. If there’s no subject field it’s a NULL (see RFC5280 for omitting subjects) and if there’s no attributes it’s an empty sequence. version and subjectPKInfo (subject public key information) are always present.
Status: Held for Document Update (5)
RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012
Note: This RFC has been updated by RFC 7318, RFC 8209
Source of RFC: sidr (rtg)
Errata ID: 6854
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2022-02-16
Held for Document Update by: John Scudder
Date Held: 2022-05-24
Section 4.8.1 says:
The Basic Constraints extension field is a critical extension in the resource certificate profile, and MUST be present when the subject is a CA, and MUST NOT be present otherwise. The issuer determines whether the "cA" boolean is set.
It should say:
The Basic Constraints extension field is critical and MUST be present when the "cA" field is TRUE, otherwise it MUST NOT be present.
Notes:
See discussion at https://mailarchive.ietf.org/arch/msg/sidrops/dPCiDz_pDR68G4cTC8W7X5LTE5o/
The original text is tautological -- Since according to RFC 5280 §4.2.1.9 the "cA" boolean MUST be set when the subject is a CA, and MUST NOT be set when the subject is not a CA, then it's axiomatic that
cA boolean set <=> Basic Constraints field present <=> subject is a CA
Although the original text is not strictly speaking wrong, it's potentially misleading since it could be read as implying that it's possible to have the cA boolean FALSE in a CA certificate, which is not so.
Errata ID: 5187
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01
Section 7.1 says:
encompass Given two IP address and AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X.
It should say:
encompass Given two IP address or two AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X.
Errata ID: 5188
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-28
Section 7.1 says:
Validation of a certificate's resource extension in the context of a certification path (see Section 7.2 entails that for every adjacent
It should say:
Validation of a certificate's resource extension in the context of a certification path (see Section 7.2) entails that for every adjacent
Notes:
The closing parenthesis is missing.
Errata ID: 5190
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01
Section 8 says:
3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> (A string of 20 ASCII HEX digits would have 80-bits of entropy)
It should say:
3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1" (A string of 20 ASCII HEX digits would have 80-bits of entropy)
Notes:
Typo
Errata ID: 5191
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-11-28
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-01
Section 8 says:
(The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc.
It should say:
(The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc).
Notes:
The closing parenthesis is missing.
Status: Rejected (2)
RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012
Note: This RFC has been updated by RFC 7318, RFC 8209
Source of RFC: sidr (rtg)
Errata ID: 3168
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-03-26
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06
Section 4.8 says:
or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280].
It should say:
or non-critical. A certificate-using system MUST reject the certificate if it encounters an extension not explicitly mentioned in this document. This is in contrast to RFC 5280 which allows non-critical extensions to be ignored.
Notes:
Other sections of the same document contradict the original section 4.8:
Section 1:
Any extensions not explicitly mentioned MUST be absent. The same
applies to the CRLs used in the RPKI, that are also profiled in this
document.
Section 8:
Certificate Extensions:
This profile does not permit the use of any other critical or
non-critical extensions.
--VERIFIER NOTES--
This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.
Errata ID: 3174
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Mandelberg
Date Reported: 2012-04-03
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06
Section 5 says:
An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed.
It should say:
An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. The Authority Key Identifier extension MUST follow the same restrictions as in Section 4.8.3 above. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed.
Notes:
RFC 6487 doesn't specify any restrictions on the format of the AKI extension in CRLs.
--VERIFIER NOTES--
The discussion on the SIDR list concluded that this errata should be rejected, although there appears an issue that may need addressing through a new errata or a revision to the RFC text.