idnits 2.17.1 draft-ietf-lamps-rfc5280-i18n-update-00.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 (9 May 2017) is 2545 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: 'RFC5980' is mentioned on line 75, but not defined == Missing Reference: 'RFC3492' is mentioned on line 166, but not defined == Missing Reference: 'RFC3629' is mentioned on line 257, but not defined == Unused Reference: 'RFC5892' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC3639' is defined on line 335, but no explicit reference was found in the text -- 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 (~~), 7 warnings (==), 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: RFC 5280 (once approved) 6 Expires: 9 November 2017 9 May 2017 8 Internationalization Updates to RFC 5280 9 draft-ietf-lamps-rfc5280-i18n-update-00 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 [RFC5891]. 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 [RFC3987], [RFC4518], [RFC5890], and [RFC5891]. 112 2.2. Update in Section 4.2.1.10, Name Constraints 114 This update removes the ability to include constraints for a 115 particular mailbox. This capability was not used, and removing it 116 allows name constraints to apply to email addresses in rfc822Name and 117 SmtpUTF8Name within otherName. 119 OLD 121 A name constraint for Internet mail addresses MAY specify a 122 particular mailbox, all addresses at a particular host, or all 123 mailboxes in a domain. To indicate a particular mailbox, the 124 constraint is the complete mail address. For example, 125 "root@example.com" indicates the root mailbox on the host 126 "example.com". To indicate all Internet mail addresses on a 127 particular host, the constraint is specified as the host name. For 128 example, the constraint "example.com" is satisfied by any mail 129 address at the host "example.com". To specify any address within a 130 domain, the constraint is specified with a leading period (as with 131 URIs). For example, ".example.com" indicates all the Internet mail 132 addresses in the domain "example.com", but not Internet mail 133 addresses on the host "example.com". 135 NEW 137 A name constraint for Internet mail addresses MAY specify all 138 addresses at a particular host or all mailboxes in a domain. To 139 indicate all Internet mail addresses on a particular host, the 140 constraint is specified as the host name. For example, the 141 constraint "example.com" is satisfied by any mail address at the 142 host "example.com". To specify any address within a domain, the 143 constraint is specified with a leading period (as with URIs). For 144 example, ".example.com" indicates all the Internet mail addresses 145 in the domain "example.com", but not Internet mail addresses on 146 the host "example.com". 148 2.3. Update in Section 7.2, IDNs in GeneralName 150 This update aligns with IDNA2008. Since all of Section 7.2 is 151 replaced, the OLD text is not provided. 153 NEW 155 Internationalized Domain Names (IDNs) may be included in certificates 156 and CRLs in the subjectAltName and issuerAltName extensions, name 157 constraints extension, authority information access extension, 158 subject information access extension, CRL distribution points 159 extension, and issuing distribution point extension. Each of these 160 extensions uses the GeneralName type; one choice in GeneralName is 161 the dNSName field, which is defined as type IA5String. 163 IA5String is limited to the set of ASCII characters. To accommodate 164 internationalized domain names U-labels are converted to A-labels. 165 The A-label is the encoding of the U-label according to the Punycode 166 algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning 167 of the string. 169 When comparing DNS names for equality, conforming implementations 170 MUST perform a case-insensitive exact match on the entire DNS name. 171 When evaluating name constraints, conforming implementations MUST 172 perform a case-insensitive exact match on a label-by-label basis. As 173 noted in Section 4.2.1.10, any DNS name that may be constructed by 174 adding labels to the left-hand side of the domain name given as the 175 constraint is considered to fall within the indicated subtree. 177 Implementations should convert IDNs to Unicode before display. 178 Specifically, conforming implementations should convert A-labels to 179 U-labels for display. 181 Note: Implementations MUST allow for increased space requirements 182 for IDNs. An IDN ACE label will begin with the four additional 183 characters "xn--" and may require as many as five ASCII characters to 184 specify a single international character. 186 2.3. Update in Section 7.3, IDNs in Distinguished Names 188 This update aligns with IDNA2008. 190 OLD 192 Domain Names may also be represented as distinguished names using 193 domain components in the subject field, the issuer field, the 194 subjectAltName extension, or the issuerAltName extension. As with 195 the dNSName in the GeneralName type, the value of this attribute is 196 defined as an IA5String. Each domainComponent attribute represents a 197 single label. To represent a label from an IDN in the distinguished 198 name, the implementation MUST perform the "ToASCII" label conversion 199 specified in Section 4.1 of RFC 3490. The label SHALL be considered 200 a "stored string". That is, the AllowUnassigned flag SHALL NOT be 201 set. 203 NEW 205 Domain Names may also be represented as distinguished names using 206 domain components in the subject field, the issuer field, the 207 subjectAltName extension, or the issuerAltName extension. As with 208 the dNSName in the GeneralName type, the value of this attribute is 209 defined as an IA5String. Each domainComponent attribute represents a 210 single label. To represent a label from an IDN in the distinguished 211 name, the implementation MUST convert all U-labels to A-labels. 213 2.4. Update in Section 7.5, Internationalized Electronic Mail Addresses 215 This update aligns with IDNA2008 and [ID.lamps-eai-addresses]. Since 216 all of Section 7.5 is replaced, the OLD text is not provided. 218 NEW 220 Electronic Mail addresses may be included in certificates and CRLs in 221 the subjectAltName and issuerAltName extensions, name constraints 222 extension, authority information access extension, subject 223 information access extension, issuing distribution point extension, 224 or CRL distribution points extension. Each of these extensions uses 225 the GeneralName construct. If the email address includes an IDN but 226 the local-part of the email address can be represented in ASCII, then 227 the email address is placed in the rfc822Name choice of GeneralName, 228 which is defined as type IA5String. If the local-part of the 229 internationalized email address cannot be represented in ASCII, then 230 the internationalized email address is placed in the otherName choice 231 of GeneralName using the conventions in [ID.lamps-eai-addresses]. 233 7.5.1. Local-part Contains Only ASCII Characters 235 Where the host-part contains an IDN, conforming implementations MUST 236 convert all U-labels to A-labels. 238 Two email addresses are considered to match if: 240 1) the local-part of each name is an exact match, AND 242 2) the host-part of each name matches using a case-insensitive 243 ASCII comparison. 245 Implementations should convert the host-part of internationalized 246 email addresses specified in these extensions to Unicode before 247 display. Specifically, conforming implementations should convert 248 A-labels to U-labels for display. 250 7.5.2. Local-part Contains Non-ASCII Characters 252 When the local-part contains non-ASCII character, conforming 253 implementations MUST be placed in the SmtpUtf8Name within the 254 otherName choice of GeneralName as specified in Section 3 of 255 [ID.lamps-eai-addresses]. Note that the UTF8 encoding of the 256 internationalized email address MUST NOT contain a Byte-Order-Mark 257 (BOM) [RFC3629] to aid comparison. 259 The comparison of two internationalized email addresses is specified 260 in Section 5 of [ID.lamps-eai-addresses]. 262 Implementations should convert the local-part and the host-part of 263 internationalized email addresses placed in these extensions to 264 Unicode before display. 266 3. Security Considerations 268 Conforming CAs SHOULD ensure that IDNs are represented as valid 269 A-labels. This can be accomplished by taking a provided U-label, 270 validating the code points, converting it to an A-label, back to an 271 U-label, and then checking to see that the result is the same as the 272 original U-label. Failure to use valid A-labels may yield a name 273 that cannot be correctly represented in the Domain Name System (DNS). 274 In addition, the CA/Browser Forum offers some guidance regarding 275 internal server names in certificates [CABF]. 277 4. IANA Considerations 279 No IANA registries are changed by this update. 281 5. Normative References 283 [ID.lamps-eai-addresses] 284 Melnikov, A. (Ed.) and W. Chuang (Ed.), 285 "Internationalized Email Addresses in X.509 certificates", 286 December 2016, , work-in-progress. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, DOI 291 10.17487/RFC2119, March 1997, . 294 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 295 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 296 January 2005, . 298 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 299 (LDAP): Internationalized String Preparation", RFC 4518, 300 DOI 10.17487/RFC4518, June 2006, . 303 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 304 Housley, R., and W. Polk, "Internet X.509 Public Key 305 Infrastructure Certificate and Certificate Revocation List 306 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 307 . 309 [RFC5890] Klensin, J., "Internationalized Domain Names for 310 Applications (IDNA): Definitions and Document Framework", 311 RFC 5890, DOI 10.17487/RFC5890, August 2010, 312 . 314 [RFC5891] Klensin, J., "Internationalized Domain Names in 315 Applications (IDNA): Protocol", RFC 5891, DOI 316 10.17487/RFC5891, August 2010, . 319 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 320 Internationalized Domain Names for Applications (IDNA)", 321 RFC 5892, DOI 10.17487/RFC5892, August 2010, 322 . 324 6. Informative References 326 [CABF] CA/Browser Forum, "Internal Server Names and IP Address 327 Requirements for SSL", Version 1.0, June 2012, 328 330 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 331 "Internationalizing Domain Names in Applications (IDNA)", 332 RFC 3490, DOI 10.17487/RFC3490, March 2003, 333 . 335 [RFC3639] St. Johns, M., Ed., Huston, G., Ed., and IAB, 336 "Considerations on the use of a Service Identifier in 337 Packet Headers", RFC 3639, DOI 10.17487/RFC3639, October 338 2003, . 340 Acknowledgements 342 Thanks to Alexey Melnikov for the encouragement to write this update. 343 Thanks to John Klensin and Patrik Falstrom for confirming many of the 344 details in this update. Thanks to Wei Chuang, Alexey Melnikov, Tim 345 Ruehsen, and Sean Turner for their careful review and comments. 347 Authors' Address 349 Russ Housley 350 Vigil Security, LLC 351 918 Spring Knoll Drive 352 Herndon, VA 20170 353 USA 355 EMail: housley@vigilsec.com