--- 1/draft-ietf-lamps-rfc5280-i18n-update-03.txt 2017-10-12 12:13:08.873682470 -0700 +++ 2/draft-ietf-lamps-rfc5280-i18n-update-04.txt 2017-10-12 12:13:08.893682950 -0700 @@ -1,25 +1,25 @@ INTERNET-DRAFT Internet Engineering Task Force R. Housley Intended Status: Proposed Standard Vigil Security Updates: 5280 (once approved) -Expires: 4 March 2018 4 September 2017 +Expires: 12 April 2018 12 October 2017 Internationalization Updates to RFC 5280 - draft-ietf-lamps-rfc5280-i18n-update-03 + draft-ietf-lamps-rfc5280-i18n-update-04 Abstract - These updates to RFC 5280 provide clarity on the handling of - Internationalized Domain Names (IDNs) and Internationalized Email - Addresses in X.509 Certificates. + These updates to RFC 5280 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 Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -60,45 +60,47 @@ 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. 1. Introduction This document updates RFC 5280 [RFC5280]. 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 are updated to provide clarity on the handling of - Internationalized Domain Names (IDNs) and Internationalized Email - Addresses in X.509 Certificates. + Names in Section 7 are updated 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 an U-label to an A-label is described in [RFC5891]. The GeneralName structure supports many different names forms, including otherName for extensibility. [ID.lamps-eai-addresses] specifies the SmtpUTF8Mailbox for Internationalized Email addresses, which include 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", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + "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 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. 2.1. Update in Section 1, Introduction This update provides references for IDNA2008. @@ -179,28 +181,28 @@ 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 should convert A-labels to - U-labels for display. + Implementations SHOULD convert IDNs to Unicode before display. + Specifically, conforming implementations convert A-labels to U-labels + for display. - Note: Implementations MUST allow for increased space requirements - for IDNs. An IDN ACE label will begin with the four additional - characters "xn--" and may require as many as five ASCII characters to - specify a single international character. + 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.3. Update in Section 7.3, IDNs in Distinguished Names 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 @@ -247,46 +249,46 @@ 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 + Implementations SHOULD convert the host-part of internationalized email addresses specified in these extensions to Unicode before - display. Specifically, conforming implementations should convert - A-labels to U-labels for display. + 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 character, conforming implementations MUST place the internationalized email address in the SmtpUTF8Mailbox within the otherName choice of GeneralName as specified in Section 3 of [ID.lamps-eai-addresses]. 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 [ID.lamps-eai-addresses]. - Implementations should convert the local-part and the host-part of - internationalized email addresses placed in these extensions to - Unicode before display. + 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]. 4. IANA Considerations No IANA registries are changed by this update. 5. Normative References @@ -295,20 +297,29 @@ Melnikov, A. (Ed.) and W. Chuang (Ed.), "Internationalized Email Addresses in X.509 certificates", September 2017, , work-in-progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications + (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, . [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, DOI 10.17487/RFC4518, June 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., @@ -325,47 +336,43 @@ [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017. . + 6. Informative References [CABF] CA/Browser Forum, "Internal Server Names and IP Address Requirements for SSL", Version 1.0, June 2012, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, . - [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications - (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, - . - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November - 2003, . - 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 Wei Chuang, Phillip Hallam-Baker, - Alexey Melnikov, Tim Ruehsen, and Sean Turner for their careful - review and comments. + 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. Authors' Address Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com