--- 1/draft-ietf-lamps-eai-addresses-09.txt 2017-05-19 12:13:09.463772180 -0700 +++ 2/draft-ietf-lamps-eai-addresses-10.txt 2017-05-19 12:13:09.491772858 -0700 @@ -1,19 +1,19 @@ LAMPS A. Melnikov, Ed. Internet-Draft Isode Ltd Intended status: Standards Track W. Chuang, Ed. -Expires: October 17, 2017 Google, Inc. - April 15, 2017 +Expires: November 19, 2017 Google, Inc. + May 18, 2017 Internationalized Email Addresses in X.509 certificates - draft-ietf-lamps-eai-addresses-09 + draft-ietf-lamps-eai-addresses-10 Abstract This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate Name extension that allows a certificate subject to be associated with an Internationalized Email Address. Status of This Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 17, 2017. + This Internet-Draft will expire on November 19, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -144,25 +144,26 @@ ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name supports A-label. SmtpUTF8Name is encoded as UTF8String. The UTF8String encoding MUST NOT contain a Byte-Order- Mark (BOM) [RFC3629] to aid consistency across implementations particularly for comparison. 4. IDNA2008 To facilitate comparison between email addresses, all email address - domain in X.509 certificates MUST conform to IDNA2008 [RFC5890]. - Otherwise non-conforming email address domains introduces the - possibility of conversion errors between alternate forms. This - applies to SmtpUTF8Mailbox and rfc822Name in subjectAltName, - issuerAltName and anywhere else that GeneralName is used. + domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and + excludes any "mappings" mentioned in that document). Otherwise non- + conforming email address domains introduces the possibility of + conversion errors between alternate forms. This applies to + SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and + anywhere else that GeneralName is used. 5. Matching of Internationalized Email Addresses in X.509 certificates In equivalence comparison with SmtpUTF8Name, there may be some setup work to enable the comparison i.e. processing of the SmtpUTF8Name content or the email address that is being compared against. The process for setup for comparing with SmtpUTF8Name is split into domain steps and local- part steps. The comparison form for local- part always is UTF-8. The comparison form for domain depends on context. While some contexts such as certificate path validation in @@ -208,66 +209,58 @@ This specification expressly does not define any wildcards characters and SmtpUTF8Name comparison implementations MUST NOT interpret any character as wildcards. Instead, to specify multiple email addresses through SmtpUTF8Name, the certificate SHOULD use multiple subjectAltNames or issuerAltNames to explicitly carry those email addresses. 6. Name constraints in path validation - This section updates [RFC5280] name constraints to work with - SmtpUTF8Name subjectAltName. In the following, a CA or path verifier - implementation that follows this specification is called SmtpUTF8Name - aware. - - SmtpUTF8Name aware path validators MUST be able to apply name - constraint to the subject distinguished name and both forms of - subject alternative name. That is rfc822Name name constraint applies - to emailAddress subject distinguished name, and to SmtpUTF8Name and - rfc822Name subject alternative name, as mentioned in Section 4.2.1.10 - of [RFC5280]. Constraint comparison with SmtpUTF8Name subjectAltName - uses the matching procedure defined by Section 5 including any setup - steps. The lack of a SmtpUTF8Name name constraint form is - intentional and motivated as described next. - - This specification requires that SmtpUTF8Name aware CAs continue to - issue certificates with rfc822Name name constraints form due to - compatibility concerns with legacy systems. Using rfc822Name name - constraints allows backwards compatibility with legacy path verifiers - that only understand rfc822Name form, yet is forward compatible by - being able to describe the intent of the CA to constrain both - rfc822Name and SmtpUTF8Name subjectAltName to SmtpUTF8Name aware path - verifiers. Oblivious legacy path verifier will not see the - SmtpUTF8Name subjectAltName (nor the unknown otherNames), and thereby - prevent the use of an unconstrained SmtpUTF8Name subjectAltName. + This section updates [RFC5280] name constraints defined in section + 4.2.1.10 to work with SmtpUTF8Name subjectAltName. The following + specifies that a SmtpUTF8Name aware CA use a compatible name + constraint representation. Similarly a SmtpUTF8Name aware path + validators MUST be able to apply name constraint comparison to the + subject distinguished name and both forms of subject alternative name + rfc822Name and SmtpUTF8Name. - Other implementations may detect an unknown otherNames, along with - the critical bit set on the name constraints extension and then fail - path verification. This too prevents use of an unconstrained - SmtpUTF8Name subjectAltName. A legacy CA will use rfc822Name name - constraints. As the CA's intent is to constrain all email addresses - matching the constraint, this will be forward compatible with a - SmtpUTF8Name aware path verifiers that applies the name constraint to - either forms rfc822Name and SmtpUTF8Name subjectAltName. + 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 representation of name constraints are specified in - Section 4.2.1.10 of [RFC5280] and there MAY 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. - This specification modifies [RFC5280] name constraint to only require - with a MAY that it represents all addresses at a host or all - mailboxes in a domain, and require with a MAY NOT that it represent a - particular mailbox. This is motivated by rfc822Name name constraints - inability to represent a specific mailbox with a UTF-8 email local - part email address. Certificate issuers should be aware of this - lessened support. + Constraint comparison with SmtpUTF8Name subjectAltName starts with + the setup steps defined by Section 5. The setup applies to the + inputs of the comparison which is one of a subject distinguished name + or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a + rfc822Name name constraint. Non-normatively the setup will convert + any domain A-label to U-label in the rfc822Name name constraint, and + to lower case any doman NR-LDH label in both the name constraint and + the subject. After setup, this follows the comparison steps defined + in 4.2.1.10 of [RFC5280] with some modifications as follows. The + comparison process starts by determining the name constraint + representation i.e. email host name or domain part, then comparing + the name constraint against the corresponding part in the email + address using a byte for byte comparison. This document suggests + that name constraint comparison with subject distinguished name or + rfc822Name subjectAltName also follow these setup and comparisons + steps as well. The name constraint requirement with SmtpUTF8Name subject alternative name is illustrated in the non-normative diagram Figure 1. The first example (1) illustrates a permitted rfc822Name ASCII only hostname name constraint, and the corresponding valid rfc822Name subjectAltName and SmtpUTF8Name subjectAltName email addresses. The second example (2) illustrates a permitted rfc822Name hostname name constraint with A-label, and the corresponding valid rfc822Name subjectAltName and SmtpUTF8Name subjectAltName email addresses. @@ -286,21 +279,21 @@ +-------------------------------------------------------------------+ | v +-------------------------------------------------------------------+ | Entity Cert (w/explicitly permitted subjects) | | SubjectAltName Extension | | rfc822Name: student@elemenary.school.example.com (1) | | SmtpUTF8Name: u+5B66u+751F@elementary.school.example.com (1) | | | | rfc822Name: student@xn--pss25c.example.com (2) | - | SmtpUTF8Name: u+533Bu+751F@xn--pss25c.example.com (2) | + | SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) | | | +-------------------------------------------------------------------+ Name constraints with SmtpUTF8Name and rfc822Name Figure 1 7. Security Considerations Use for SmtpUTF8Name for certificate subjectAltName (and