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/