Internationalized Email Addresses in X.509 Certificates
obsoletes
- rfc-8398 — Internationalized Email Addresses in X.509 Certificates
updates
- rfc-5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extracted elements (25)
Octet-for-octet comparison of SmtpUTF8Mailbox Local-parts is required rather than Unicode-normalized comparison, to mitigate attacks where different encodings are used by the mail system and the Certification Authority. This trades potential interoperability concerns for improved security.
SmtpUTF8Mailbox is only used when the Local-part contains non-ASCII characters, with rfc822Name required for ASCII Local-parts, to maintain compatibility with legacy software that supports rfc822Name but not SmtpUTF8Mailbox.
This document mandates A-label encoding for all domain labels in SmtpUTF8Mailbox, eliminating the conditional A-label or U-label encoding from RFC 8398. This simplification reduces complexity for path validation algorithm implementations by eliminating the need to convert domain labels to Unicode representation during comparison.
Comparison of an SmtpUTF8Mailbox and an rfc822Name will always fail because SmtpUTF8Mailbox values SHALL contain a Local-part with one or more non-ASCII characters, while rfc822Name only includes ASCII characters. The two name forms will never match.
This document obsoletes RFC 8398 with three major changes: (1) domain labels SHALL always be encoded as LDH/A-labels, never U-labels; (2) the matching algorithm is updated to only accept A-label domain representations; (3) the rfc822Name name constraint procedure is updated to only accept A-label domain representations.
All email address domains in X.509 certificates MUST conform to IDNA2008 (RFC 5890) and avoid any mappings mentioned in that document. This applies to SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName, and everywhere else they appear.
Certificate Authorities that wish to issue CA certificates with email address name constraints MUST use rfc822Name subject alternative names only. These MUST be IDNA2008-conformant names with no mappings and with non-ASCII domains encoded in A-labels only.
Domain labels that solely use ASCII characters SHALL use NR-LDH restrictions as specified by Section 2.3.1 of RFC 5890. All NR-LDH and A-label labels that constitute the domain part SHALL only be encoded with lowercase letters to facilitate octet-for-octet comparisons.
For Local-part setup in SmtpUTF8Mailbox comparison, the Local-part MUST be verified to conform to RFC 6530 and RFC 6531 in UTF-8 form. The Local-part MUST NOT be transformed in any way, such as by doing case folding or normalization of any kind.
In SmtpUTF8Mailbox, labels that include non-ASCII characters MUST be stored in A-label (rather than U-label) form as defined in RFC 5890. This reduces complexity for path validation algorithm implementations.
rfc822Name name constraints with a Local-part SHOULD NOT be used, because RFC 9549 deprecates rfc822Name name constraints that represent a particular mailbox, allowing only forms that represent all addresses at a host or all mailboxes in a domain.
SmtpUTF8Mailbox comparison implementations MUST NOT interpret any characters as wildcards. To specify multiple email addresses, the certificate MUST use multiple subjectAltNames or issuerAltNames to explicitly carry each additional email address.
The UTF8String encoding of SmtpUTF8Mailbox MUST NOT contain a Byte Order Mark (BOM) per RFC 3629, to aid consistency across implementations particularly for comparison.
When the Local-part is ASCII-only, rfc822Name subjectAltName MUST be used instead of SmtpUTF8Mailbox. SmtpUTF8Mailbox MUST NOT be used unless the Local-part contains non-ASCII characters.
When the subjectAltName or issuerAltName extension contains an internationalized email address with a non-ASCII Local-part, the address MUST be stored in the SmtpUTF8Mailbox name form of otherName.
Equivalence comparison of SmtpUTF8Mailbox values uses a two-step process: (1) domain part comparison using LDH label encoding after converting U-labels to A-labels and lowercasing, and (2) Local-part comparison in UTF-8 form without any transformation. Two SmtpUTF8Mailbox values are equivalent if there is an exact octet-for-octet match after setup.
SmtpUTF8Mailbox-aware path validators apply name constraint comparison to the subject distinguished name and both rfc822Name and SmtpUTF8Mailbox subject alternative name forms. RFC 9549 extends rfc822Name name constraints to cover SmtpUTF8Mailbox subjectAltNames, ensuring introduction of SmtpUTF8Mailbox does not violate existing name constraints.
SmtpUTF8Mailbox is a new otherName variant for representing internationalized email addresses in X.509 GeneralName structures. It is defined as a UTF8String of at least one character, with OID id-on-SmtpUTF8Mailbox (1.3.6.1.5.5.7.8.9), and may appear in subjectAltName, issuerAltName, or anywhere GeneralName is used.
SmtpUTF8Mailbox is an envelope Mailbox with no phrase before it, no comment after it, and not surrounded by '<' and '>' characters, consistent with the treatment of rfc822Name in RFC 5280.
IANA updated the reference for the id-mod-lamps-eai-addresses-2016 module in the 'SMI Security for PKIX Module Identifier' registry (OID 1.3.6.1.5.5.7.0) to point to RFC 9598 instead of RFC 8398.
IANA updated the reference for the SmtpUTF8Mailbox otherName in the 'SMI Security for PKIX Other Name Forms' registry (OID 1.3.6.1.5.5.7.8) to point to RFC 9598 instead of RFC 8398.
A Unicode string of user-perceived characters can be encoded in multiple ways, and RFC 6531 does not mandate normalization forms for the Local-part. This specification requires octet-for-octet comparison to mitigate attacks using different encodings, but this may raise interoperability concerns where the mail system and Certification Authority use different encodings.
Use of Unicode in the email address Local-part introduces the risk of visually similar and identical characters (homograph attacks) that can be exploited to deceive the recipient. RFC 5890 Section 4.4 and RFC 6532 Section 4 reference mitigations against these attacks.
SmtpUTF8Mailbox is encoded as UTF8String (SIZE (1..MAX)). All domain labels are encoded as LDH labels (A-labels for internationalized labels, NR-LDH for ASCII-only labels), never as U-labels. The encoding MUST NOT contain a Byte Order Mark (BOM).
The DER encoding of an SmtpUTF8Mailbox otherName for the email address 'U+533BU+[email protected]' is: a02b0608 2b060105 05070809 a01f0c1d e58cbbe7 949f4078 6e2d2d70 73733235 632e6578 616d706c 652e636f 6d. The structure is a context-tagged sequence containing the OID 1.3.6.1.5.5.7.8.9 followed by a context-tagged UTF8String.