Internationalized Email Addresses in X.509 Certificates
obsoleted by
- rfc-9598 — 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 (20)
Non-ASCII domain labels in SmtpUTF8Mailbox are required to be U-labels rather than A-labels to remove the ambiguity of which label encoding is present, simplifying comparison and reducing conversion errors. This document recommends transforming domains to U-labels for comparison rather than A-labels, to reduce conversions as more implementations natively support U-labels.
SmtpUTF8Mailbox is modeled as an envelope Mailbox (no phrase, comment, or angle brackets) consistent with rfc822Name treatment in RFC 5280, to maintain a uniform presentation of email addresses in certificates.
Name constraint comparison for SmtpUTF8Mailbox strips the local-part and '@' separator, leaving only the domain, which is then compared against rfc822Name name constraints using the domain-matching rules of RFC 5280 Section 4.2.1.10.
RFC 8399 updates rfc822Name name constraints in RFC 5280 to cover SmtpUTF8Mailbox subject alternative names, ensuring that introduction of SmtpUTF8Mailbox does not violate existing name constraints issued by legacy CAs.
SmtpUTF8Mailbox is restricted to non-ASCII local-parts specifically to maintain compatibility with legacy software that supports only rfc822Name; when the local-part is ASCII-only, rfc822Name MUST be used even if the domain contains non-ASCII characters (encoded as A-label).
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 both SmtpUTF8Mailbox and rfc822Name wherever used.
Certificate Authorities that wish to issue CA certificates with email address name constraints MUST use rfc822Name subject alternative names only, and these MUST be IDNA2008-conformant with non-ASCII domains encoded in A-labels only.
Domain labels in SmtpUTF8Mailbox that solely use ASCII characters SHALL use NR-LDH restrictions per RFC 5890 Section 2.3.1 and SHALL be restricted to lowercase letters.
In setup for SmtpUTF8Mailbox comparison, the email address local-part MUST conform to RFC 6530 and RFC 6531 requirements including being a UTF-8 string, and MUST NOT be transformed in any way such as by case folding or normalization.
In SmtpUTF8Mailbox, domain labels that include non-ASCII characters MUST be stored in U-label (rather than A-label) form as defined in RFC 5890.
rfc822Name name constraints that represent a particular mailbox (i.e., containing a local-part) SHOULD NOT be used, as RFC 8399 deprecates this form.
SmtpUTF8Mailbox comparison implementations MUST NOT interpret any characters as wildcards. To specify multiple email addresses, the certificate MUST use multiple subjectAltNames or issuerAltNames.
SmtpUTF8Mailbox MUST NOT be used unless the local-part of the email address contains non-ASCII characters. When the local-part is ASCII, rfc822Name subjectAltName MUST be used instead.
The UTF8String encoding of SmtpUTF8Mailbox MUST NOT contain a Byte-Order-Mark (BOM) to aid consistency across implementations, particularly for comparison.
When a subjectAltName or issuerAltName contains an internationalized email address with a non-ASCII local-part, the address MUST be stored in the SmtpUTF8Mailbox name form of otherName.
SmtpUTF8Mailbox is a new otherName form for X.509 GeneralName, assigned OID id-on-SmtpUTF8Mailbox (1.3.6.1.5.5.7.8.9), encoded as UTF8String of size 1..MAX, conforming to the Mailbox definition in RFC 6531 Section 3.3.
IANA registered value 9 for id-on-SmtpUTF8Mailbox in the 'SMI Security for PKIX Other Name Forms' registry (OID arc 1.3.6.1.5.5.7.8), and value 92 for 'id-mod-lamps-eai-addresses-2016' in the 'SMI Security for PKIX Module Identifier' registry (OID arc 1.3.6.1.5.5.7.0).
Use of Unicode in the email local-part introduces the risk of visually similar and identical characters (homograph attacks) that can be exploited to deceive certificate relying parties. Implementers are referred to RFC 5890 Section 4.4, RFC 6532 Section 4, and [WEBER] for mitigations.
SmtpUTF8Mailbox comparison proceeds in two steps: (1) domain part normalization — A-labels converted to U-labels, ASCII NR-LDH labels lowercased; (2) local-part kept as-is in UTF-8. After setup, strings are compared octet-for-octet for equivalence.
SmtpUTF8Mailbox is encoded as ASN.1 UTF8String with OID id-on-SmtpUTF8Mailbox (1.3.6.1.5.5.7.8.9) inside an otherName structure within GeneralName. The DER example for 'u+8001u+[email protected]' is: A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 6D706C65 2E636F6D.