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/