Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
updates
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (15)
Self-issued certificates and self-signed certificates issued by entities other than CAs are explicitly placed outside the scope of RFC 5280, consistent with X.509 (11/2008) Section 3.4.61. A web server generating a self-signed certificate to identify itself, and relying-party use of such certificates, are both out of scope.
The acceptable encodings for the explicitText field were updated to prohibit IA5String (previously allowed) and to permit VisibleString and BMPString (previously prohibited). This change aligns the specification with existing deployed practice rather than requiring a break from common implementations.
The IDN ToASCII conversion rule in Section 7.3 (Distinguished Names) is aligned with the rule in Section 7.2 (GeneralNames) by requiring the UseSTD3ASCIIRules flag, making the two code paths consistent. The conversion process is now the same as step 4 in Section 7.2.
The path validation algorithm does not specify processing rules for additional information in self-signed trust anchor certificates; implementations are free to use or ignore such information. RFC 5914 defines trust anchor formats and RFC 5937 provides guidance on using them to initialize path validation inputs.
RFC 5914 is added as a normative reference to RFC 5280, defining formats for representing trust anchor information including self-signed certificates. RFC 5937 is added as an informative reference showing how such information may be used to initialize path validation inputs.
The IDN encoding rules for domain components in Distinguished Names (Section 7.3) and for dNSName GeneralNames (Section 7.2) are now aligned. Both require UseSTD3ASCIIRules and treat the label as a stored string with AllowUnassigned unset.
Conforming CAs MUST NOT encode the explicitText field of the user notice policy qualifier as IA5String. This reverses the previous RFC 5280 allowance of IA5String and brings the rule in line with existing practice.
Conforming CAs SHOULD use UTF8String encoding for the explicitText field. VisibleString and BMPString are acceptable but less preferred alternatives.
The explicitText string SHOULD NOT include any control characters (e.g., U+0000 to U+001F and U+007F to U+009F).
To represent an IDN label in a Distinguished Name, implementations MUST perform the ToASCII label conversion specified in Section 4.1 of RFC 3490 with the UseSTD3ASCIIRules flag set. This flag was absent in the original RFC 5280 text.
When converting IDN labels to ASCII for Distinguished Names, the label SHALL be treated as a 'stored string', meaning the AllowUnassigned flag SHALL NOT be set.
When UTF8String or BMPString encoding is used for explicitText, all character sequences SHOULD be normalized according to Unicode normalization form C (NFC).
Compromise of a CA private key allows an attacker to issue bogus certificates and CRLs, including bogus CA certificates with the same subject names as legitimate CAs, enabling issuance of certificates with matching issuer names and possibly the same serial numbers as legitimate ones. All certificates issued to a compromised CA MUST be revoked.
Even without obtaining a CA's private key, an attacker may issue bogus certificates and CRLs by making unauthorized use of the CA's or an RA's workstation, whether through remote compromise or insider activity. This expands the RFC 5280 threat model beyond key theft.
One-way hash functions used to generate key identifiers (AKI and SKI) do not require any specific security property — in particular, collision resistance is not required for this use case.