Internationalization Updates to RFC 5280
obsoletes
- rfc-8399 — Internationalization Updates to RFC 5280
updates
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (20)
RFC 8399 required conversion of A-labels to U-labels to process name constraints for internationalized email addresses in SmtpUTF8Mailbox, which led to implementation complexity and at least two security vulnerabilities. RFC 9549 eliminates this requirement: all IDNs are now carried and processed exclusively as A-labels.
The ability to specify name constraints for a particular mailbox (e.g., '[email protected]') was removed because this capability was not used in practice. Removing it allows name constraints to apply uniformly to email addresses in both rfc822Name and SmtpUTF8Mailbox within otherName.
Both IDNA2003 (RFC 3490) and IDNA2008 (RFC 5890) reference the Punycode algorithm (RFC 3492) for conversion of internationalized domain name labels, providing a common encoding base between the two specification generations.
Characters in the Unicode Category 'Symbol, Other' (So), including emoji, are DISALLOWED under IDNA2003 and IDNA2008. Characters allowed under the Unicode IDNA Compatibility Processing (UTS46) may not be allowed here; for example, ♚.example (U+1F0A1) fails under this specification but becomes xn--45h.example under UTS46.
The IDNA2003 requirement to set AllowUnassigned=false (treating labels as 'stored strings') in the ToASCII conversion for distinguished name domainComponent attributes is replaced by a simpler IDNA2008 requirement to convert U-labels to A-labels, removing the flag-based processing model.
A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain, but NOT a particular mailbox. The constraint 'example.com' is satisfied by any address at that host; '.example.com' matches addresses in the domain but not on the host itself.
Conforming Certification Authorities SHOULD ensure that IDNs are valid according to IDNA2008 (RFC 5890 through RFC 5893 and their updates); failure to use valid A-labels may yield a domain name that cannot be correctly represented in DNS.
Implementations that have a user interface SHOULD convert IDNs from A-labels to U-labels for display purposes.
The email address local-part within SmtpUTF8Mailbox MUST conform to the requirements of RFC 6530 and RFC 6531.
The UTF-8 encoding of an internationalized email address in SmtpUTF8Mailbox MUST NOT contain a Byte-Order-Mark (BOM) to aid comparison.
To represent an IDN label in a distinguished name domainComponent attribute, the implementation MUST convert all U-labels to A-labels (replacing the IDNA2003 'ToASCII' label conversion).
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire DNS name.
When evaluating name constraints for DNS names, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis; any DNS name formed by adding labels to the left of the constraint domain is considered within the indicated subtree.
When the host-part of an email address in a certificate extension contains an IDN, conforming implementations MUST convert all U-labels to A-labels.
When the local-part of an email address contains non-ASCII characters, conforming implementations MUST place the internationalized email address in the SmtpUTF8Mailbox within the otherName choice of GeneralName as specified in RFC 8398.
Email address placement in GeneralName depends on the local-part: if the local-part is representable in ASCII (even when the host-part is an IDN), the address goes in rfc822Name (IA5String); if the local-part contains non-ASCII characters, the address goes in SmtpUTF8Mailbox within the otherName choice.
IDNs are carried in certificates and CRLs in ACE-encoded form: all U-labels are converted to A-labels using the Punycode algorithm (RFC 3492) with the 'xn--' prefix. The dNSName field in GeneralName is type IA5String, limiting it to ASCII, which necessitates the A-label encoding.
Two email addresses with ASCII-only local-parts match if: (1) the local-parts are an exact match, AND (2) the host-parts match using case-insensitive ASCII comparison. The same matching rule applies when the local-part contains non-ASCII characters.
CAs that fail to validate IDNs against IDNA2008 may issue certificates with A-labels that cannot be correctly represented in DNS, potentially creating name mismatches or certificate validation failures. The CA/Browser Forum provides additional guidance on internal server names.
RFC 8399's requirement to convert A-labels back to U-labels for processing name constraints on internationalized email addresses led to at least two security vulnerabilities (see CVE-2022-3602 / OpenSSL punycode vulnerability). RFC 9549 removes this conversion requirement entirely: A-labels are used throughout.