idnits 2.17.1 draft-ietf-lamps-eai-addresses-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2017) is 2634 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 439 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: August 5, 2017 Google, Inc. 6 February 1, 2017 8 Internationalized Email Addresses in X.509 certificates 9 draft-ietf-lamps-eai-addresses-06 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 August 5, 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. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 10.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 66 Appendix B. Example of SmtpUtf8Name . . . . . . . . . . . . . . 10 67 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 [RFC5280] defines rfc822Name subjectAltName choice for representing 73 [RFC5321] email addresses. This form is restricted to a subset of 74 US-ASCII characters and thus can't be used to represent 75 Internationalized Email addresses [RFC6531]. To facilitate use of 76 these Internationalized Email addresses with X.509 certificates, this 77 document specifies a new name form in otherName so that 78 subjectAltName and issuerAltName can carry them. In addition this 79 document calls for all email address domain in X.509 certificates to 80 conform to IDNA2008 [RFC5890]. 82 2. Conventions Used in This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 89 notation. 91 3. Name Definitions 93 The GeneralName structure is defined in [RFC5280], and supports many 94 different names forms including otherName for extensibility. This 95 section specifies the SmtpUtf8Name name form of otherName, so that 96 Internationalized Email addresses can appear in the subjectAltName of 97 a certificate, the issuerAltName of a certificate, or anywhere else 98 that GeneralName is used. 100 id-on-smtpUtf8Name OBJECT IDENTIFIER ::= { id-on 9 } 102 SmtpUtf8Name ::= UTF8String (SIZE (1..MAX)) 104 When the subjectAltName (or issuerAltName) extension contains an 105 Internationalized Email address, the address MUST be stored in the 106 SmtpUtf8Name name form of otherName. The format of SmtpUtf8Name is 107 defined as the ABNF rule SmtpUtf8Mailbox. SmtpUtf8Mailbox is a 108 modified version of the Internationalized Mailbox which is defined in 109 Section 3.3 of [RFC6531] which is itself derived from SMTP Mailbox 110 from Section 4.1.2 of [RFC5321]. [RFC6531] defines the following 111 ABNF rules for Mailbox whose parts are modified for 112 internationalization: , , , 113 , , and . In particular, 114 was updated to also support UTF8-non-ascii. UTF8-non-ascii is 115 described by Section 3.1 of [RFC6532]. Also, sub-domain is extended 116 to support U-label, as defined in [RFC5890]. 118 This document further refines Internationalized [RFC6531] Mailbox 119 ABNF rules and calls this SmtpUtf8Mailbox. In SmtpUtf8Mailbox, sub- 120 domain that encode non-ASCII characters SHALL use U-label Unicode 121 native character labels and MUST NOT use A-label [RFC5890]. This 122 restriction prevents having to determine which label encoding A- or 123 U-label is present in the Domain. As per Section 2.3.2.1 of 124 [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and 125 other properties specified there. In SmtpUtf8Mailbox, sub-domain 126 that encode solely ASCII character labels SHALL use NR-LDH 127 restrictions as specified by section 2.3.1 of [RFC5890] and 128 restricted to lower case letters. Note that a SmtpUtf8Mailbox has no 129 phrase (such as a common name) before it, has no comment (text 130 surrounded in parentheses) after it, and is not surrounded by "<" and 131 ">". 133 In the context of building name constraint as needed by [RFC5280], 134 the SmtpUtf8Mailbox rules are modified to allow partial productions 135 to allow for additional forms required by Section 6. Name 136 constraints may specify a complete email address, host name, or 137 domain. This means that the local-part may be missing, and domain 138 partially specified. 140 SmtpUtf8Name is encoded as UTF8String. The UTF8String encoding MUST 141 NOT contain a Byte-Order-Mark (BOM) [RFC3629] to aid consistency 142 across implementations particularly for comparison. 144 4. IDNA2008 146 To facilitate comparison between email addresses, all email address 147 domain in X.509 certificates MUST conform to IDNA2008 [RFC5890]. 148 Otherwise non-conforming email address domains introduces the 149 possibility of conversion errors between alternate forms. This 150 applies to SmtpUtf8Mailbox and rfc822Name in subjectAltName, 151 issuerAltName and anywhere else that GeneralName is used. 153 5. Matching of Internationalized Email Addresses in X.509 certificates 155 In equivalence comparison with SmtpUtf8Name, there may be some setup 156 work to enable the comparison i.e. processing of the SmtpUtf8Name 157 content or the email address that is being compared against. The 158 process for setup for comparing with SmtpUtf8Name is split into 159 domain steps and local-part steps. The comparison form for local- 160 part always is UTF-8. The comparison form for domain depends on 161 context. While some contexts such as certificate path validation in 162 [RFC5280] specify transforming domain to A-label, this document 163 RECOMMENDS transforming to UTF-8 U-label instead. This reduces the 164 likelihood of errors by reducing conversions as more implementations 165 natively support U-label domains. 167 Comparison of two SmtpUtf8Name can be straightforward. No setup work 168 is needed and it can be an octet for octet comparison. For other 169 email address forms such as Internationalized email address or 170 rfc822Name, the comparison requires additional setup to convert the 171 format for comparison. Domain setup is particularly important for 172 forms that may contain A- or U-label such as International email 173 address, or A-label only forms such as rfc822Name. This document 174 specifies the process to transform the domain to U-label. (To 175 convert the domain to A-label, follow the process specified in 176 section 7.5 and 7.2 in [RFC5280]) The first step is to detect A-label 177 by using section 5.1 of [RFC5891]. Next if necessary, transform the 178 A-label to U-label Unicode as specified in section 5.2 of [RFC5891]. 179 Finally if necessary convert the Unicode to UTF-8 as specified in 180 section 3 of [RFC3629]. For ASCII NR-LDH labels, upper case letters 181 are converted to lower case letters. In setup for SmtpUtf8Mailbox, 182 the email address local-part MUST conform to the requirements of 183 [RFC6530] and [RFC6531], including already being a string in UTF-8 184 form. In particular, the local-part MUST NOT be transformed in any 185 way, such as by doing case folding or normalization of any kind. The 186 part of an Internationalized email address is already in 187 UTF-8. For rfc822Name the local-part, which is IA5String (ASCII), 188 trivially maps to UTF-8 without change. Once setup is completed, 189 comparison is again checking for octet for octet equivalence. 191 To summarize non-normatively the domain setup steps are: 193 1. if the domain contains A-labels, transform them to U-label 195 2. if the domain contains ASCII NR-LDH labels, lowercase them 197 This enables an octet for octet comparison. 199 This specification expressly does not define any wildcards characters 200 and SmtpUtf8Name comparison implementations MUST NOT interpret any 201 character as wildcards. Instead, to specify multiple specifying 202 multiple email addresses through SmtpUtf8Name, the certificate should 203 use multiple subjectAltNames or issuerAltNames to explicitly carry 204 those email addresses. 206 6. Name constraints in path validation 208 This section defines use of SmtpUtf8Name name for name constraints. 209 The format for SmtpUtf8Name in name constraints is identical to the 210 use in subjectAltName as specified in Section 3 with the extension as 211 noted there for partial productions. 213 Constraint comparison on complete email address with SmtpUtf8Name 214 name uses the matching procedure defined by Section 5. As with 215 rfc822Name name constraints as specified in Section 4.2.1.10 of 216 [RFC5280], SmtpUtf8Name name can specify a particular mailbox, all 217 addresses at a host, or all mailboxes in a domain by specifying the 218 complete email address, a host name, or a domain. 220 Name constraint comparisons in the context [RFC5280] is specified 221 with SmtpUtf8Name name are only done on the subjectAltName (and 222 issuerAltName) SmtpUtf8Name name, and says nothing more about 223 constraints on other email address forms such as rfc822Name. 224 Consequently it may be necessary to include other name constraints 225 such as rfc822Name in addition to SmtpUtf8Name to constrain all 226 potential email addresses. For example a domain with both ASCII and 227 non-ASCII local-part email addresses may require both rfc822Name and 228 SmtpUtf8Name name constraints. This can be illustrated in the 229 following non-normative diagram Figure 1 which shows a name 230 constraint set in the intermediate CA certificate, which then applies 231 to the children entity certificates. Note that a constraint on 232 rfc822Name does not apply to SmtpUtf8Name and vice versa as is shown 233 in non-normative diagram Figure 2. 235 +--------------------------------------------------------------+ 236 | Root CA Cert | 237 +--------------------------------------------------------------+ 238 | 239 v 240 +--------------------------------------------------------------+ 241 | Intermediate CA Cert | 242 | Name Constraint Extension | 243 | Permitted | 244 | rfc822Name: allowed.example.com | 245 | SmtpUtf8Name: allowed.example.com | 246 | Excluded | 247 | rfc822Name: ignored.allowed.example.com | 248 +--------------------------------------------------------------+ 249 | 250 v 251 +--------------------------------------------------------------+ 252 | Entity Cert (w/explicitly permitted subjects) | 253 | SubjectAltName Extension | 254 | rfc822Name: student@allowed.example.com | 255 | SmtpUtf8Name: u+8001u+5E2B@allowed.example.com | 256 +--------------------------------------------------------------+ 258 Figure 1 260 +--------------------------------------------------------------+ 261 | Root CA Cert | 262 +--------------------------------------------------------------+ 263 | 264 v 265 +--------------------------------------------------------------+ 266 | Intermediate CA Cert | 267 | Name Constraint Extension | 268 | Permitted | 269 | rfc822Name: allowed.example.com | 270 | SmtpUtf8Name: allowed.example.com | 271 | Excluded | 272 | rfc822Name: ignored.allowed.example.com | 273 +--------------------------------------------------------------+ 274 | 275 v 276 +--------------------------------------------------------------+ 277 | Entity Cert (w/permitted subject i.e. excluded rfc822Name | 278 | does not exclude SmtpUtf8Name) | 279 | SubjectAltName Extension | 280 | SmtpUtf8Name: u+4E0Du+5C0D@ignored.allowed.example.com | 281 +--------------------------------------------------------------+ 283 Figure 2 285 7. Deployment Considerations 287 For email addresses whose local-part is ASCII it may be more 288 reasonable to continue using rfc822Name instead of SmtpUtf8Name. The 289 use of rfc822Name rather than SmtpUtf8Name is currently more likely 290 to be supported. Also use of SmtpUtf8Name incurs higher byte 291 representation overhead due to encoding with otherName and the 292 additional OID needed. This may be offset if domain requires non- 293 ASCII characters as smptUtf8Name supports U-label whereas rfc822Name 294 supports A-label. This document RECOMMENDS using SmtpUtf8Name when 295 local-part contains non-ASCII characters, and otherwise rfc822Name. 297 8. 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 9. IANA Considerations 311 This document makes use of object identifiers for the SmtpUtf8Name 312 defined in Section Section 3 and the ASN.1 module identifier defined 313 in Section Appendix A. IANA is kindly requested to make the 314 following assignments for: 316 The LAMPS-EaiAddresses-2016 ASN.1 module in the "SMI Security for 317 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 319 The SmtpUtf8Name otherName in the "PKIX Other Name Forms" registry 320 (1.3.6.1.5.5.7.8). 322 10. References 324 10.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 332 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 333 2003, . 335 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 336 Specifications: ABNF", STD 68, RFC 5234, 337 DOI 10.17487/RFC5234, January 2008, 338 . 340 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 341 Housley, R., and W. Polk, "Internet X.509 Public Key 342 Infrastructure Certificate and Certificate Revocation List 343 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 344 . 346 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 347 DOI 10.17487/RFC5321, October 2008, 348 . 350 [RFC5890] Klensin, J., "Internationalized Domain Names for 351 Applications (IDNA): Definitions and Document Framework", 352 RFC 5890, DOI 10.17487/RFC5890, August 2010, 353 . 355 [RFC5891] Klensin, J., "Internationalized Domain Names in 356 Applications (IDNA): Protocol", RFC 5891, 357 DOI 10.17487/RFC5891, August 2010, 358 . 360 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 361 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 362 February 2012, . 364 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 365 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 366 . 368 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 369 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 370 2012, . 372 10.2. Informative References 374 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 375 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 376 DOI 10.17487/RFC5912, June 2010, 377 . 379 Appendix A. ASN.1 Module 381 The following ASN.1 module normatively specifies the SmtpUtf8Name 382 structure. This specification uses the ASN.1 definitions from 383 [RFC5912] with the 2002 ASN.1 notation used in that document. 384 [RFC5912] updates normative documents using older ASN.1 notation. 386 LAMPS-EaiAddresses-2016 387 { iso(1) identified-organization(3) dod(6) 388 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 389 id-mod-lamps-eai-addresses-2016(TBD) } 391 DEFINITIONS IMPLICIT TAGS ::= 392 BEGIN 394 IMPORTS 395 OTHER-NAME 396 FROM PKIX1Implicit-2009 397 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 398 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 400 id-pkix 401 FROM PKIX1Explicit-2009 402 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 403 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; 405 -- 406 -- otherName carries additional name types for subjectAltName, 407 -- issuerAltName, and other uses of GeneralNames. 408 -- 410 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 412 SmtpUtf8OtherNames OTHER-NAME ::= { on-smtpUtf8Name, ... } 414 on-smtpUtf8Name OTHER-NAME ::= { 415 SmtpUtf8Name IDENTIFIED BY id-on-smtpUtf8Name 416 } 418 id-on-smtpUtf8Name OBJECT IDENTIFIER ::= { id-on 9 } 420 SmtpUtf8Name ::= UTF8String (SIZE (1..MAX)) 422 END 424 Figure 3 426 Appendix B. Example of SmtpUtf8Name 428 This non-normative example demonstrates using SmtpUtf8Name as an 429 otherName in GeneralName to encode the email address 430 "u+8001u+5E2B@example.com". 432 The hexidecimal DER encoding of the email address is: 433 A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 434 6D706C65 2E636F6D 436 The text decoding is: 437 0 34: [0] { 438 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' 439 14 20: [0] { 440 16 18: UTF8String '..@example.com' 441 : } 442 : } 444 Figure 4 446 The example was encoded on the OSS Nokalva ASN.1 Playground and the 447 above text decoding is an output of Peter Gutmann's "dumpasn1" 448 program. 450 Appendix C. Acknowledgements 452 Thank you to Magnus Nystrom for motivating this document. Thanks to 453 Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean 454 Leonard, Sean Turner, John Levine, Viktor Dukhovni and Patrik 455 Falstrom for their feedback. Also special thanks to John Klensin for 456 his valuable input on internationalization, Unicode and ABNF 457 formatting, and to Jim Schaad for his help with the ASN.1 example and 458 his helpful feedback. 460 Authors' Addresses 462 Alexey Melnikov (editor) 463 Isode Ltd 464 14 Castle Mews 465 Hampton, Middlesex TW12 2NP 466 UK 468 Email: Alexey.Melnikov@isode.com 470 Weihaw Chuang (editor) 471 Google, Inc. 472 1600 Amphitheatre Parkway 473 Mountain View, CA 94043 474 US 476 Email: weihaw@google.com