RFC Errata
Found 4 records.
Status: Verified (3)
RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012
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: Reported (1)
RFC 6487, "A Profile for X.509 PKIX Resource Certificates", February 2012
Source of RFC: sidr (rtg)
Errata ID: 6854
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Corey Bonnell
Date Reported: 2022-02-16
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 a critical extension in the resource certificate profile, and MUST be present when the subject is a CA, and MUST NOT be present otherwise. If this extension is present, then the "cA" field MUST be true.
Notes:
The original text is contradictory. If the basicConstraints extension is prohibited in end-entity certificates, then it follows that whenever the extension is present in a certificate, that certificate is a CA certificate. If the certificate is a CA certificate, then the "cA" boolean MUST be true in all cases. It is nonsensical to allow a "cA" field value of false.
