From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8398.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc8398.txt (limited to 'doc/rfc/rfc8398.txt') diff --git a/doc/rfc/rfc8398.txt b/doc/rfc/rfc8398.txt new file mode 100644 index 0000000..e474bcb --- /dev/null +++ b/doc/rfc/rfc8398.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Melnikov, Ed. +Request for Comments: 8398 Isode Ltd +Updates: 5280 W. Chuang, Ed. +Category: Standards Track Google, Inc. +ISSN: 2070-1721 May 2018 + + + Internationalized Email Addresses in X.509 Certificates + +Abstract + + This document defines a new name form for inclusion in the otherName + field of an X.509 Subject Alternative Name and Issuer Alternative + Name extension that allows a certificate subject to be associated + with an internationalized email address. + + This document updates RFC 5280. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8398. + +Copyright Notice + + Copyright (c) 2018 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Melnikov & Chuang Standards Track [Page 1] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 + 3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 3 + 4. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Matching of Internationalized Email Addresses in X.509 + Certificates . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Name Constraints in Path Validation . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . 9 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 + Appendix B. Example of SmtpUTF8Mailbox . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + [RFC5280] defines the rfc822Name subjectAltName name type for + representing email addresses as described in [RFC5321]. The syntax + of rfc822Name is restricted to a subset of US-ASCII characters and + thus can't be used to represent internationalized email addresses + [RFC6531]. This document defines a new otherName variant to + represent internationalized email addresses. In addition this + document requires all email address domains in X.509 certificates to + conform to IDNA2008 [RFC5890]. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The formal syntax uses the Augmented Backus-Naur Form (ABNF) + [RFC5234] notation. + + + + + + + + + + + +Melnikov & Chuang Standards Track [Page 2] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +3. Name Definitions + + The GeneralName structure is defined in [RFC5280] and supports many + different name forms including otherName for extensibility. This + section specifies the SmtpUTF8Mailbox name form of otherName so that + internationalized email addresses can appear in the subjectAltName of + a certificate, the issuerAltName of a certificate, or anywhere else + that GeneralName is used. + + id-on-SmtpUTF8Mailbox OBJECT IDENTIFIER ::= { id-on 9 } + + SmtpUTF8Mailbox ::= UTF8String (SIZE (1..MAX)) + -- SmtpUTF8Mailbox conforms to Mailbox as specified + -- in Section 3.3 of RFC 6531. + + 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. + The format of SmtpUTF8Mailbox is defined as the ABNF rule + SmtpUTF8Mailbox. SmtpUTF8Mailbox is a modified version of the + internationalized Mailbox that was defined in Section 3.3 of + [RFC6531], which was derived from Mailbox as defined in Section 4.1.2 + of [RFC5321]. [RFC6531] defines the following ABNF rules for Mailbox + whose parts are modified for internationalization: , + , , , , and . + In particular, was updated to also support UTF8-non- + ascii. UTF8-non-ascii was described by Section 3.1 of [RFC6532]. + Also, domain was extended to support U-labels, as defined in + [RFC5890]. + + This document further refines internationalized Mailbox ABNF rules as + described in [RFC6531] and calls this SmtpUTF8Mailbox. In + SmtpUTF8Mailbox, labels that include non-ASCII characters MUST be + stored in U-label (rather than A-label) form [RFC5890]. This + restriction removes the need to determine which label encoding, A- or + U-label, is present in the domain. As per Section 2.3.2.1 of + [RFC5890], U-labels are encoded as UTF-8 [RFC3629] in Normalization + Form C and other properties specified there. In SmtpUTF8Mailbox, + domain labels that solely use ASCII characters (meaning neither A- + nor U-labels) SHALL use NR-LDH restrictions as specified by + Section 2.3.1 of [RFC5890] and SHALL be restricted to lowercase + letters. NR-LDH stands for "Non-Reserved Letters Digits Hyphen" and + is the set of LDH labels that do not have "--" characters in the + third and forth character position, which excludes "tagged domain + names" such as A-labels. Consistent with the treatment of rfc822Name + in [RFC5280], SmtpUTF8Mailbox is an envelope and has no + + + + + +Melnikov & Chuang Standards Track [Page 3] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + + phrase (such as a common name) before it, has no comment (text + surrounded in parentheses) after it, and is not surrounded by "<" and + ">" characters. + + Due to name constraint compatibility reasons described in Section 6, + SmtpUTF8Mailbox subjectAltName 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 of + SmtpUTF8Mailbox. This is compatible with legacy software that + supports only rfc822Name (and not SmtpUTF8Mailbox). The appropriate + usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1 + below. + + SmtpUTF8Mailbox is encoded as UTF8String. The UTF8String encoding + MUST NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid consistency + across implementations, particularly for comparison. + + +-----------------+-------------+--------------+-----------------+ + | local-part char | domain char | domain label | subjectAltName | + +-----------------+-------------+--------------+-----------------+ + | ASCII-only | ASCII-only | NR-LDH label | rfc822Name | + | non-ASCII | ASCII-only | NR-LDH label | SmtpUTF8Mailbox | + | ASCII-only | non-ASCII | A-label | rfc822Name | + | non-ASCII | non-ASCII | U-label | SmtpUTF8Mailbox | + +-----------------+-------------+--------------+-----------------+ + + Non-ASCII may additionally include ASCII characters. + + Table 1: Email Address Formatting + +4. IDNA2008 + + To facilitate comparison between email addresses, all email address + domains in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and + avoid any "mappings" mentioned in that document). Use of + non-conforming email address domains introduces the possibility of + conversion errors between alternate forms. This applies to + SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName, and + anywhere else that these are used. + +5. Matching of Internationalized Email Addresses in X.509 Certificates + + In equivalence comparison with SmtpUTF8Mailbox, there may be some + setup work on one or both inputs depending on whether the input is + already in comparison form. Comparing SmtpUTF8Mailboxes consists of + a domain part step and a local-part step. The comparison form for + local-parts is always UTF-8. The comparison form for domain parts + depends on context. While some contexts such as certificate path + + + +Melnikov & Chuang Standards Track [Page 4] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + + validation in [RFC5280] specify transforming domain to A-label + (Sections 7.2 and 7.5 in [RFC5280] as updated by [RFC8399]), this + document recommends transforming to UTF-8 U-label instead. This + reduces the likelihood of errors by reducing conversions as more + implementations natively support U-label domains. + + Comparison of two SmtpUTF8Mailboxes is straightforward with no setup + work needed. They are considered equivalent if there is an exact + octet-for-octet match. Comparison with email addresses such as + internationalized email address or rfc822Name requires additional + setup steps for domain part and local-part. The initial preparation + for the email addresses is to remove any phrases, comments, and "<" + or ">" characters. This document calls for comparison of domain + labels that include non-ASCII characters to be transformed to + U-labels if not already in that form. The first step is to detect + use of the A-label by using Section 5.1 of [RFC5891]. Next, if + necessary, transform any A-labels (US-ASCII) to U-labels (Unicode) as + specified in Section 5.2 of [RFC5891]. Finally, if necessary, + convert the Unicode to UTF-8 as specified in Section 3 of [RFC3629]. + For ASCII NR-LDH labels, uppercase letters are converted to lowercase + letters. In setup for SmtpUTF8Mailbox, the email address local-part + MUST conform to the requirements of [RFC6530] and [RFC6531], + including being a string in UTF-8 form. In particular, the local- + part MUST NOT be transformed in any way, such as by doing case + folding or normalization of any kind. The part of an + internationalized email address is already in UTF-8. For rfc822Name, + the local-part, which is IA5String (ASCII), trivially maps to UTF-8 + without change. Once setup is complete, they are again compared + octet for octet. + + To summarize non-normatively, the comparison steps, including setup, + are: + + 1. If the domain contains A-labels, transform them to U-labels. + + 2. If the domain contains ASCII NR-LDH labels, lowercase them. + + 3. Compare strings octet for octet for equivalence. + + This specification expressly does not define any wildcard characters, + and SmtpUTF8Mailbox comparison implementations MUST NOT interpret any + characters as wildcards. Instead, to specify multiple email + addresses through SmtpUTF8Mailbox, the certificate MUST use multiple + subjectAltNames or issuerAltNames to explicitly carry any additional + email addresses. + + + + + + +Melnikov & Chuang Standards Track [Page 5] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +6. Name Constraints in Path Validation + + This section updates Section 4.2.1.10 of [RFC5280] to extend + rfc822Name name constraints to SmtpUTF8Mailbox subjectAltNames. + SmtpUTF8Mailbox-aware path validators will apply name constraint + comparison to the subject distinguished name and both forms of + subject alternative names rfc822Name and SmtpUTF8Mailbox. + + Both rfc822Name and SmtpUTF8Mailbox subject alternative names + represent the same underlying email address namespace. Since legacy + CAs constrained to issue certificates for a specific set of domains + would lack corresponding UTF-8 constraints, [RFC8399] updates, + modifies, and extends rfc822Name name constraints defined in + [RFC5280] to cover SmtpUTF8Mailbox subject alternative names. This + ensures that the introduction of SmtpUTF8Mailbox does not violate + existing name constraints. Since it is not valid to include + non-ASCII UTF-8 characters in the local-part of rfc822Name name + constraints, and since name constraints that include a local-part are + rarely, if at all, used in practice, name constraints updated in + [RFC8399] allow the forms that represent all addresses at a host or + all mailboxes in a domain and deprecates rfc822Name name constraints + that represent a particular mailbox. That is, rfc822Name constraints + with a local-part SHOULD NOT be used. + + Constraint comparison with SmtpUTF8Mailbox subjectAltName starts with + the setup steps defined by Section 5. Setup converts the inputs of + the comparison (which is one of a subject distinguished name, an + rfc822Name, or an SmtpUTF8Mailbox subjectAltName, and one of an + rfc822Name name constraint) to constraint comparison form. For an + rfc822Name name constraint, this will convert any domain A-labels to + U-labels. For both the name constraint and the subject, this will + lowercase any domain NR-LDH labels. Strip the local-part and "@" + separator from each rfc822Name and SmtpUTF8Mailbox, leaving just the + domain part. After setup, this follows the comparison steps defined + in Section 4.2.1.10 of [RFC5280] as follows. If the resulting name + constraint domain starts with a "." character, then for the name + constraint to match, a suffix of the resulting subject alternative + name domain MUST match the name constraint (including the leading + ".") octet for octet. If the resulting name constraint domain does + not start with a "." character, then for the name constraint to + match, the entire resulting subject alternative name domain MUST + match the name constraint octet for octet. + + 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. + + + + +Melnikov & Chuang Standards Track [Page 6] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + + The name constraint requirement with SmtpUTF8Mailbox subject + alternative name is illustrated in the non-normative diagram in + Figure 1. The first example (1) illustrates a permitted rfc822Name + ASCII-only host name name constraint and the corresponding valid + rfc822Name subjectAltName and SmtpUTF8Mailbox subjectAltName email + addresses. The second example (2) illustrates a permitted rfc822Name + host name name constraint with A-label, and the corresponding valid + rfc822Name subjectAltName and SmtpUTF8Mailbox subjectAltName email + addresses. Note that an email address with ASCII-only local-part is + encoded as rfc822Name despite also having Unicode present in the + domain. + + +-------------------------------------------------------------------+ + | Root CA Cert | + +-------------------------------------------------------------------+ + | + v + +-------------------------------------------------------------------+ + | Intermediate CA Cert | + | Permitted | + | rfc822Name: elementary.school.example.com (1) | + | | + | rfc822Name: xn--pss25c.example.com (2) | + | | + +-------------------------------------------------------------------+ + | + v + +-------------------------------------------------------------------+ + | Entity Cert (w/explicitly permitted subjects) | + | SubjectAltName Extension | + | rfc822Name: student@elemenary.school.example.com (1) | + | SmtpUTF8Mailbox: u+5B66u+751F@elementary.school.example.com | + | (1) | + | | + | rfc822Name: student@xn--pss25c.example.com (2) | + | SmtpUTF8Mailbox: u+533Bu+751F@u+5927u+5B66.example.com (2) | + | | + +-------------------------------------------------------------------+ + + Figure 1: Name Constraints with SmtpUTF8Name and rfc822Name + +7. Security Considerations + + Use of SmtpUTF8Mailbox for certificate subjectAltName (and + issuerAltName) will incur many of the same security considerations as + in Section 8 in [RFC5280], but it introduces a new issue by + permitting non-ASCII characters in the email address local-part. + This issue, as mentioned in Section 4.4 of [RFC5890] and in Section 4 + + + +Melnikov & Chuang Standards Track [Page 7] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + + of [RFC6532], is that use of Unicode introduces the risk of visually + similar and identical characters that can be exploited to deceive the + recipient. The former document references some means to mitigate + against these attacks. See [WEBER] for more background on security + issues with Unicode. + +8. IANA Considerations + + As described in Section 3 and the ASN.1 module identifier defined in + Appendix A, IANA has assigned the values described here. + + o For the LAMPS-EaiAddresses-2016 ASN.1 module, IANA has registered + value 92 for "id-mod-lamps-eai-addresses-2016" in the "SMI + Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. + + o For the SmtpUTF8Mailbox otherName, IANA has registered value 9 for + id-on-SmtpUTF8Mailbox in the "SMI Security for PKIX Other Name + Forms" (1.3.6.1.5.5.7.8) registry. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + . + + + + + +Melnikov & Chuang Standards Track [Page 8] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + . + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for + Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, + February 2012, . + + [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized + Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, + . + + [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized + Email Headers", RFC 6532, DOI 10.17487/RFC6532, February + 2012, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8399] Housley, R., "Internationalization Updates to RFC 5280", + RFC 8399, DOI 10.17487/RFC8399, May 2018, + . + +9.2. Informative References + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, + DOI 10.17487/RFC5912, June 2010, + . + + [WEBER] Weber, C., "Attacking Software Globalization", March 2010, + . + + + + + + + + + + + +Melnikov & Chuang Standards Track [Page 9] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +Appendix A. ASN.1 Module + + The following ASN.1 module normatively specifies the SmtpUTF8Mailbox + structure. This specification uses the ASN.1 definitions from + [RFC5912] with the 2002 ASN.1 notation used in that document. + [RFC5912] updates normative documents using older ASN.1 notation. + + LAMPS-EaiAddresses-2016 + { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-lamps-eai-addresses-2016(92) } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + OTHER-NAME + FROM PKIX1Implicit-2009 + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } + + id-pkix + FROM PKIX1Explicit-2009 + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; + + -- + -- otherName carries additional name types for subjectAltName, + -- issuerAltName, and other uses of GeneralNames. + -- + + id-on OBJECT IDENTIFIER ::= { id-pkix 8 } + + SmtpUtf8OtherNames OTHER-NAME ::= { on-SmtpUTF8Mailbox, ... } + + on-SmtpUTF8Mailbox OTHER-NAME ::= { + SmtpUTF8Mailbox IDENTIFIED BY id-on-SmtpUTF8Mailbox + } + + id-on-SmtpUTF8Mailbox OBJECT IDENTIFIER ::= { id-on 9 } + + SmtpUTF8Mailbox ::= UTF8String (SIZE (1..MAX)) + -- SmtpUTF8Mailbox conforms to Mailbox as specified + -- in Section 3.3 of RFC 6531. + + END + + + + + +Melnikov & Chuang Standards Track [Page 10] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +Appendix B. Example of SmtpUTF8Mailbox + + This non-normative example demonstrates using SmtpUTF8Mailbox as an + otherName in GeneralName to encode the email address + "u+8001u+5E2B@example.com". + + The hexadecimal DER encoding of the email address is: + A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 + 6D706C65 2E636F6D + + The text decoding is: + 0 34: [0] { + 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' + 14 20: [0] { + 16 18: UTF8String '..@example.com' + : } + : } + + Figure 2 + + The example was encoded on the OSS Nokalva ASN.1 Playground and the + above text decoding is an output of Peter Gutmann's "dumpasn1" + program. + +Acknowledgements + + Thank you to Magnus Nystrom for motivating this document. Thanks to + Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean + Leonard, Sean Turner, John Levine, and Patrik Falstrom for their + feedback. Also special thanks to John Klensin for his valuable input + on internationalization, Unicode, and ABNF formatting; to Jim Schaad + for his help with the ASN.1 example and his helpful feedback; and + especially to Viktor Dukhovni for helping us with name constraints + and his many detailed document reviews. + + + + + + + + + + + + + + + + + +Melnikov & Chuang Standards Track [Page 11] + +RFC 8398 I18N Mail Addresses in X.509 Certificates May 2018 + + +Authors' Addresses + + Alexey Melnikov (editor) + Isode Ltd + 14 Castle Mews + Hampton, Middlesex TW12 2NP + United Kingdom + + Email: Alexey.Melnikov@isode.com + + + Weihaw Chuang (editor) + Google, Inc. + 1600 Amphitheater Parkway + Mountain View, CA 94043 + United States of America + + Email: weihaw@google.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Chuang Standards Track [Page 12] + -- cgit v1.2.3