idnits 2.17.1 draft-ietf-lamps-rfc5280-i18n-update-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5280, but the abstract doesn't seem to directly say this. It does mention RFC5280 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5280, updated by this document, for RFC5378 checks: 2005-04-15) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 October 2017) is 2387 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.lamps-eai-addresses' -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 Internet Engineering Task Force R. Housley 4 Intended Status: Proposed Standard Vigil Security 5 Updates: 5280 (once approved) 6 Expires: 12 April 2018 12 October 2017 8 Internationalization Updates to RFC 5280 9 draft-ietf-lamps-rfc5280-i18n-update-04 11 Abstract 13 These updates to RFC 5280 provide alignment with the 2008 14 specification for Internationalized Domain Names (IDNs) and add 15 support for Internationalized Email Addresses in X.509 Certificates. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 1. Introduction 67 This document updates RFC 5280 [RFC5280]. The Introduction in 68 Section 1, the Name Constraints certificate extension discussion in 69 Section 4.2.1.10, and the Processing Rules for Internationalized 70 Names in Section 7 are updated to provide alignment with the 2008 71 specification for Internationalized Domain Names (IDNs) and add 72 support for Internationalized Email Addresses in X.509 Certificates. 74 An IDN in Unicode (native character) form contains at least one 75 U-label [RFC5890]. With one exception, IDNs are carried in 76 certificates in ACE-encoded form. That is, all U-labels within an 77 IDN are converted to A-labels. Conversion of an U-label to an 78 A-label is described in [RFC5891]. 80 The GeneralName structure supports many different names forms, 81 including otherName for extensibility. [ID.lamps-eai-addresses] 82 specifies the SmtpUTF8Mailbox for Internationalized Email addresses, 83 which include IDNs with U-labels. 85 Note that Internationalized Domain Names in Applications 86 specifications published in 2003 (IDNA2003) [RFC3490] and 2008 87 (IDNA2008) [RFC5890] both refer to the Punycode Algorithm for 88 conversion [RFC3492]. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 2. Updates 100 This section provides updates to several paragraphs of RFC 5280 101 [RFC5280]. For clarity, if the entire section is not replaced, then 102 the original text and the replacement text are shown. 104 2.1. Update in Section 1, Introduction 106 This update provides references for IDNA2008. 108 OLD 110 * Enhanced support for internationalized names is specified in 111 Section 7, with rules for encoding and comparing 112 Internationalized Domain Names, Internationalized Resource 113 Identifiers (IRIs), and distinguished names. These rules are 114 aligned with comparison rules established in current RFCs, 115 including [RFC3490], [RFC3987], and [RFC4518]. 117 NEW 119 * Enhanced support for internationalized names is specified in 120 Section 7, with rules for encoding and comparing 121 Internationalized Domain Names, Internationalized Resource 122 Identifiers (IRIs), and distinguished names. These rules are 123 aligned with comparison rules established in current RFCs, 124 including [RFC3987], [RFC4518], [RFC5890], and [RFC5891]. 126 2.2. Update in Section 4.2.1.10, Name Constraints 128 This update removes the ability to include constraints for a 129 particular mailbox. This capability was not used, and removing it 130 allows name constraints to apply to email addresses in rfc822Name and 131 SmtpUTF8Mailbox [ID.lamps-eai-addresses] within otherName. 133 OLD 135 A name constraint for Internet mail addresses MAY specify a 136 particular mailbox, all addresses at a particular host, or all 137 mailboxes in a domain. To indicate a particular mailbox, the 138 constraint is the complete mail address. For example, 139 "root@example.com" indicates the root mailbox on the host 140 "example.com". To indicate all Internet mail addresses on a 141 particular host, the constraint is specified as the host name. For 142 example, the constraint "example.com" is satisfied by any mail 143 address at the host "example.com". To specify any address within a 144 domain, the constraint is specified with a leading period (as with 145 URIs). For example, ".example.com" indicates all the Internet mail 146 addresses in the domain "example.com", but not Internet mail 147 addresses on the host "example.com". 149 NEW 151 A name constraint for Internet mail addresses MAY specify all 152 addresses at a particular host or all mailboxes in a domain. To 153 indicate all Internet mail addresses on a particular host, the 154 constraint is specified as the host name. For example, the 155 constraint "example.com" is satisfied by any mail address at the 156 host "example.com". To specify any address within a domain, the 157 constraint is specified with a leading period (as with URIs). For 158 example, ".example.com" indicates all the Internet mail addresses 159 in the domain "example.com", but not Internet mail addresses on 160 the host "example.com". 162 2.3. Update in Section 7.2, IDNs in GeneralName 164 This update aligns with IDNA2008. Since all of Section 7.2 is 165 replaced, the OLD text is not provided. 167 NEW 169 Internationalized Domain Names (IDNs) may be included in certificates 170 and CRLs in the subjectAltName and issuerAltName extensions, name 171 constraints extension, authority information access extension, 172 subject information access extension, CRL distribution points 173 extension, and issuing distribution point extension. Each of these 174 extensions uses the GeneralName type; one choice in GeneralName is 175 the dNSName field, which is defined as type IA5String. 177 IA5String is limited to the set of ASCII characters. To accommodate 178 internationalized domain names U-labels are converted to A-labels. 179 The A-label is the encoding of the U-label according to the Punycode 180 algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning 181 of the string. 183 When comparing DNS names for equality, conforming implementations 184 MUST perform a case-insensitive exact match on the entire DNS name. 185 When evaluating name constraints, conforming implementations MUST 186 perform a case-insensitive exact match on a label-by-label basis. As 187 noted in Section 4.2.1.10, any DNS name that may be constructed by 188 adding labels to the left-hand side of the domain name given as the 189 constraint is considered to fall within the indicated subtree. 191 Implementations SHOULD convert IDNs to Unicode before display. 192 Specifically, conforming implementations convert A-labels to U-labels 193 for display. 195 Implementation consideration: There are increased memory 196 requirements for IDNs. An IDN ACE label will begin with the four 197 additional characters "xn--", and an IDN can require as many as five 198 ASCII characters to specify a single international character. 200 2.3. Update in Section 7.3, IDNs in Distinguished Names 202 This update aligns with IDNA2008. 204 OLD 206 Domain Names may also be represented as distinguished names using 207 domain components in the subject field, the issuer field, the 208 subjectAltName extension, or the issuerAltName extension. As with 209 the dNSName in the GeneralName type, the value of this attribute is 210 defined as an IA5String. Each domainComponent attribute represents a 211 single label. To represent a label from an IDN in the distinguished 212 name, the implementation MUST perform the "ToASCII" label conversion 213 specified in Section 4.1 of RFC 3490. The label SHALL be considered 214 a "stored string". That is, the AllowUnassigned flag SHALL NOT be 215 set. 217 NEW 219 Domain Names may also be represented as distinguished names using 220 domain components in the subject field, the issuer field, the 221 subjectAltName extension, or the issuerAltName extension. As with 222 the dNSName in the GeneralName type, the value of this attribute is 223 defined as an IA5String. Each domainComponent attribute represents a 224 single label. To represent a label from an IDN in the distinguished 225 name, the implementation MUST convert all U-labels to A-labels. 227 2.4. Update in Section 7.5, Internationalized Electronic Mail Addresses 229 This update aligns with IDNA2008 and [ID.lamps-eai-addresses]. Since 230 all of Section 7.5 is replaced, the OLD text is not provided. 232 NEW 234 Electronic Mail addresses may be included in certificates and CRLs in 235 the subjectAltName and issuerAltName extensions, name constraints 236 extension, authority information access extension, subject 237 information access extension, issuing distribution point extension, 238 or CRL distribution points extension. Each of these extensions uses 239 the GeneralName construct. If the email address includes an IDN but 240 the local-part of the email address can be represented in ASCII, then 241 the email address is placed in the rfc822Name choice of GeneralName, 242 which is defined as type IA5String. If the local-part of the 243 internationalized email address cannot be represented in ASCII, then 244 the internationalized email address is placed in the otherName choice 245 of GeneralName using the conventions in [ID.lamps-eai-addresses]. 247 7.5.1. Local-part Contains Only ASCII Characters 249 Where the host-part contains an IDN, conforming implementations MUST 250 convert all U-labels to A-labels. 252 Two email addresses are considered to match if: 254 1) the local-part of each name is an exact match, AND 256 2) the host-part of each name matches using a case-insensitive 257 ASCII comparison. 259 Implementations SHOULD convert the host-part of internationalized 260 email addresses specified in these extensions to Unicode before 261 display. Specifically, conforming implementations convert A-labels 262 to U-labels for display. 264 7.5.2. Local-part Contains Non-ASCII Characters 266 When the local-part contains non-ASCII character, conforming 267 implementations MUST place the internationalized email address in the 268 SmtpUTF8Mailbox within the otherName choice of GeneralName as 269 specified in Section 3 of [ID.lamps-eai-addresses]. Note that the 270 UTF8 encoding of the internationalized email address MUST NOT contain 271 a Byte-Order-Mark (BOM) [RFC3629] to aid comparison. 273 The comparison of two internationalized email addresses is specified 274 in Section 5 of [ID.lamps-eai-addresses]. 276 Implementations SHOULD convert the host-part of internationalized 277 email addresses specified in these extensions to Unicode before 278 display. Specifically, conforming implementations convert A-labels 279 to U-labels for display. 281 3. Security Considerations 283 Conforming CAs SHOULD ensure that IDNs are valid. This can be done 284 by validating all code points according to IDNA2008 [RFC5892]. 285 Failure to use valid A-labels and valid U-labels may yield a domain 286 name that cannot be correctly represented in the Domain Name System 287 (DNS). In addition, the CA/Browser Forum offers some guidance 288 regarding internal server names in certificates [CABF]. 290 4. IANA Considerations 292 No IANA registries are changed by this update. 294 5. Normative References 296 [ID.lamps-eai-addresses] 297 Melnikov, A. (Ed.) and W. Chuang (Ed.), 298 "Internationalized Email Addresses in X.509 certificates", 299 September 2017, , work-in-progress. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, DOI 304 10.17487/RFC2119, March 1997, . 307 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 308 for Internationalized Domain Names in Applications 309 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 310 . 312 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 313 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 314 2003, . 316 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 317 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 318 January 2005, . 320 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 321 (LDAP): Internationalized String Preparation", RFC 4518, 322 DOI 10.17487/RFC4518, June 2006, . 325 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 326 Housley, R., and W. Polk, "Internet X.509 Public Key 327 Infrastructure Certificate and Certificate Revocation List 328 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 329 . 331 [RFC5890] Klensin, J., "Internationalized Domain Names for 332 Applications (IDNA): Definitions and Document Framework", 333 RFC 5890, DOI 10.17487/RFC5890, August 2010, 334 . 336 [RFC5891] Klensin, J., "Internationalized Domain Names in 337 Applications (IDNA): Protocol", RFC 5891, DOI 338 10.17487/RFC5891, August 2010, . 341 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 342 Internationalized Domain Names for Applications (IDNA)", 343 RFC 5892, DOI 10.17487/RFC5892, August 2010, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017. . 350 6. Informative References 352 [CABF] CA/Browser Forum, "Internal Server Names and IP Address 353 Requirements for SSL", Version 1.0, June 2012, 354 356 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 357 "Internationalizing Domain Names in Applications (IDNA)", 358 RFC 3490, DOI 10.17487/RFC3490, March 2003, 359 . 361 Acknowledgements 363 Thanks to Alexey Melnikov for the encouragement to write this update. 364 Thanks to John Klensin and Patrik Falstrom for confirming many of the 365 details in this update. Thanks to Ben Campbell, Wei Chuang, Spencer 366 Dawkins, Phillip Hallam-Baker, Warren Kumari, Alexey Melnikov, Adam 367 Roach, Tim Ruehsen, and Sean Turner for their careful review and 368 comments. 370 Authors' Address 372 Russ Housley 373 Vigil Security, LLC 374 918 Spring Knoll Drive 375 Herndon, VA 20170 376 USA 378 EMail: housley@vigilsec.com