summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8399.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8399.txt')
-rw-r--r--doc/rfc/rfc8399.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc8399.txt b/doc/rfc/rfc8399.txt
new file mode 100644
index 0000000..4c5b1ab
--- /dev/null
+++ b/doc/rfc/rfc8399.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Housley
+Request for Comments: 8399 Vigil Security
+Updates: 5280 May 2018
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Internationalization Updates to RFC 5280
+
+Abstract
+
+ The updates to RFC 5280 described in this document provide alignment
+ with the 2008 specification for Internationalized Domain Names (IDNs)
+ and add support for internationalized email addresses in X.509
+ certificates.
+
+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/rfc8399.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley Standards Track [Page 1]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+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.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, 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, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 2. Updates to RFC 5280 .............................................3
+ 2.1. Update in the Introduction (Section 1) .....................4
+ 2.2. Update in Name Constraints (Section 4.2.1.10) ..............4
+ 2.3. Update in IDNs in GeneralName (Section 7.2) ................5
+ 2.4. Update in IDNs in Distinguished Names (Section 7.3) ........6
+ 2.5. Update in Internationalized Electronic Mail
+ Addresses (Section 7.5) ....................................6
+ 3. Security Considerations .........................................7
+ 4. IANA Considerations .............................................8
+ 5. References ......................................................8
+ 5.1. Normative References .......................................8
+ 5.2. Informative References .....................................9
+ Acknowledgements ...................................................9
+ Author's Address ...................................................9
+
+
+
+
+
+
+Housley Standards Track [Page 2]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+1. Introduction
+
+ This document updates the Introduction in Section 1, the Name
+ Constraints certificate extension discussion in Section 4.2.1.10, and
+ the Processing Rules for Internationalized Names in Section 7 of RFC
+ 5280 [RFC5280] to provide alignment with the 2008 specification for
+ Internationalized Domain Names (IDNs) and add support for
+ internationalized email addresses in X.509 certificates.
+
+ An IDN in Unicode (native character) form contains at least one
+ U-label [RFC5890]. With one exception, IDNs are carried in
+ certificates in ACE-encoded form. That is, all U-labels within an
+ IDN are converted to A-labels. Conversion of a U-label to an A-label
+ is described in [RFC5891].
+
+ The GeneralName structure supports many different name forms,
+ including otherName for extensibility. RFC 8398 [RFC8398] specifies
+ the SmtpUTF8Mailbox for internationalized email addresses, which
+ includes IDNs with U-labels.
+
+ Note that Internationalized Domain Names in Applications
+ specifications published in 2003 (IDNA2003) [RFC3490] and 2008
+ (IDNA2008) [RFC5890] both refer to the Punycode algorithm for
+ conversion [RFC3492].
+
+1.1. Terminology
+
+ 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.
+
+2. Updates to RFC 5280
+
+ This section provides updates to several paragraphs of RFC 5280
+ [RFC5280]. For clarity, if the entire section is not replaced, then
+ the original text and the replacement text are shown.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley Standards Track [Page 3]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+2.1. Update in the Introduction (Section 1)
+
+ This update provides references for IDNA2008.
+
+ 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].
+
+ 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. This capability was not used, and removing it
+ allows name constraints to apply to email addresses in rfc822Name and
+ SmtpUTF8Mailbox [RFC8398] within otherName.
+
+ 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".
+
+
+
+
+
+
+
+Housley Standards Track [Page 4]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+ 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 aligns with IDNA2008. Since all of Section 7.2 is
+ replaced, the OLD text is not provided.
+
+ 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 SHOULD convert IDNs to Unicode before display.
+ Specifically, conforming implementations convert A-labels to U-labels
+ for display.
+
+
+
+
+
+
+
+Housley Standards Track [Page 5]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+ 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.
+
+2.4. Update in IDNs in Distinguished Names (Section 7.3)
+
+ This update aligns with IDNA2008.
+
+ OLD
+
+ Domain Names may also be represented as distinguished names using
+ domain components in the subject field, the issuer field, the
+ subjectAltName extension, or the issuerAltName extension. As with
+ the dNSName in the GeneralName type, the value of this attribute is
+ defined as an IA5String. Each domainComponent attribute represents a
+ single label. To represent a label from an IDN in the distinguished
+ name, the implementation MUST perform the "ToASCII" label conversion
+ specified in Section 4.1 of RFC 3490. The label SHALL be considered
+ a "stored string". That is, the AllowUnassigned flag SHALL NOT be
+ set.
+
+ NEW
+
+ Domain names may also be represented as distinguished names using
+ domain components in the subject field, the issuer field, the
+ subjectAltName extension, or the issuerAltName extension. As with
+ the dNSName in the GeneralName type, the value of this attribute is
+ defined as an IA5String. Each domainComponent attribute represents a
+ single label. To represent a label from an IDN 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 RFC 8398 [RFC8398]. Since all
+ of Section 7.5 is replaced, the OLD text is not provided.
+
+ NEW
+
+ Electronic Mail addresses may be included in certificates and CRLs in
+ the subjectAltName and issuerAltName extensions, name constraints
+ extension, authority information access extension, subject
+ information access extension, issuing distribution point extension,
+ or CRL distribution points extension. Each of these extensions uses
+ the GeneralName construct. If the email address includes an IDN but
+ the local-part of the email address can be represented in ASCII, then
+ the email address is placed in the rfc822Name choice of GeneralName,
+
+
+
+Housley Standards Track [Page 6]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+ which is defined as type IA5String. If the local-part of the
+ internationalized email address cannot be represented in ASCII, then
+ the internationalized email address is placed in the otherName choice
+ of GeneralName using the conventions in RFC 8398 [RFC8398].
+
+ 7.5.1. Local-Part Contains Only ASCII Characters
+
+ Where the host-part contains an IDN, conforming implementations MUST
+ convert all U-labels to A-labels.
+
+ 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 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.
+
+ 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 comparison of two internationalized email addresses is specified
+ in Section 5 of RFC 8398 [RFC8398].
+
+ Implementations 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.
+
+3. Security Considerations
+
+ Conforming CAs SHOULD ensure that IDNs are valid. This can be done
+ by validating all code points according to IDNA2008 [RFC5892].
+ Failure to use valid A-labels and valid U-labels may yield a domain
+ name that cannot be correctly represented in the Domain Name System
+ (DNS). In addition, the CA/Browser Forum offers some guidance
+ regarding internal server names in certificates [CABF].
+
+
+
+
+Housley Standards Track [Page 7]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+4. IANA Considerations
+
+ This document has no IANA actions.
+
+5. References
+
+5.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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications
+ (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
+ <https://www.rfc-editor.org/info/rfc3492>.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+ 2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
+ January 2005, <https://www.rfc-editor.org/info/rfc3987>.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC 4518,
+ DOI 10.17487/RFC4518, June 2006,
+ <https://www.rfc-editor.org/info/rfc4518>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, DOI 10.17487/RFC5890, August 2010,
+ <https://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC5891] Klensin, J., "Internationalized Domain Names in
+ Applications (IDNA): Protocol", RFC 5891,
+ DOI 10.17487/RFC5891, August 2010,
+ <https://www.rfc-editor.org/info/rfc5891>.
+
+
+
+
+
+Housley Standards Track [Page 8]
+
+RFC 8399 I18n Updates to RFC 5280 May 2018
+
+
+ [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
+ Internationalized Domain Names for Applications (IDNA)",
+ RFC 5892, DOI 10.17487/RFC5892, August 2010,
+ <https://www.rfc-editor.org/info/rfc5892>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized
+ Email Addresses in X.509 Certificates",
+ DOI 10.17487/RFC8398, May 2016,
+ <http://www.rfc-editor.org/info/rfc8398>.
+
+5.2. Informative References
+
+ [CABF] CA/Browser Forum, "Internal Server Names and IP Address
+ Requirements for SSL: Guidance on the Deprecation of
+ Internal Server Names and Reserved IP Addresses provided
+ by the CA/Browser Forum", Version 1.0, June 2012,
+ <https://cabforum.org/internal-names/>.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, DOI 10.17487/RFC3490, March 2003,
+ <https://www.rfc-editor.org/info/rfc3490>.
+
+Acknowledgements
+
+ Thanks to Alexey Melnikov for the encouragement to write this update.
+ Thanks to John Klensin and Patrik Falstrom for confirming many of the
+ details in this update. Thanks to Ben Campbell, Wei Chuang, Spencer
+ Dawkins, Phillip Hallam-Baker, Warren Kumari, Alexey Melnikov, Adam
+ Roach, Tim Ruehsen, and Sean Turner for their careful review and
+ comments.
+
+Author's Address
+
+ Russ Housley
+ Vigil Security, LLC
+ 918 Spring Knoll Drive
+ Herndon, VA 20170
+ United States of America
+
+ Email: housley@vigilsec.com
+
+
+
+
+
+
+Housley Standards Track [Page 9]
+