idnits 2.17.1 draft-ietf-lamps-eai-addresses-10.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The SmtpUTF8Name aware email address name constraint form is specified to be rfc822Name motivated by compatibility considerations with legacy systems that already understand that form. This specification modifies [RFC5280] name constraint to only require with MAY that it represents all addresses at a host or all mailboxes in a domain, and require with MAY NOT that it represent a particular mailbox. For context, [RFC5280] Section 4.2.1.10 specifies with MAY that name constraint represent a particular mailbox, all addresses at a host, or all mailboxes in a domain by specifying the complete email address, a host name, or a domain. The change is due to rfc822Name name constraints inability to represent a specific mailbox with a UTF-8 email local part email address. CA certificate issuers should be aware of this lessened support. -- The document date (May 18, 2017) is 2534 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) -- Looks like a reference, but probably isn't: '0' on line 438 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track W. Chuang, Ed. 5 Expires: November 19, 2017 Google, Inc. 6 May 18, 2017 8 Internationalized Email Addresses in X.509 certificates 9 draft-ietf-lamps-eai-addresses-10 11 Abstract 13 This document defines a new name form for inclusion in the otherName 14 field of an X.509 Subject Alternative Name and Issuer Alternate Name 15 extension that allows a certificate subject to be associated with an 16 Internationalized Email Address. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 19, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 2 55 4. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Matching of Internationalized Email Addresses in X.509 57 certificates . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Name constraints in path validation . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 9.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 65 Appendix B. Example of SmtpUTF8Name . . . . . . . . . . . . . . 10 66 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 [RFC5280] defines rfc822Name subjectAltName choice for representing 72 [RFC5321] email addresses. This form is restricted to a subset of 73 US-ASCII characters and thus can't be used to represent 74 Internationalized Email addresses [RFC6531]. To facilitate use of 75 these Internationalized Email addresses with X.509 certificates, this 76 document specifies a new name form in otherName so that 77 subjectAltName and issuerAltName can carry them. In addition this 78 document calls for all email address domain in X.509 certificates to 79 conform to IDNA2008 [RFC5890]. 81 2. Conventions Used in This Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 88 notation. 90 3. Name Definitions 92 The GeneralName structure is defined in [RFC5280], and supports many 93 different names forms including otherName for extensibility. This 94 section specifies the SmtpUTF8Name name form of otherName, so that 95 Internationalized Email addresses can appear in the subjectAltName of 96 a certificate, the issuerAltName of a certificate, or anywhere else 97 that GeneralName is used. 99 id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 } 101 SmtpUTF8Name ::= UTF8String (SIZE (1..MAX)) 103 When the subjectAltName (or issuerAltName) extension contains an 104 Internationalized Email address, the address MUST be stored in the 105 SmtpUTF8Name name form of otherName. The format of SmtpUTF8Name is 106 defined as the ABNF rule SmtpUTF8Mailbox. SmtpUTF8Mailbox is a 107 modified version of the Internationalized Mailbox which was defined 108 in Section 3.3 of [RFC6531] which was itself derived from SMTP 109 Mailbox from Section 4.1.2 of [RFC5321]. [RFC6531] defines the 110 following ABNF rules for Mailbox whose parts are modified for 111 internationalization: , , , 112 , , and . In particular, 113 was updated to also support UTF8-non-ascii. UTF8-non-ascii was 114 described by Section 3.1 of [RFC6532]. Also, sub-domain was extended 115 to support U-label, as defined in [RFC5890]. 117 This document further refines Internationalized [RFC6531] Mailbox 118 ABNF rules and calls this SmtpUTF8Mailbox. In SmtpUTF8Mailbox, sub- 119 domain that encode non-ASCII characters SHALL use U-label Unicode 120 native character labels and MUST NOT use A-label [RFC5890]. This 121 restriction prevents having to determine which label encoding A- or 122 U-label is present in the Domain. As per Section 2.3.2.1 of 123 [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and 124 other properties specified there. In SmtpUTF8Mailbox, sub-domain 125 that encode ASCII character labels SHALL use NR-LDH restrictions as 126 specified by section 2.3.1 of [RFC5890] and SHALL be restricted to 127 lower case letters. One suggested approach to apply these sub- 128 domains restriction is to restrict sub-domain so that labels not 129 start with two letters followed by two hyphen-minus characters. 130 Consistent with the treatment of rfc822Name in [RFC5280], 131 SmtpUTF8Name is an envelope and has no phrase (such as a 132 common name) before it, has no comment (text surrounded in 133 parentheses) after it, and is not surrounded by "<" and ">". 135 Due to operational reasons described shortly and name constraint 136 compatibility reasons described in its section, SmtpUTF8Name 137 subjectAltName MUST only be used when the local part of the email 138 address contains UTF-8. When the local-part is ASCII, rfc822Name 139 subjectAltName MUST be used instead of SmtpUTF8Name. The use of 140 rfc822Name rather than SmtpUTF8Name is currently more likely to be 141 supported. Also use of SmtpUTF8Name incurs higher byte 142 representation overhead due to encoding with otherName and the 143 additional OID needed. This may be offset if domain requires non- 144 ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name 145 supports A-label. 147 SmtpUTF8Name is encoded as UTF8String. The UTF8String encoding MUST 148 NOT contain a Byte-Order- Mark (BOM) [RFC3629] to aid consistency 149 across implementations particularly for comparison. 151 4. IDNA2008 153 To facilitate comparison between email addresses, all email address 154 domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and 155 excludes any "mappings" mentioned in that document). Otherwise non- 156 conforming email address domains introduces the possibility of 157 conversion errors between alternate forms. This applies to 158 SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and 159 anywhere else that GeneralName is used. 161 5. Matching of Internationalized Email Addresses in X.509 certificates 163 In equivalence comparison with SmtpUTF8Name, there may be some setup 164 work to enable the comparison i.e. processing of the SmtpUTF8Name 165 content or the email address that is being compared against. The 166 process for setup for comparing with SmtpUTF8Name is split into 167 domain steps and local- part steps. The comparison form for local- 168 part always is UTF-8. The comparison form for domain depends on 169 context. While some contexts such as certificate path validation in 170 [RFC5280] specify transforming domain to A-label, this document 171 RECOMMENDS transforming to UTF-8 U-label instead. This reduces the 172 likelihood of errors by reducing conversions as more implementations 173 natively support U-label domains. 175 Comparison of two SmtpUTF8Name is straightforward with no setup work 176 needed. They are considered equivalent if there is an exact octet- 177 for-octet match. Comparison with other email address forms such as 178 Internationalized email address or rfc822Name requires additional 179 setup steps. Domain setup is particularly important for forms that 180 may contain A- or U-label such as International email address, or 181 A-label only forms such as rfc822Name. This document specifies the 182 process to transform the domain to U-label. (To convert the domain 183 to A-label, follow the process specified in section 7.5 and 7.2 in 184 [RFC5280]) The first step is to detect A-label by using section 5.1 185 of [RFC5891]. Next if necessary, transform the A-label to U-label 186 Unicode as specified in section 5.2 of [RFC5891]. Finally if 187 necessary convert the Unicode to UTF-8 as specified in section 3 of 188 [RFC3629]. For ASCII NR-LDH labels, upper case letters are converted 189 to lower case letters. In setup for SmtpUTF8Mailbox, the email 190 address local-part MUST conform to the requirements of [RFC6530] and 191 [RFC6531], including being a string in UTF-8 form. In particular, 192 the local-part MUST NOT be transformed in any way, such as by doing 193 case folding or normalization of any kind. The part of 194 an Internationalized email address is already in UTF-8. For 195 rfc822Name the local-part, which is IA5String (ASCII), trivially maps 196 to UTF-8 without change. Once setup is complete, they are again 197 compared octet-for-octet. 199 To summarize non-normatively, the comparison steps including setup 200 are: 202 1. If the domain contains A-labels, transform them to U-label. 204 2. If the domain contains ASCII NR-LDH labels, lowercase them. 206 3. Ensure local-part is UTF-8. 208 4. Compare strings octet-for-octet for equivalence. 210 This specification expressly does not define any wildcards characters 211 and SmtpUTF8Name comparison implementations MUST NOT interpret any 212 character as wildcards. Instead, to specify multiple email addresses 213 through SmtpUTF8Name, the certificate SHOULD use multiple 214 subjectAltNames or issuerAltNames to explicitly carry those email 215 addresses. 217 6. Name constraints in path validation 219 This section updates [RFC5280] name constraints defined in section 220 4.2.1.10 to work with SmtpUTF8Name subjectAltName. The following 221 specifies that a SmtpUTF8Name aware CA use a compatible name 222 constraint representation. Similarly a SmtpUTF8Name aware path 223 validators MUST be able to apply name constraint comparison to the 224 subject distinguished name and both forms of subject alternative name 225 rfc822Name and SmtpUTF8Name. 227 The SmtpUTF8Name aware email address name constraint form is 228 specified to be rfc822Name motivated by compatibility considerations 229 with legacy systems that already understand that form. This 230 specification modifies [RFC5280] name constraint to only require with 231 MAY that it represents all addresses at a host or all mailboxes in a 232 domain, and require with MAY NOT that it represent a particular 233 mailbox. For context, [RFC5280] Section 4.2.1.10 specifies with MAY 234 that name constraint represent a particular mailbox, all addresses at 235 a host, or all mailboxes in a domain by specifying the complete email 236 address, a host name, or a domain. The change is due to rfc822Name 237 name constraints inability to represent a specific mailbox with a 238 UTF-8 email local part email address. CA certificate issuers should 239 be aware of this lessened support. 241 Constraint comparison with SmtpUTF8Name subjectAltName starts with 242 the setup steps defined by Section 5. The setup applies to the 243 inputs of the comparison which is one of a subject distinguished name 244 or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a 245 rfc822Name name constraint. Non-normatively the setup will convert 246 any domain A-label to U-label in the rfc822Name name constraint, and 247 to lower case any doman NR-LDH label in both the name constraint and 248 the subject. After setup, this follows the comparison steps defined 249 in 4.2.1.10 of [RFC5280] with some modifications as follows. The 250 comparison process starts by determining the name constraint 251 representation i.e. email host name or domain part, then comparing 252 the name constraint against the corresponding part in the email 253 address using a byte for byte comparison. This document suggests 254 that name constraint comparison with subject distinguished name or 255 rfc822Name subjectAltName also follow these setup and comparisons 256 steps as well. 258 The name constraint requirement with SmtpUTF8Name subject alternative 259 name is illustrated in the non-normative diagram Figure 1. The first 260 example (1) illustrates a permitted rfc822Name ASCII only hostname 261 name constraint, and the corresponding valid rfc822Name 262 subjectAltName and SmtpUTF8Name subjectAltName email addresses. The 263 second example (2) illustrates a permitted rfc822Name hostname name 264 constraint with A-label, and the corresponding valid rfc822Name 265 subjectAltName and SmtpUTF8Name subjectAltName email addresses. 267 +-------------------------------------------------------------------+ 268 | Root CA Cert | 269 +-------------------------------------------------------------------+ 270 | 271 v 272 +-------------------------------------------------------------------+ 273 | Intermediate CA Cert | 274 | Permitted | 275 | rfc822Name: elementary.school.example.com (1) | 276 | | 277 | rfc822Name: xn--pss25c.example.com (2) | 278 | | 279 +-------------------------------------------------------------------+ 280 | 281 v 282 +-------------------------------------------------------------------+ 283 | Entity Cert (w/explicitly permitted subjects) | 284 | SubjectAltName Extension | 285 | rfc822Name: student@elemenary.school.example.com (1) | 286 | SmtpUTF8Name: u+5B66u+751F@elementary.school.example.com (1) | 287 | | 288 | rfc822Name: student@xn--pss25c.example.com (2) | 289 | SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) | 290 | | 291 +-------------------------------------------------------------------+ 293 Name constraints with SmtpUTF8Name and rfc822Name 295 Figure 1 297 7. Security Considerations 299 Use for SmtpUTF8Name for certificate subjectAltName (and 300 issuerAltName) will incur many of the same security considerations of 301 Section 8 in [RFC5280] but is further complicated by permitting non- 302 ASCII characters in the email address local-part. This complication, 303 as mentioned in Section 4.4 of [RFC5890] and in Section 4 of 304 [RFC6532], is that use of Unicode introduces the risk of visually 305 similar and identical characters which can be exploited to deceive 306 the recipient. The former document references some means to mitigate 307 against these attacks. 309 8. IANA Considerations 311 in Section Section 3 and the ASN.1 module identifier defined in 312 Section Appendix A. IANA is kindly requested to make the following 313 assignments for: 315 The LAMPS-EaiAddresses-2016 ASN.1 module in the "SMI Security for 316 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 318 The SmtpUTF8Name otherName in the "PKIX Other Name Forms" registry 319 (1.3.6.1.5.5.7.8). 321 9. References 323 9.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 331 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 332 2003, . 334 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 335 Specifications: ABNF", STD 68, RFC 5234, 336 DOI 10.17487/RFC5234, January 2008, 337 . 339 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 340 Housley, R., and W. Polk, "Internet X.509 Public Key 341 Infrastructure Certificate and Certificate Revocation List 342 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 343 . 345 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 346 DOI 10.17487/RFC5321, October 2008, 347 . 349 [RFC5890] Klensin, J., "Internationalized Domain Names for 350 Applications (IDNA): Definitions and Document Framework", 351 RFC 5890, DOI 10.17487/RFC5890, August 2010, 352 . 354 [RFC5891] Klensin, J., "Internationalized Domain Names in 355 Applications (IDNA): Protocol", RFC 5891, 356 DOI 10.17487/RFC5891, August 2010, 357 . 359 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 360 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 361 February 2012, . 363 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 364 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 365 . 367 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 368 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 369 2012, . 371 9.2. Informative References 373 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 374 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 375 DOI 10.17487/RFC5912, June 2010, 376 . 378 Appendix A. ASN.1 Module 380 The following ASN.1 module normatively specifies the SmtpUTF8Name 381 structure. This specification uses the ASN.1 definitions from 382 [RFC5912] with the 2002 ASN.1 notation used in that document. 383 [RFC5912] updates normative documents using older ASN.1 notation. 385 LAMPS-EaiAddresses-2016 386 { iso(1) identified-organization(3) dod(6) 387 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 388 id-mod-lamps-eai-addresses-2016(TBD) } 390 DEFINITIONS IMPLICIT TAGS ::= 391 BEGIN 393 IMPORTS 394 OTHER-NAME 395 FROM PKIX1Implicit-2009 396 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 397 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 399 id-pkix 400 FROM PKIX1Explicit-2009 401 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 402 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; 404 -- 405 -- otherName carries additional name types for subjectAltName, 406 -- issuerAltName, and other uses of GeneralNames. 407 -- 409 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 411 SmtpUtf8OtherNames OTHER-NAME ::= { on-SmtpUTF8Name, ... } 413 on-SmtpUTF8Name OTHER-NAME ::= { 414 SmtpUTF8Name IDENTIFIED BY id-on-SmtpUTF8Name 415 } 417 id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 } 419 SmtpUTF8Name ::= UTF8String (SIZE (1..MAX)) 421 END 423 Figure 2 425 Appendix B. Example of SmtpUTF8Name 427 This non-normative example demonstrates using SmtpUTF8Name as an 428 otherName in GeneralName to encode the email address 429 "u+8001u+5E2B@example.com". 431 The hexadecimal DER encoding of the email address is: 432 A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 433 6D706C65 2E636F6D 435 The text decoding is: 436 0 34: [0] { 437 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' 438 14 20: [0] { 439 16 18: UTF8String '..@example.com' 440 : } 441 : } 443 Figure 3 445 The example was encoded on the OSS Nokalva ASN.1 Playground and the 446 above text decoding is an output of Peter Gutmann's "dumpasn1" 447 program. 449 Appendix C. Acknowledgements 451 Thank you to Magnus Nystrom for motivating this document. Thanks to 452 Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean 453 Leonard, Sean Turner, John Levine, and Patrik Falstrom for their 454 feedback. Also special thanks to John Klensin for his valuable input 455 on internationalization, Unicode and ABNF formatting, to Jim Schaad 456 for his help with the ASN.1 example and his helpful feedback, and to 457 Viktor Dukhovni for his help with name constraints. 459 Authors' Addresses 461 Alexey Melnikov (editor) 462 Isode Ltd 463 14 Castle Mews 464 Hampton, Middlesex TW12 2NP 465 UK 467 Email: Alexey.Melnikov@isode.com 469 Weihaw Chuang (editor) 470 Google, Inc. 471 1600 Amphitheater Parkway 472 Mountain View, CA 94043 473 US 475 Email: weihaw@google.com