RFC 9549

Internationalization Updates to RFC 5280

📅 published March 2024, from ietf

RFC 9549: Internationalization Updates to RFC 5280 💖

Okay bestie, this one is from the IETF (Internet Engineering Task Force) 🎀. It's RFC 9549, written by R. Housley from Vigil Security, dated March 2024. It's a Standards Track document, so it's officially a real Internet standard 👑 (ISSN 2070-1721). It obsoletes RFC 8399, which means 8399 is retired now 💀, and it updates RFC 5280, the big X.509 certificate rulebook 📜.

Abstract

So the updates to RFC 5280 in this doc line it up with the 2008 spec for Internationalized Domain Names (IDNs) 🌍 and add support for internationalized email addresses in X.509 certificates ✨. The big win is that name constraints treat plain ASCII email addresses and internationalized email addresses the same way 🫶. And yes, this document obsoletes RFC 8399 💅.

Status of This Memo

This is an Internet Standards Track document 👑.

This document is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🎀. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚.

Info about this doc's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9549 🔗.

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as in effect on the date this document was published 📄. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🔥.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🕰️. The people controlling the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Without an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.

Table of Contents

  • 1. Introduction
    • 1.1. Terminology
    • 1.2. Changes since RFC 8399
  • 2. Updates to RFC 5280
    • 2.1. Update in the Introduction (Section 1)
    • 2.2. Update in Name Constraints (Section 4.2.1.10)
    • 2.3. Update in IDNs in GeneralName (Section 7.2)
    • 2.4. Update in IDNs in Distinguished Names (Section 7.3)
    • 2.5. Update in Internationalized Electronic Mail Addresses (Section 7.5)
  • 3. Security Considerations
  • 4. IANA Considerations
  • 5. References
    • 5.1. Normative References
    • 5.2. Informative References
  • Acknowledgements
  • Author's Address

1. Introduction ✨

Okay so this doc updates three spots in RFC 5280 [RFC5280] 📜. First, the Introduction in Section 1. Second, the Name Constraints certificate extension discussion in Section 4.2.1.10. Third, the Processing Rules for Internationalized Names in Section 7. The goal is to line everything up with the 2008 IDN spec and add support for internationalized email addresses in X.509 certificates 💖.

An IDN in Unicode (native character) form has at least one U-label [RFC5890] 🌸. IDNs get carried in certificates in ACE-encoded form, which means every U-label inside an IDN gets converted to an A-label 🔁. The conversion from U-label to A-label is described in [RFC5891] 🦋.

The GeneralName structure supports lots of name forms, including otherName for extensibility 🧩. RFC 8398 [RFC8398] specifies the SmtpUTF8Mailbox for internationalized email addresses 📧.

Also, IDNA2003 [RFC3490] and IDNA2008 [RFC5890] both point to the Punycode algorithm for conversion [RFC3492] 🍓.

⚠️ Heads up: characters in the Unicode Category "Symbol, Other" (So) are specifically NOT included in IDNA2003 [RFC3490] or IDNA2008 [RFC5890]. Their derived property values are calculated as DISALLOWED. So some characters that are allowed under the Unicode IDNA Compatibility Processing [UTS46] are not allowed here. For example, ♚.example contains the Unicode character U+1F0A1 (BLACK CHESS KING). It fails under this spec, but it becomes xn--45h.example under [UTS46] 💀.

1.1. Terminology

Here's the key word rundown 🔑. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here 🎀.

1.2. Changes since RFC 8399

Real talk, the old RFC 8399 [RFC8399] made implementers convert A-labels back into U-labels just to process name constraints for internationalized email addresses 😩. That led to extra implementation complexity and at least two security vulnerabilities 🙈. There's a summary of those vulnerabilities in [DDHQ] 📚. The new move is that all IDNs get carried and processed as A-labels ✨, which is so much cleaner 🫶.

The Introduction also gives implementers a warning about handling characters in the Unicode Category "Symbol, Other" (So), which includes emoji 🌈.

2. Updates to RFC 5280 🦋

This section has the updates to several paragraphs of [RFC5280] 💅. For clarity, if the whole section isn't being replaced, you get to see both the original text and the replacement text 👀.

2.1. Update in the Introduction (Section 1)

This update adds references for IDNA2008 📚. Here's the OLD text:

OLD

|  *  Enhanced support for internationalized names is specified in
|     Section 7, with rules for encoding and comparing
|     Internationalized Domain Names, Internationalized Resource
|     Identifiers (IRIs), and distinguished names.  These rules are
|     aligned with comparison rules established in current RFCs,
|     including [RFC3490], [RFC3987], and [RFC4518].

And here's the NEW text:

NEW

|  *  Enhanced support for internationalized names is specified in
|     Section 7, with rules for encoding and comparing
|     Internationalized Domain Names, Internationalized Resource
|     Identifiers (IRIs), and distinguished names.  These rules are
|     aligned with comparison rules established in current RFCs,
|     including [RFC3987], [RFC4518], [RFC5890], and [RFC5891].

2.2. Update in Name Constraints (Section 4.2.1.10)

This update removes the ability to include constraints for a particular mailbox 🙅‍♀️. Nobody was using that capability, and getting rid of it lets name constraints apply to email addresses in rfc822Name and SmtpUTF8Mailbox [RFC8398] within otherName 💖.

Here's the OLD text:

OLD

|  A name constraint for Internet mail addresses MAY specify a
|  particular mailbox, all addresses at a particular host, or all
|  mailboxes in a domain.  To indicate a particular mailbox, the
|  constraint is the complete mail address.  For example,
|  "root@example.com" indicates the root mailbox on the host
|  "example.com".  To indicate all Internet mail addresses on a
|  particular host, the constraint is specified as the host name.
|  For example, the constraint "example.com" is satisfied by any mail
|  address at the host "example.com".  To specify any address within
|  a domain, the constraint is specified with a leading period (as
|  with URIs).  For example, ".example.com" indicates all the
|  Internet mail addresses in the domain "example.com", but not
|  Internet mail addresses on the host "example.com".

And the NEW text:

NEW

|  A name constraint for Internet mail addresses MAY specify all
|  addresses at a particular host or all mailboxes in a domain.  To
|  indicate all Internet mail addresses on a particular host, the
|  constraint is specified as the host name.  For example, the
|  constraint "example.com" is satisfied by any mail address at the
|  host "example.com".  To specify any address within a domain, the
|  constraint is specified with a leading period (as with URIs).  For
|  example, ".example.com" indicates all the Internet mail addresses
|  in the domain "example.com" but not Internet mail addresses on the
|  host "example.com".

2.3. Update in IDNs in GeneralName (Section 7.2)

This update lines things up with IDNA2008 🌸. Since all of Section 7.2 of [RFC5280] is being replaced, there's no OLD text this time. Just the NEW text 👇:

NEW

|  Internationalized Domain Names (IDNs) may be included in
|  certificates and CRLs in the subjectAltName and issuerAltName
|  extensions, name constraints extension, authority information
|  access extension, subject information access extension, CRL
|  distribution points extension, and issuing distribution point
|  extension.  Each of these extensions uses the GeneralName type;
|  one choice in GeneralName is the dNSName field, which is defined
|  as type IA5String.
|
|  IA5String is limited to the set of ASCII characters.  To
|  accommodate IDNs, U-labels are converted to A-labels.  The A-label
|  is the encoding of the U-label according to the Punycode algorithm
|  [RFC3492] with the ACE prefix "xn--" added at the beginning of the
|  string.
|
|  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.  As noted in Section 4.2.1.10, any DNS name
|  that may be constructed by adding labels to the left-hand side of
|  the domain name given as the constraint is considered to fall
|  within the indicated subtree.
|
|  Implementations that have a user interface SHOULD convert IDNs to
|  Unicode for display.  Specifically, conforming implementations
|  convert A-labels to U-labels for display purposes.
|
|  Implementation consideration: There are increased memory
|  requirements for IDNs.  An IDN ACE label will begin with the four
|  additional characters "xn--", and an IDN can require as many as
|  five ASCII characters to specify a single international character.

Quick recap for the implementation side 🧠: comparing DNS names for equality is a case-insensitive exact match on the whole name ✨. Evaluating name constraints is a case-insensitive exact match, but label by label 🍓. And IDNs eat a bit more memory, since the "xn--" prefix adds four characters and one international character can take up to five ASCII characters 💜.

2.4. Update in IDNs in Distinguished Names (Section 7.3) 🎀

This update lines things up with IDNA2008, so it's giving consistency 💅

OLD 🕰️ (the before, bestie):

Domain names can also show up as distinguished names, using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. Just like dNSName in GeneralName, the value of this attribute is an IA5String, and each domainComponent attribute stands for one single label. To put an IDN label into the distinguished name, the implementation MUST do the "ToASCII" label conversion from Section 4.1 of RFC 3490. That label SHALL count as a "stored string", which means the AllowUnassigned flag SHALL NOT be set.

NEW 🆕 (the glow-up):

Domain names can also be written as distinguished names, with domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. Same energy as dNSName in GeneralName: the value is an IA5String, and each domainComponent attribute is one label. For an IDN label in the distinguished name, the implementation MUST convert all U-labels to A-labels. ✨

2.5. Update in Internationalized Electronic Mail Addresses (Section 7.5) 💌

This update aligns with IDNA2008 and [RFC8398]. Since all of Section 7.5 of [RFC5280] got replaced, there's no OLD text to show, so we're going straight to the glow-up 🦋

NEW 🆕:

Electronic Mail addresses can show up in certificates and CRLs inside the subjectAltName and issuerAltName extensions, the name constraints extension, the authority information access extension, the subject information access extension, the issuing distribution point extension, or the CRL distribution points extension. Each of these uses the GeneralName construct. If the email address includes an IDN but the local-part can be written in ASCII, the email address goes in the rfc822Name choice of GeneralName, which is defined as type IA5String. If the local-part can't be written in ASCII, the internationalized email address goes in the otherName choice of GeneralName, following the conventions in RFC 8398 [RFC8398]. When the host-part contains an IDN, conforming implementations MUST convert all U-labels to A-labels. 🫶

7.5.1. Local-Part Contains Only ASCII Characters 🌸

Two email addresses 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. Implementations that have a user interface SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display purposes. 👑

7.5.2. Local-Part Contains Non-ASCII Characters 🌈

When the local-part contains non-ASCII characters, conforming implementations MUST place the internationalized email address in the SmtpUTF8Mailbox within the otherName choice of GeneralName, as specified in Section 3 of RFC 8398 [RFC8398]. Note that the UTF8 encoding of the internationalized email address MUST NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid comparison. The email address local-part within the SmtpUTF8Mailbox MUST conform to the requirements of [RFC6530] and [RFC6531]. Two email addresses 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. Implementations that have a user interface SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations convert A-labels to U-labels for display purposes. 💅

3. Security Considerations 🚨

The Security Considerations related to internationalized names in Section 4 of [RFC5890] are relevant to this specification, so go read those too 🙈

Conforming Certification Authorities (CAs) SHOULD make sure that IDNs are valid according to IDNA2008, which is defined in [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], and the updates to these documents. Failing to use valid A-labels may yield a domain name that can't be correctly represented in the Domain Name System (DNS). The CA/Browser Forum also offers some guidance about internal server names in certificates [CABF]. 🔐

An earlier version of this specification [RFC8399] required conversion of A-labels to U-labels in order to process name constraints for internationalized email addresses in SmtpUTF8Mailbox other names. This led to implementation complexity and at least two security vulnerabilities 💀 Now, all IDNs are carried and processed as A-labels. Iconic redemption arc 🦋

4. IANA Considerations 🌷

This document has no IANA actions. Nothing to register, bestie ✨

5. References 📚

5.1. Normative References 💜

5.2. Informative References 🧚

Acknowledgements 🫶

Thanks to David Benjamin and Wei Chuang for identifying the issue and a solution. You two are the real MVPs 👑

Thanks to Takahiro Nemoto, John Klensin, Mike Ounsworth, and Orie Steele for their careful review and thoughtful comments. 🌸

Author's Address 💖

Russ Housley Vigil Security, LLC Herndon, VA United States of America Email: housley@vigilsec.com

📦 where this page comes from