idnits 2.17.1 draft-ietf-lamps-rfc5280-i18n-update-02.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 (23 June 2017) is 2493 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: 23 December 2017 23 June 2017 8 Internationalization Updates to RFC 5280 9 draft-ietf-lamps-rfc5280-i18n-update-02 11 Abstract 13 These updates to RFC 5280 provide clarity on the handling of 14 Internationalized Domain Names (IDNs) and Internationalized Email 15 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 clarity on the handling of 71 Internationalized Domain Names (IDNs) and Internationalized Email 72 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 SmtpUTF8Name 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", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Updates 98 This section provides updates to several paragraphs of RFC 5280 99 [RFC5280]. For clarity, if the entire section is not replace, then 100 the original text and the replacement text are shown. 102 2.1. Update in Section 1, Introduction 104 This update includes references for IDNA2008. 106 OLD 108 * Enhanced support for internationalized names is specified in 109 Section 7, with rules for encoding and comparing 110 Internationalized Domain Names, Internationalized Resource 111 Identifiers (IRIs), and distinguished names. These rules are 112 aligned with comparison rules established in current RFCs, 113 including [RFC3490], [RFC3987], and [RFC4518]. 115 NEW 117 * Enhanced support for internationalized names is specified in 118 Section 7, with rules for encoding and comparing 119 Internationalized Domain Names, Internationalized Resource 120 Identifiers (IRIs), and distinguished names. These rules are 121 aligned with comparison rules established in current RFCs, 122 including [RFC3987], [RFC4518], [RFC5890], and [RFC5891]. 124 2.2. Update in Section 4.2.1.10, Name Constraints 126 This update removes the ability to include constraints for a 127 particular mailbox. This capability was not used, and removing it 128 allows name constraints to apply to email addresses in rfc822Name and 129 SmtpUTF8Name within otherName. 131 OLD 133 A name constraint for Internet mail addresses MAY specify a 134 particular mailbox, all addresses at a particular host, or all 135 mailboxes in a domain. To indicate a particular mailbox, the 136 constraint is the complete mail address. For example, 137 "root@example.com" indicates the root mailbox on the host 138 "example.com". To indicate all Internet mail addresses on a 139 particular host, the constraint is specified as the host name. For 140 example, the constraint "example.com" is satisfied by any mail 141 address at the host "example.com". To specify any address within a 142 domain, the constraint is specified with a leading period (as with 143 URIs). For example, ".example.com" indicates all the Internet mail 144 addresses in the domain "example.com", but not Internet mail 145 addresses on the host "example.com". 147 NEW 149 A name constraint for Internet mail addresses MAY specify all 150 addresses at a particular host or all mailboxes in a domain. To 151 indicate all Internet mail addresses on a particular host, the 152 constraint is specified as the host name. For example, the 153 constraint "example.com" is satisfied by any mail address at the 154 host "example.com". To specify any address within a domain, the 155 constraint is specified with a leading period (as with URIs). For 156 example, ".example.com" indicates all the Internet mail addresses 157 in the domain "example.com", but not Internet mail addresses on 158 the host "example.com". 160 2.3. Update in Section 7.2, IDNs in GeneralName 162 This update aligns with IDNA2008. Since all of Section 7.2 is 163 replaced, the OLD text is not provided. 165 NEW 167 Internationalized Domain Names (IDNs) may be included in certificates 168 and CRLs in the subjectAltName and issuerAltName extensions, name 169 constraints extension, authority information access extension, 170 subject information access extension, CRL distribution points 171 extension, and issuing distribution point extension. Each of these 172 extensions uses the GeneralName type; one choice in GeneralName is 173 the dNSName field, which is defined as type IA5String. 175 IA5String is limited to the set of ASCII characters. To accommodate 176 internationalized domain names U-labels are converted to A-labels. 177 The A-label is the encoding of the U-label according to the Punycode 178 algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning 179 of the string. 181 When comparing DNS names for equality, conforming implementations 182 MUST perform a case-insensitive exact match on the entire DNS name. 183 When evaluating name constraints, conforming implementations MUST 184 perform a case-insensitive exact match on a label-by-label basis. As 185 noted in Section 4.2.1.10, any DNS name that may be constructed by 186 adding labels to the left-hand side of the domain name given as the 187 constraint is considered to fall within the indicated subtree. 189 Implementations should convert IDNs to Unicode before display. 190 Specifically, conforming implementations should convert A-labels to 191 U-labels for display. 193 Note: Implementations MUST allow for increased space requirements 194 for IDNs. An IDN ACE label will begin with the four additional 195 characters "xn--" and may require as many as five ASCII characters to 196 specify a single international character. 198 2.3. Update in Section 7.3, IDNs in Distinguished Names 200 This update aligns with IDNA2008. 202 OLD 204 Domain Names may also be represented as distinguished names using 205 domain components in the subject field, the issuer field, the 206 subjectAltName extension, or the issuerAltName extension. As with 207 the dNSName in the GeneralName type, the value of this attribute is 208 defined as an IA5String. Each domainComponent attribute represents a 209 single label. To represent a label from an IDN in the distinguished 210 name, the implementation MUST perform the "ToASCII" label conversion 211 specified in Section 4.1 of RFC 3490. The label SHALL be considered 212 a "stored string". That is, the AllowUnassigned flag SHALL NOT be 213 set. 215 NEW 217 Domain Names may also be represented as distinguished names using 218 domain components in the subject field, the issuer field, the 219 subjectAltName extension, or the issuerAltName extension. As with 220 the dNSName in the GeneralName type, the value of this attribute is 221 defined as an IA5String. Each domainComponent attribute represents a 222 single label. To represent a label from an IDN in the distinguished 223 name, the implementation MUST convert all U-labels to A-labels. 225 2.4. Update in Section 7.5, Internationalized Electronic Mail Addresses 227 This update aligns with IDNA2008 and [ID.lamps-eai-addresses]. Since 228 all of Section 7.5 is replaced, the OLD text is not provided. 230 NEW 232 Electronic Mail addresses may be included in certificates and CRLs in 233 the subjectAltName and issuerAltName extensions, name constraints 234 extension, authority information access extension, subject 235 information access extension, issuing distribution point extension, 236 or CRL distribution points extension. Each of these extensions uses 237 the GeneralName construct. If the email address includes an IDN but 238 the local-part of the email address can be represented in ASCII, then 239 the email address is placed in the rfc822Name choice of GeneralName, 240 which is defined as type IA5String. If the local-part of the 241 internationalized email address cannot be represented in ASCII, then 242 the internationalized email address is placed in the otherName choice 243 of GeneralName using the conventions in [ID.lamps-eai-addresses]. 245 7.5.1. Local-part Contains Only ASCII Characters 247 Where the host-part contains an IDN, conforming implementations MUST 248 convert all U-labels to A-labels. 250 Two email addresses are considered to match if: 252 1) the local-part of each name is an exact match, AND 254 2) the host-part of each name matches using a case-insensitive 255 ASCII comparison. 257 Implementations should convert the host-part of internationalized 258 email addresses specified in these extensions to Unicode before 259 display. Specifically, conforming implementations should convert 260 A-labels to U-labels for display. 262 7.5.2. Local-part Contains Non-ASCII Characters 264 When the local-part contains non-ASCII character, conforming 265 implementations MUST be placed in the SmtpUtf8Name within the 266 otherName choice of GeneralName as specified in Section 3 of 267 [ID.lamps-eai-addresses]. Note that the UTF8 encoding of the 268 internationalized email address MUST NOT contain a Byte-Order-Mark 269 (BOM) [RFC3629] to aid comparison. 271 The comparison of two internationalized email addresses is specified 272 in Section 5 of [ID.lamps-eai-addresses]. 274 Implementations should convert the local-part and the host-part of 275 internationalized email addresses placed in these extensions to 276 Unicode before display. 278 3. Security Considerations 280 Conforming CAs SHOULD ensure that IDNs are valid. This can be done 281 by validating all code points according to IDNA2008 [RFC5892]. 283 Failure to use valid A-labels and valid U-labels may yield a domain 284 name that cannot be correctly represented in the Domain Name System 285 (DNS). In addition, the CA/Browser Forum offers some guidance 286 regarding internal server names in certificates [CABF]. 288 4. IANA Considerations 290 No IANA registries are changed by this update. 292 5. Normative References 294 [ID.lamps-eai-addresses] 295 Melnikov, A. (Ed.) and W. Chuang (Ed.), 296 "Internationalized Email Addresses in X.509 certificates", 297 December 2016, , work-in-progress. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, DOI 302 10.17487/RFC2119, March 1997, . 305 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 306 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 307 January 2005, . 309 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 310 (LDAP): Internationalized String Preparation", RFC 4518, 311 DOI 10.17487/RFC4518, June 2006, . 314 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 315 Housley, R., and W. Polk, "Internet X.509 Public Key 316 Infrastructure Certificate and Certificate Revocation List 317 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 318 . 320 [RFC5890] Klensin, J., "Internationalized Domain Names for 321 Applications (IDNA): Definitions and Document Framework", 322 RFC 5890, DOI 10.17487/RFC5890, August 2010, 323 . 325 [RFC5891] Klensin, J., "Internationalized Domain Names in 326 Applications (IDNA): Protocol", RFC 5891, DOI 327 10.17487/RFC5891, August 2010, . 330 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 331 Internationalized Domain Names for Applications (IDNA)", 332 RFC 5892, DOI 10.17487/RFC5892, August 2010, 333 . 335 6. Informative References 337 [CABF] CA/Browser Forum, "Internal Server Names and IP Address 338 Requirements for SSL", Version 1.0, June 2012, 339 341 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 342 "Internationalizing Domain Names in Applications (IDNA)", 343 RFC 3490, DOI 10.17487/RFC3490, March 2003, 344 . 346 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 347 for Internationalized Domain Names in Applications 348 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 349 . 351 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 352 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 353 2003, . 355 Acknowledgements 357 Thanks to Alexey Melnikov for the encouragement to write this update. 358 Thanks to John Klensin and Patrik Falstrom for confirming many of the 359 details in this update. Thanks to Wei Chuang, Phillip Hallam-Baker, 360 Alexey Melnikov, Tim Ruehsen, and Sean Turner for their careful 361 review and comments. 363 Authors' Address 365 Russ Housley 366 Vigil Security, LLC 367 918 Spring Knoll Drive 368 Herndon, VA 20170 369 USA 371 EMail: housley@vigilsec.com