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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/