idnits 2.17.1 draft-housley-rfc5280-i18n-update-01.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 April 2017) is 2551 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) == Missing Reference: 'RFC5981' is mentioned on line 66, but not defined == Missing Reference: 'RFC5980' is mentioned on line 75, but not defined == Missing Reference: 'RFC3492' is mentioned on line 167, but not defined == Missing Reference: 'RFC3629' is mentioned on line 258, but not defined == Unused Reference: 'RFC5892' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC3639' is defined on line 336, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.lamps-eai-addresses' ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 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: RFC 5280 (once approved) 6 Expires: 24 October 2017 24 April 2017 8 Internationalization Updates to RFC 5280 9 draft-housley-rfc5280-i18n-update-01 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 1. Introduction 55 This document updates RFC 5280 [RFC5280]. The Introduction in 56 Section 1, the Name Constraints certificate extension discussion in 57 Section 4.2.1.10, and the Processing Rules for Internationalized 58 Names in Section 7 are updated to provide clarity on the handling of 59 Internationalized Domain Names (IDNs) and Internationalized Email 60 Addresses in X.509 Certificates. 62 An IDN in Unicode (native character) form contains at least one 63 U-label [RFC5890]. With one exception, IDNs are carried in 64 certificates in ACE-encoded form. That is, all U-labels within an 65 IDN are converted to A-labels. Conversion of an U-label to an 66 A-label is described in [RFC5981]. 68 The GeneralName structure supports many different names forms, 69 including otherName for extensibility. [ID.lamps-eai-addresses] 70 specifies the SmtpUTF8Name for Internationalized Email addresses, 71 which include IDNs with U-labels. 73 Note that Internationalized Domain Names in Applications 74 specifications published in 2003 (IDNA2003) [RFC3490] and 2008 75 (IDNA2008) [RFC5980] both refer to the Punycode Algorithm for 76 conversion [RFC3492]. 78 1.1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Updates 86 This section provides updates to several paragraphs of RFC 5280 87 [RFC5280]. For clarity, if the entire section is not replace, then 88 the original text and the replacement text are shown. 90 2.1. Update in Section 1, Introduction 92 This update includes references for IDNA2008. 94 OLD 96 * Enhanced support for internationalized names is specified in 97 Section 7, with rules for encoding and comparing 98 Internationalized Domain Names, Internationalized Resource 99 Identifiers (IRIs), and distinguished names. These rules are 100 aligned with comparison rules established in current RFCs, 101 including [RFC3490], [RFC3987], and [RFC4518]. 103 NEW 105 * Enhanced support for internationalized names is specified in 106 Section 7, with rules for encoding and comparing 107 Internationalized Domain Names, Internationalized Resource 108 Identifiers (IRIs), and distinguished names. These rules are 109 aligned with comparison rules established in current RFCs, 110 including [RFC3490], [RFC3987], [RFC4518], [RFC5890], and 111 [RFC5891]. 113 2.2. Update in Section 4.2.1.10, Name Constraints 115 This update removes the ability to include constraints for a 116 particular mailbox. This capability was not used, and removing it 117 allows name constraints to apply to email addresses in rfc822Name and 118 SmtpUTF8Name within otherName. 120 OLD 122 A name constraint for Internet mail addresses MAY specify a 123 particular mailbox, all addresses at a particular host, or all 124 mailboxes in a domain. To indicate a particular mailbox, the 125 constraint is the complete mail address. For example, 126 "root@example.com" indicates the root mailbox on the host 127 "example.com". To indicate all Internet mail addresses on a 128 particular host, the constraint is specified as the host name. For 129 example, the constraint "example.com" is satisfied by any mail 130 address at the host "example.com". To specify any address within a 131 domain, the constraint is specified with a leading period (as with 132 URIs). For example, ".example.com" indicates all the Internet mail 133 addresses in the domain "example.com", but not Internet mail 134 addresses on the host "example.com". 136 NEW 138 A name constraint for Internet mail addresses MAY specify all 139 addresses at a particular host or all mailboxes in a domain. To 140 indicate all Internet mail addresses on a particular host, the 141 constraint is specified as the host name. For example, the 142 constraint "example.com" is satisfied by any mail address at the 143 host "example.com". To specify any address within a domain, the 144 constraint is specified with a leading period (as with URIs). For 145 example, ".example.com" indicates all the Internet mail addresses 146 in the domain "example.com", but not Internet mail addresses on 147 the host "example.com". 149 2.3. Update in Section 7.2, IDNs in GeneralName 151 This update aligns with IDNA2008. Since all of Section 7.2 is 152 replaced, the OLD text is not provided. 154 NEW 156 Internationalized Domain Names (IDNs) may be included in certificates 157 and CRLs in the subjectAltName and issuerAltName extensions, name 158 constraints extension, authority information access extension, 159 subject information access extension, CRL distribution points 160 extension, and issuing distribution point extension. Each of these 161 extensions uses the GeneralName type; one choice in GeneralName is 162 the dNSName field, which is defined as type IA5String. 164 IA5String is limited to the set of ASCII characters. To accommodate 165 internationalized domain names U-labels are converted to A-labels. 166 The A-label is the encoding of the U-label according to the Punycode 167 algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning 168 of the string. 170 When comparing DNS names for equality, conforming implementations 171 MUST perform a case-insensitive exact match on the entire DNS name. 172 When evaluating name constraints, conforming implementations MUST 173 perform a case-insensitive exact match on a label-by-label basis. As 174 noted in Section 4.2.1.10, any DNS name that may be constructed by 175 adding labels to the left-hand side of the domain name given as the 176 constraint is considered to fall within the indicated subtree. 178 Implementations should convert IDNs to Unicode before display. 179 Specifically, conforming implementations should convert A-labels to 180 U-labels for display. 182 Note: Implementations MUST allow for increased space requirements 183 for IDNs. An IDN ACE label will begin with the four additional 184 characters "xn--" and may require as many as five ASCII characters to 185 specify a single international character. 187 2.3. Update in Section 7.3, IDNs in Distinguished Names 189 This update aligns with IDNA2008. 191 OLD 193 Domain Names may also be represented as distinguished names using 194 domain components in the subject field, the issuer field, the 195 subjectAltName extension, or the issuerAltName extension. As with 196 the dNSName in the GeneralName type, the value of this attribute is 197 defined as an IA5String. Each domainComponent attribute represents a 198 single label. To represent a label from an IDN in the distinguished 199 name, the implementation MUST perform the "ToASCII" label conversion 200 specified in Section 4.1 of RFC 3490. The label SHALL be considered 201 a "stored string". That is, the AllowUnassigned flag SHALL NOT be 202 set. 204 NEW 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 convert all U-labels to A-labels. 214 2.4. Update in Section 7.5, Internationalized Electronic Mail Addresses 216 This update aligns with IDNA2008 and [ID.lamps-eai-addresses]. Since 217 all of Section 7.5 is replaced, the OLD text is not provided. 219 NEW 221 Electronic Mail addresses may be included in certificates and CRLs in 222 the subjectAltName and issuerAltName extensions, name constraints 223 extension, authority information access extension, subject 224 information access extension, issuing distribution point extension, 225 or CRL distribution points extension. Each of these extensions uses 226 the GeneralName construct. If the email address includes an IDN but 227 the local-part of the email address can be represented in ASCII, then 228 the email address is placed in the rfc822Name choice of GeneralName, 229 which is defined as type IA5String. If the local-part of the 230 internationalized email address cannot be represented in ASCII, then 231 the internationalized email address is placed in the otherName choice 232 of GeneralName using the conventions in [ID.lamps-eai-addresses]. 234 7.5.1. Local-part Contains Only ASCII Characters 236 Where the host-part contains an IDN, conforming implementations MUST 237 MUST convert all U-labels to A-labels. 239 Two email addresses are considered to match if: 241 1) the local-part of each name is an exact match, AND 243 2) the host-part of each name matches using a case-insensitive 244 ASCII comparison. 246 Implementations should convert the host-part of internationalized 247 email addresses specified in these extensions to Unicode before 248 display. Specifically, conforming implementations should convert 249 A-labels to U-labels for display. 251 7.5.2. Local-part Contains Non-ASCII Characters 253 When the local-part contains non-ASCII character, conforming 254 implementations MUST be placed in the SmtpUtf8Name within the 255 otherName choice of GeneralName as specified in Section 3 of 256 [ID.lamps-eai-addresses]. Note that the UTF8 encoding of the 257 internationalized email address MUST NOT contain a Byte-Order-Mark 258 (BOM) [RFC3629] to aid comparison. 260 The comparison of two internationalized email addresses is specified 261 in Section 5 of [ID.lamps-eai-addresses]. 263 Implementations should convert the local-part and the host-part of 264 internationalized email addresses placed in these extensions to 265 Unicode before display. 267 3. Security Considerations 269 Conforming CAs SHOULD ensure that IDNs are represented as valid 270 A-labels. This can be accomplished by taking a provided U-label, 271 validating the code points, converting it to an A-label, back to an 272 U-label, and then checking to see that the result is the same as the 273 original U-label. Failure to use valid A-labels may yield a name 274 that cannot be correctly represented in the Domain Name System (DNS). 275 In addition, the CA/Browser Forum offers some guidance regarding 276 internal server names in certificates [CABF]. 278 4. IANA Considerations 280 No IANA registries are changed by this update. 282 5. Normative References 284 [ID.lamps-eai-addresses] 285 Melnikov, A. (Ed.) and W. Chuang (Ed.), 286 "Internationalized Email Addresses in X.509 certificates", 287 December 2016, , work-in-progress. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, DOI 292 10.17487/RFC2119, March 1997, . 295 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 296 "Internationalizing Domain Names in Applications (IDNA)", 297 RFC 3490, DOI 10.17487/RFC3490, March 2003, 298 . 300 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 301 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 302 January 2005, . 304 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 305 (LDAP): Internationalized String Preparation", RFC 4518, 306 DOI 10.17487/RFC4518, June 2006, . 309 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 310 Housley, R., and W. Polk, "Internet X.509 Public Key 311 Infrastructure Certificate and Certificate Revocation List 312 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 313 . 315 [RFC5890] Klensin, J., "Internationalized Domain Names for 316 Applications (IDNA): Definitions and Document Framework", 317 RFC 5890, DOI 10.17487/RFC5890, August 2010, 318 . 320 [RFC5891] Klensin, J., "Internationalized Domain Names in 321 Applications (IDNA): Protocol", RFC 5891, DOI 322 10.17487/RFC5891, August 2010, . 325 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 326 Internationalized Domain Names for Applications (IDNA)", 327 RFC 5892, DOI 10.17487/RFC5892, August 2010, 328 . 330 6. Informative References 332 [CABF] CA/Browser Forum, "Internal Server Names and IP Address 333 Requirements for SSL", Version 1.0, June 2012, 334 336 [RFC3639] St. Johns, M., Ed., Huston, G., Ed., and IAB, 337 "Considerations on the use of a Service Identifier in 338 Packet Headers", RFC 3639, DOI 10.17487/RFC3639, October 339 2003, . 341 Acknowledgements 343 Thanks to Alexey Melnikov for the encouragement to write this update. 344 Thanks to John Klensin and Patrik Falstrom for confirming many of the 345 details in this update. Thanks to Wei Chuang and Tim Ruehsen for 346 their careful review and comments. 348 Authors' Address 350 Russ Housley 351 Vigil Security, LLC 352 918 Spring Knoll Drive 353 Herndon, VA 20170 354 USA 356 EMail: housley@vigilsec.com