draft-ietf-lamps-eai-addresses-07.txt   draft-ietf-lamps-eai-addresses-08.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: September 9, 2017 Google, Inc. Expires: September 13, 2017 Google, Inc.
March 8, 2017 March 12, 2017
Internationalized Email Addresses in X.509 certificates Internationalized Email Addresses in X.509 certificates
draft-ietf-lamps-eai-addresses-07 draft-ietf-lamps-eai-addresses-08
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 September 9, 2017. This Internet-Draft will expire on September 13, 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 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 2 3. Name Definitions . . . . . . . . . . . . . . . . . . . . . . 2
4. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Matching of Internationalized Email Addresses in X.509 5. Matching of Internationalized Email Addresses in X.509
certificates . . . . . . . . . . . . . . . . . . . . . . . . 4 certificates . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Name constraints in path validation . . . . . . . . . . . . . 5 6. Name constraints in path validation . . . . . . . . . . . . . 5
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Example of SmtpUTF8Name . . . . . . . . . . . . . . 11 Appendix B. Example of SmtpUTF8Name . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
[RFC5280] defines rfc822Name subjectAltName choice for representing [RFC5280] defines rfc822Name subjectAltName choice for representing
[RFC5321] email addresses. This form is restricted to a subset of [RFC5321] email addresses. This form is restricted to a subset of
US-ASCII characters and thus can't be used to represent US-ASCII characters and thus can't be used to represent
Internationalized Email addresses [RFC6531]. To facilitate use of Internationalized Email addresses [RFC6531]. To facilitate use of
these Internationalized Email addresses with X.509 certificates, this these Internationalized Email addresses with X.509 certificates, this
document specifies a new name form in otherName so that document specifies a new name form in otherName so that
subjectAltName and issuerAltName can carry them. In addition this subjectAltName and issuerAltName can carry them. In addition this
skipping to change at page 5, line 44 skipping to change at page 5, line 44
rfc822Name name constraints as specified in Section 4.2.1.10 of rfc822Name name constraints as specified in Section 4.2.1.10 of
[RFC5280], SmtpUTF8Name name can specify a particular mailbox, all [RFC5280], SmtpUTF8Name name can specify a particular mailbox, all
addresses at a host, or all mailboxes in a domain by specifying the addresses at a host, or all mailboxes in a domain by specifying the
complete email address, a host name, or a domain. Name constraint complete email address, a host name, or a domain. Name constraint
comparisons in the context of [RFC5280] that are specified with comparisons in the context of [RFC5280] that are specified with
SmtpUTF8Name name are only done on the subjectAltName SmtpUTF8Name SmtpUTF8Name name are only done on the subjectAltName SmtpUTF8Name
name and not on other forms. Similarly rfc822Name name constraints name and not on other forms. Similarly rfc822Name name constraints
do not apply to subjectAltName SmtpUTF8Name name. This imposes do not apply to subjectAltName SmtpUTF8Name name. This imposes
requirements on the certificate issuer as described next. requirements on the certificate issuer as described next.
When name constraints are used with SmtpUTF8Name subjectAltName When name constraints are used with SmtpUTF8Name subject alternative
names, they are specified in the following profile to prevent names, the constraints are specified by the following changes to the
bypassing of name constraints. Host name and domain constraints MUST path validator to prevent bypass of the name constraints. The email
use both rfc822Name and SmtpUTF8Name forms in the issuing certificate address path validator in Section 6 of [RFC5280] is modified to
with the constraint. Complete email address constraint with UTF-8 consider:
local-part MUST only use SmtpUTF8Name form. Complete email address
constraint with ASCII local-part MUST use both rfc822Name and
SmtpUTF8Name forms. When both rfc822Name and SmtpUTF8Name name
constraints forms are present, they MUST carry the equivalent
constraints as defined by Section 5 and MUST be found in the same
node and in the same permittedSubtrees or excludedSubtrees. This
specification intentionally leaves unchanged rfc822Name name
constraint processing as described in Section 4.2.1.10 of [RFC5280].
This document specifies that SmtpUTF8Name aware path validators check 1. When neither rfc822Name nor SmtpUTF8Name name constraints are
for SmtpUTF8Name name constraint profiles as an additional path present in any issuer CA certificate, then path validation does
validation step in Section 6 of [RFC5280]. SmtpUTF8Name aware not add restrictions on children certificates with rfc822Name or
validators MUST NOT accept any certificate whose path contains an SmtpUTF8Name subject alternative names. That is any combination
issuing certificate whose rfc822Name or SmtpUTF8Name name constraints of rfc822Name or SmtpUTF8Name subject alternative names may be
do not match the above profile. That is the path validator verifies present.
that a rfc822Name name constraint has a corresponding SmtpUTF8Name
constraint and that a SmtpUTF8Name name constraint has a
corresponding rfc822Name constraint when the constraint contains host
name, domain or email address with an ASCII local-part. This
correspondence is required to be in the same issuing certificate node
and in the same nameConstraint permittedSubtrees or excludedSubtrees.
The name constraint requirement with SmtpUTF8Name subjectAltName is 2. If issuer CA certificates contain only rfc822Name name
illustrated in the following non-normative diagram Figure 1. This constraints, then those constraints apply to rfc822Name subject
show a SmtpUTF8Name aware issuer that constrained the intermediate CA alternative name in children certificates. SmtpUTF8Name subject
with host name and email address name constraints. In particular the alternative name are prohibited in those same certificates, that
email address constraint with UTF8 local-part only used a single is those certificates MUST be rejected by the path verifier.
SmtpUTF8Name name constraint, while the email address constraint with
ASCII local-part used both rfc822Name and SmtpUTF8Name name 3. When both rfc822Name and SmtpUTF8Name name constraints are
constraints. The next non-normative diagram Figure 2 illustrates present in all issuer CA certificates that have either form, then
legacy name constraints to contrasts the changes this document the path verifier applies the constraint of the subject
specifies. The legacy approach has only a single rfc822Name name alternative name form in children certificates. This allows any
combination of rfc822Name or SmtpUTF8Name subject alternative
names to be present and implies that the issuer has applied
appropriate name constraints. While commonly the alternative
forms will be equivalent, they need not be, as the forms can
represent features not present in its counterpart. One instance
of this is when the issuer wants to name constrain domain or
hostname using the rules of a particular form.
4. If some issuer CA certificates contain only SmtpUTF8Name name
constraints, then those are at risk of bypass with rfc822Name
subject alternative names when processed by legacy verifiers. To
prevent this, issuers MUST also publish rfc822Name name
constraint that prevent those bypasses. This occurs when both
rfc822Name and SmtpUTF8Name constraint forms can represents the
same host, domain or email address, and both are needed. Even
when the constraints are asymmetric such as when the issuer
wishes to constrain an email address with an UTF-8 local part, a
non empty rfc822Name name constraint may be needed if there isn't
one already so that the path verifier initializes correctly.
When both name constraints are present, the contents depends on the
usage. If the issuer desires to represent the same NR-LDH host or
domain, then it is the same string in both rfc822Name and
SmtpUTF8Name. If the host or domain labels contain UTF-8, then the
labels may be used directly in SmtpUTF8Name noting the restriction in
Section 5 and transformed to A-label for rfc822Name using the process
described in [RFC5280]. Email addresses that use ASCII local-part
use the same processing procedures for host or domain.
If the issuer wishes to represent the name constraint asymmetrically,
with either rfc822Name or SmtpUTF8Name to respectively represent some
A-label or U-label in the domain or host, the alternate name
constraint form must still be present. If nothing needs be
represented by the alternate form, then empty name constraint can
described by the "invalid" TLD that helps initialize the name
constraint path validation set. Or alternatively it may be omitted
if some other name constraint pair, provides a name constraint of
that form. In particular this initialization may be needed when
SmtpUTF8Name is used to represent an email address name constraint
with an UTF-8 local-part and rfc822Name cannot represent such a email
address constraint.
The name constraint requirement with SmtpUTF8Name subject alternative
name is illustrated in the non-normative diagram Figure 1 with
several examples. (3a) shows an issuer constraining a NR-LDH
hostname with rfc822Name and SmtpUTF8Name so that they can issue
ASCII and UTF-8 local-name email addresses certificates. (3b) shows
an issuer constraining a hostname containing a non-ASCII label for
u+5C0Fu+5B66 (elementary school). (3c) demonstrates that a hostname
constraint with an rfc822Name is distinguishable from its
SmtpUTF8Name constraint, and that only the rfc822Name form is
permitted. No 'invalid' SmtpUTF8Name constraint is needed since
other SmtpUTF8Name constraints are present. (3d) similarly
demonstrates this capability to restrict a name constraint to
SmtpUTF8Name only. (3e) shows that a non-ASCII local- part email
address can also be constrained to be permitted using SmtpUTF8Name.
It too does not need an 'invalid' rfc822Name as other rfc822Name
constrains are present. Diagram Figure 2 illustrates (non-
normatively) a different certificate chain that does need the
'invalid' name constraint. (3f) constrains a non-ASCII local-part
email address using a SmtpUTF8Name name constraint but requires a
rfc822Name 'invalid' constraint because it lacks any other rfc822Name
constraints needed to initialize the name constraint path
verification. The next non-normative diagram Figure 3 illustrates
legacy name constraints that contrasts the changes this document
specifies. The legacy approach (2) has only a single rfc822Name name
email address name constraint. email address name constraint.
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Root CA Cert | | Root CA Cert |
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| |
v v
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Intermediate CA Cert | | Intermediate CA Cert |
| Name Constraint Extension | | Permitted |
| Permitted | | rfc822Name: nr.ldh.host.example.com (3a) |
| rfc822Name: allowed_host.example.com | | SmtpUTF8Name: nr.ldh.host.example.com (3a) |
| SmtpUTF8Name: allowed_host.example.com | | |
| | | rfc822Name: u+5C0Fu+5B66.host.example.com (3b) |
| SmtpUTF8Name: u+8001u+5E2B@allowed_email.example.com | | SmtpUTF8Name: xn--48s3o.host.example.com (3b) |
| | | |
| rfc822Name: student@allowed_email.example.com | | rfc822Name: xn--pss25c.a.label.example.com (3c) |
| SmtpUTF8Name: student@allowed_email.example.com | | |
+--------------------------------------------------------------+ | SmtpUTF8Name: u+4E2Du+5B66.u.label.example.com (3d) |
| |
| SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3e) |
+-------------------------------------------------------------------+
| |
v v
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Entity Cert (w/explicitly permitted subjects) | | Entity Cert (w/explicitly permitted subjects) |
| SubjectAltName Extension | | SubjectAltName Extension |
| SmtpUTF8Name: u+533Bu+751F@allowed_host.example.com | | rfc822Name: student@nr.ldh.host.example.com (3a) |
| | | SmtpUTF8Name: u+5B66u+751F@nr.ldh.host.example.com (3a) |
| SmtpUTF8Name: u+8001u+5E2B@allowed_email.example.com | | |
| | | rfc822Name: student@u+5C0Fu+5B66.host.example.com (3b) |
| rfc822Name: student@allowed_email.example.com | | SmtpUTF8Name: u+5B66u+751F@xn--48s3o.host.example.com (3b) |
+--------------------------------------------------------------+ | |
| rfc822Name: student@xn--pss25c.a.label.example.com (3c) |
| |
| SmtpUTF8Name: student@u+4E2Du+5B66.u.label.example.com (3d) |
| |
| SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3e) |
+-------------------------------------------------------------------+
Name constraints with SmtpUTF8Name Name constraints with SmtpUTF8Name and rfc822Name
Figure 1 Figure 1
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Root CA Cert | | Root CA Cert |
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| |
v v
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Intermediate CA Cert | | Intermediate CA Cert |
| Name Constraint Extension | | Name Constraint Extension |
| Permitted | | Permitted |
| rfc822Name: allowed_host.example.com | | rfc822Name: invalid (3f) |
+--------------------------------------------------------------+ | SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3f) |
+-------------------------------------------------------------------+
| |
v v
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
| Entity Cert (w/explicitly permitted subjects) | | Entity Cert (w/explicitly permitted subjects) |
| SubjectAltName Extension | | SubjectAltName Extension |
| rfc822Name: student@allowed_host.example.com | | SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3f) |
+--------------------------------------------------------------+ +-------------------------------------------------------------------+
Legacy name constraints with rfc822Name Name constraints with SmtpUTF8Name email address and empty rfc822Name
Figure 2 Figure 2
+-------------------------------------------------------------------+
| Root CA Cert |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Intermediate CA Cert |
| Name Constraint Extension |
| Permitted |
| rfc822Name: student@email.example.com (2) |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Entity Cert (w/explicitly permitted subjects) |
| SubjectAltName Extension |
| rfc822Name: student@email.example.com (2) |
+-------------------------------------------------------------------+
Legacy name constraints with rfc822Name
Figure 3
7. Deployment Considerations 7. Deployment Considerations
For email addresses whose local-part is ASCII it may be more For email addresses whose local-part is ASCII it may be more
reasonable to continue using rfc822Name instead of SmtpUTF8Name. The reasonable to continue using rfc822Name instead of SmtpUTF8Name. The
use of rfc822Name rather than SmtpUTF8Name is currently more likely use of rfc822Name rather than SmtpUTF8Name is currently more likely
to be supported. Also use of SmtpUTF8Name incurs higher byte to be supported. Also use of SmtpUTF8Name incurs higher byte
representation overhead due to encoding with otherName and the representation overhead due to encoding with otherName and the
additional OID needed. This may be offset if domain requires non- additional OID needed. This may be offset if domain requires non-
ASCII characters as smptUtf8Name supports U-label whereas rfc822Name ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name
supports A-label. This document RECOMMENDS using SmtpUTF8Name when supports A-label. This document RECOMMENDS using SmtpUTF8Name when
local-part contains non-ASCII characters, and otherwise rfc822Name. local-part contains non-ASCII characters, and otherwise rfc822Name.
8. Security Considerations 8. Security Considerations
Use for SmtpUTF8Name for certificate subjectAltName (and Use for SmtpUTF8Name for certificate subjectAltName (and
issuerAltName) will incur many of the same security considerations of issuerAltName) will incur many of the same security considerations of
Section 8 in [RFC5280] but is further complicated by permitting non- Section 8 in [RFC5280] but is further complicated by permitting non-
ASCII characters in the email address local-part. This complication, ASCII characters in the email address local-part. This complication,
as mentioned in Section 4.4 of [RFC5890] and in Section 4 of as mentioned in Section 4.4 of [RFC5890] and in Section 4 of
skipping to change at page 11, line 43 skipping to change at page 12, line 50
on-SmtpUTF8Name OTHER-NAME ::= { on-SmtpUTF8Name OTHER-NAME ::= {
SmtpUTF8Name IDENTIFIED BY id-on-SmtpUTF8Name SmtpUTF8Name IDENTIFIED BY id-on-SmtpUTF8Name
} }
id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 } id-on-SmtpUTF8Name OBJECT IDENTIFIER ::= { id-on 9 }
SmtpUTF8Name ::= UTF8String (SIZE (1..MAX)) SmtpUTF8Name ::= UTF8String (SIZE (1..MAX))
END END
Figure 3 Figure 4
Appendix B. Example of SmtpUTF8Name Appendix B. Example of SmtpUTF8Name
This non-normative example demonstrates using SmtpUTF8Name as an This non-normative example demonstrates using SmtpUTF8Name as an
otherName in GeneralName to encode the email address otherName in GeneralName to encode the email address
"u+8001u+5E2B@example.com". "u+8001u+5E2B@example.com".
The hexadecimal DER encoding of the email address is: The hexadecimal DER encoding of the email address is:
A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861
6D706C65 2E636F6D 6D706C65 2E636F6D
The text decoding is: The text decoding is:
0 34: [0] { 0 34: [0] {
2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9'
14 20: [0] { 14 20: [0] {
16 18: UTF8String '..@example.com' 16 18: UTF8String '..@example.com'
: } : }
: } : }
Figure 4 Figure 5
The example was encoded on the OSS Nokalva ASN.1 Playground and the The example was encoded on the OSS Nokalva ASN.1 Playground and the
above text decoding is an output of Peter Gutmann's "dumpasn1" above text decoding is an output of Peter Gutmann's "dumpasn1"
program. program.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Thank you to Magnus Nystrom for motivating this document. Thanks to Thank you to Magnus Nystrom for motivating this document. Thanks to
Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean Russ Housley, Nicolas Lidzborski, Laetitia Baudoin, Ryan Sleevi, Sean
Leonard, Sean Turner, John Levine, Viktor Dukhovni and Patrik Leonard, Sean Turner, John Levine, and Patrik Falstrom for their
Falstrom for their feedback. Also special thanks to John Klensin for feedback. Also special thanks to John Klensin for his valuable input
his valuable input on internationalization, Unicode and ABNF on internationalization, Unicode and ABNF formatting, to Jim Schaad
formatting, and to Jim Schaad for his help with the ASN.1 example and for his help with the ASN.1 example and his helpful feedback, and to
his helpful feedback. Viktor Dukhovni for his help with name constraints.
Authors' Addresses Authors' Addresses
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 20 change blocks. 
97 lines changed or deleted 182 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/