Summary

  • RFC 9598 stores a mailbox with a non-ASCII Local-part as SmtpUTF8Mailbox in an X.509 otherName; an ASCII-only Local-part still belongs in rfc822Name, even when the domain is internationalized.
  • The domain is converted to lowercase IDNA2008 A-label form, but the UTF-8 Local-part must not be case-folded or normalized. After domain preparation, mailbox identity is an octet-for-octet comparison.
  • A matching name is only a comparison receipt. Certification-path validity, name constraints, certificate purpose, mailbox control, SMTPUTF8 reachability, local authorization and observed delivery require separate evidence.

Imagine a relying service receiving a certificate whose subject alternative name contains an internationalized mailbox. The service also has a user-entered address. Both render as the same sequence of characters. The domains resolve to the same familiar name. A generic Unicode library reports that the strings can be normalized to the same display form.

The tempting implementation is to normalize both addresses and declare a match. Under RFC 9598, that can be the wrong security decision. The domain and the Local-part obey different comparison contracts. Domain labels may need conversion from Unicode U-labels to ASCII A-labels and then lowercasing. The Local-part must not be transformed at all. If its UTF-8 octets differ, the mailbox values do not match, however persuasive the screen rendering may be.

This is not a quirk at the edge of the standard. It is the control boundary the document was written to clarify.

One namespace, two certificate name forms

The RFC Editor record and IETF Datatracker identify RFC 9598 as a May 2024 Proposed Standard. It updates the PKIX profile in RFC 5280 and obsoletes RFC 8398.

Traditional rfc822Name can carry an ASCII mailbox. It cannot represent a non-ASCII Local-part from the internationalized-email model. RFC 9598 therefore uses the extensible otherName branch of X.509 GeneralName and assigns SmtpUTF8Mailbox the object identifier 1.3.6.1.5.5.7.8.9. The IANA SMI Numbers registry records that allocation.

The choice is determined by the Local-part. If the Local-part contains a non-ASCII character, the certificate must use SmtpUTF8Mailbox. If it is ASCII-only, the certificate must use rfc822Name—even when the domain itself is internationalized. One visible mailbox namespace is thus represented through two mutually exclusive certificate forms.

That rule matters to inventory. A parser that looks only for rfc822Name will miss internationalized Local-parts. A generator that puts an ASCII Local-part into SmtpUTF8Mailbox creates an artifact outside the RFC's compatibility contract. A validator that converts one GeneralName type into the other after parsing erases the evidence that the certificate actually carried.

The value is an envelope mailbox, not a display address. Phrases, comments and angle brackets are not part of the certificate identity. The SmtpUTF8Mailbox value is a non-empty ASN.1 UTF8String, and its UTF-8 encoding must not contain a byte-order mark. The underlying UTF-8 boundary comes from RFC 3629; the internationalized message context is bounded by RFC 6532.

The domain is prepared because it has a preparation contract

The domain side follows IDNA2008. RFC 5890 supplies the A-label, U-label and LDH vocabulary. RFC 5891 supplies the protocol conversions. RFC 9598 requires every email-address domain in an X.509 certificate to conform to IDNA2008 without relying on the mappings discussed in the framework.

Inside SmtpUTF8Mailbox, a non-ASCII domain label is stored as an A-label, not as a U-label. ASCII labels must satisfy the NR-LDH restrictions. All A-label and NR-LDH letters in the domain are lowercase. This gives the certificate one comparison form and spares a path validator from converting certificate domain labels back to Unicode.

When the candidate address comes from user input, a message or another external source, the validator does limited setup. It removes display syntax, converts any domain U-label to its A-label and lowercases eligible domain letters. Then it stops. This is canonicalization with a named scope, not permission to polish the entire mailbox.

That narrower rule is the principal repair over RFC 8398. The earlier standard conditionally used A-labels or U-labels. RFC 9598 chooses A-labels in every certificate case. Publication of a cleaner representation does not prove that certificate issuers, path builders and relying applications have all deployed it, but it gives their output a testable contract.

The Local-part stays byte-exact because no universal mapping exists

The Local-part comes from the internationalized-mail framework in RFC 6530 and the SMTP extension in RFC 6531. It is UTF-8, but UTF-8 is an encoding, not a universal mailbox-equivalence rule.

RFC 9598 says the Local-part must not be transformed. No case folding. No Unicode normalization. No compatibility mapping. After the domain has been prepared, the resulting mailbox is compared octet for octet. Two already encoded SmtpUTF8Mailbox values need no setup at all: exact bytes decide equivalence. An SmtpUTF8Mailbox and an rfc822Name always fail to match because the former requires a non-ASCII Local-part and the latter cannot contain one.

This strictness protects authority from presentation. Unicode allows visually similar characters, and user-perceived text can have multiple encodings. A normalization library may be useful for search or display. It cannot be silently promoted into the certificate identity function. If the certification authority encoded one byte sequence and the mail system provisioned another, the safe result is a mismatch to investigate, not a guessed equivalence.

The tradeoff is real. A human may see the same name twice while the validator rejects it. RFC 9598 acknowledges the interoperability cost. The alternative would let local library behavior redefine a signed identity after issuance. That would make the relying party, rather than the certificate and its governing profile, the author of the name.

Name constraints limit issuance; they do not create a mailbox

rfc822Name and SmtpUTF8Mailbox inhabit the same email-address namespace. Legacy certification authorities may already be constrained to a domain through rfc822Name name constraints. Without an update, a new otherName could appear to escape that boundary.

RFC 9549 updates the PKIX internationalization rules so those constraints cover both forms. A CA certificate expresses email constraints through IDNA2008-conformant rfc822Name values in A-label form. The comparison prepares the subject's domain, removes the Local-part, and performs an exact host or domain-suffix test. Constraints aimed at one particular mailbox should not be used.

That mechanism answers an issuing-scope question: was this mailbox domain within the subordinate CA's permitted namespace? It does not answer whether the mailbox exists, whether the certificate subject currently controls it, whether the key is suitable for the attempted operation or whether the relying application should grant access.

A complete validation receipt therefore has at least four distinct statements. The artifact contained the expected GeneralName form and exact bytes. The mailbox comparison succeeded under the RFC 9598 algorithm. The certification path and applicable name constraints succeeded under the relevant trust policy. The application accepted this certificate for this purpose. Even those four do not prove that a message could traverse an SMTPUTF8-capable path.

Matching is not delivery and not authorization

The distinction from SMTPUTF8 transport is decisive. RFC 6531 lets SMTP participants advertise and use internationalized envelope addresses. A certificate can match a mailbox while the next relay lacks that capability. Conversely, a message can travel through an SMTPUTF8-capable route without presenting any RFC 9598 certificate.

The same separation applies to control. A certification authority may have validated an address under its practice. A relying party still needs the intended trust anchor, path, policy, key usage or extended key usage, revocation state, application binding and current authorization rule. A signature can validate while the requested action remains forbidden. A mailbox can receive a message while nobody reads it. A successful login can occur while a later change fails.

Lu Heng's essay on running-code primacy makes the operational test concrete. “Supports RFC 9598” is not a result. The result is a trace that preserves the certificate bytes, parser output, prepared external domain, untouched Local-part, comparison, path, constraints, policy decision, action and effect.

The minimum-initial-specification lens explains why the RFC is narrow. It standardizes a name form and comparison rule without centralizing mailbox provisioning, CA evidence, application permission or transport operations. The essay on reality layers supplies the discipline: a represented name, a matched name, a valid certificate, a controlled mailbox, an authorized action and an observed outcome are related records, not synonyms.

The leadership consequence is simple but demanding. Do not ask one green “certificate valid” light to speak for all of them.

Sources