Internationalization Updates to RFC 5280
obsoleted by
- rfc-9549 — Internationalization Updates to RFC 5280
updates
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (17)
RFC 5280's references for internationalized names were updated from IDNA2003 (RFC 3490) to IDNA2008 (RFC 5890, RFC 5891) to align with the current specification. Both IDNA2003 and IDNA2008 use the Punycode algorithm for conversion.
The ability to specify name constraints for a particular mailbox was removed because this capability was not used in practice, and removing it allows name constraints to apply uniformly to email addresses in both rfc822Name and SmtpUTF8Mailbox within otherName.
IDN ACE labels begin with the four additional characters 'xn--', and an IDN can require as many as five ASCII characters to specify a single international character, resulting in increased memory requirements for implementations handling IDNs.
The SmtpUTF8Mailbox type (defined in RFC 8398) is used within the otherName choice of GeneralName to carry internationalized email addresses whose local-part contains non-ASCII characters. The comparison rules for such addresses are also defined in RFC 8398 Section 5.
A name constraint for Internet mail addresses MAY specify all addresses at a particular host or all mailboxes in a domain, but MAY NOT specify a particular mailbox. This removes the previously allowed per-mailbox constraint.
Conforming CAs SHOULD ensure that IDNs are valid by validating all code points according to IDNA2008 (RFC 5892). Failure to use valid A-labels and valid U-labels may yield a domain name that cannot be correctly represented in the DNS.
Implementations SHOULD convert IDNs to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display.
The UTF8 encoding of an internationalized email address MUST NOT contain a Byte-Order-Mark (BOM) to aid comparison.
To represent a label from an IDN in the distinguished name, the implementation MUST convert all U-labels to A-labels.
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire DNS name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis.
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.
Where the host-part of an email address contains an IDN, conforming implementations MUST convert all U-labels to A-labels.
IDNs are carried in certificates in ACE-encoded form: all U-labels within an IDN are converted to A-labels using the Punycode algorithm (RFC 3492) with the ACE prefix 'xn--' added at the beginning of the string. The one exception is SmtpUTF8Mailbox which carries U-labels.
IDNs may be included in certificates and CRLs in the subjectAltName, issuerAltName, name constraints, authority information access, subject information access, CRL distribution points, and issuing distribution point extensions via the dNSName field (type IA5String) of GeneralName.
If an email address includes an IDN but the local-part can be represented in ASCII, the address is placed in the rfc822Name choice of GeneralName (type IA5String). If the local-part cannot be represented in ASCII, the address is placed in the otherName choice using SmtpUTF8Mailbox per RFC 8398.
Two email addresses with ASCII local-parts are considered to match if: (1) the local-part of each name is an exact match, AND (2) the host-part of each name matches using a case-insensitive ASCII comparison.
CAs that fail to validate IDN code points per IDNA2008 (RFC 5892) may issue certificates containing invalid A-labels or U-labels that cannot be correctly represented in the DNS, potentially leading to naming mismatches or spoofing. The CA/Browser Forum also offers guidance on internal server names in certificates.