draft-ietf-lamps-rfc5280-i18n-update-03.txt		draft-ietf-lamps-rfc5280-i18n-update-04.txt
	INTERNET-DRAFT		INTERNET-DRAFT
	Internet Engineering Task Force R. Housley		Internet Engineering Task Force R. Housley
	Intended Status: Proposed Standard Vigil Security		Intended Status: Proposed Standard Vigil Security
	Updates: 5280 (once approved)		Updates: 5280 (once approved)
	Expires: 4 March 2018 4 September 2017		Expires: 12 April 2018 12 October 2017
	Internationalization Updates to RFC 5280		Internationalization Updates to RFC 5280
	draft-ietf-lamps-rfc5280-i18n-update-03		draft-ietf-lamps-rfc5280-i18n-update-04
	Abstract		Abstract
	These updates to RFC 5280 provide clarity on the handling of		These updates to RFC 5280 provide alignment with the 2008
	Internationalized Domain Names (IDNs) and Internationalized Email		specification for Internationalized Domain Names (IDNs) and add
	Addresses in X.509 Certificates.		support for Internationalized Email Addresses in X.509 Certificates.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	1. Introduction		1. Introduction
	This document updates RFC 5280 [RFC5280]. The Introduction in		This document updates RFC 5280 [RFC5280]. The Introduction in
	Section 1, the Name Constraints certificate extension discussion in		Section 1, the Name Constraints certificate extension discussion in
	Section 4.2.1.10, and the Processing Rules for Internationalized		Section 4.2.1.10, and the Processing Rules for Internationalized
	Names in Section 7 are updated to provide clarity on the handling of		Names in Section 7 are updated to provide alignment with the 2008
	Internationalized Domain Names (IDNs) and Internationalized Email		specification for Internationalized Domain Names (IDNs) and add
	Addresses in X.509 Certificates.		support for Internationalized Email Addresses in X.509 Certificates.
	An IDN in Unicode (native character) form contains at least one		An IDN in Unicode (native character) form contains at least one
	U-label [RFC5890]. With one exception, IDNs are carried in		U-label [RFC5890]. With one exception, IDNs are carried in
	certificates in ACE-encoded form. That is, all U-labels within an		certificates in ACE-encoded form. That is, all U-labels within an
	IDN are converted to A-labels. Conversion of an U-label to an		IDN are converted to A-labels. Conversion of an U-label to an
	A-label is described in [RFC5891].		A-label is described in [RFC5891].
	The GeneralName structure supports many different names forms,		The GeneralName structure supports many different names forms,
	including otherName for extensibility. [ID.lamps-eai-addresses]		including otherName for extensibility. [ID.lamps-eai-addresses]
	specifies the SmtpUTF8Mailbox for Internationalized Email addresses,		specifies the SmtpUTF8Mailbox for Internationalized Email addresses,
	which include IDNs with U-labels.		which include IDNs with U-labels.
	Note that Internationalized Domain Names in Applications		Note that Internationalized Domain Names in Applications
	specifications published in 2003 (IDNA2003) [RFC3490] and 2008		specifications published in 2003 (IDNA2003) [RFC3490] and 2008
	(IDNA2008) [RFC5890] both refer to the Punycode Algorithm for		(IDNA2008) [RFC5890] both refer to the Punycode Algorithm for
	conversion [RFC3492].		conversion [RFC3492].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. Updates		2. Updates
	This section provides updates to several paragraphs of RFC 5280		This section provides updates to several paragraphs of RFC 5280
	[RFC5280]. For clarity, if the entire section is not replaced, then		[RFC5280]. For clarity, if the entire section is not replaced, then
	the original text and the replacement text are shown.		the original text and the replacement text are shown.
	2.1. Update in Section 1, Introduction		2.1. Update in Section 1, Introduction
	This update provides references for IDNA2008.		This update provides references for IDNA2008.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 9 ¶
	of the string.		of the string.
	When comparing DNS names for equality, conforming implementations		When comparing DNS names for equality, conforming implementations
	MUST perform a case-insensitive exact match on the entire DNS name.		MUST perform a case-insensitive exact match on the entire DNS name.
	When evaluating name constraints, conforming implementations MUST		When evaluating name constraints, conforming implementations MUST
	perform a case-insensitive exact match on a label-by-label basis. As		perform a case-insensitive exact match on a label-by-label basis. As
	noted in Section 4.2.1.10, any DNS name that may be constructed by		noted in Section 4.2.1.10, any DNS name that may be constructed by
	adding labels to the left-hand side of the domain name given as the		adding labels to the left-hand side of the domain name given as the
	constraint is considered to fall within the indicated subtree.		constraint is considered to fall within the indicated subtree.
	Implementations should convert IDNs to Unicode before display.		Implementations SHOULD convert IDNs to Unicode before display.
	Specifically, conforming implementations should convert A-labels to		Specifically, conforming implementations convert A-labels to U-labels
	U-labels for display.		for display.
	Note: Implementations MUST allow for increased space requirements		Implementation consideration: There are increased memory
	for IDNs. An IDN ACE label will begin with the four additional		requirements for IDNs. An IDN ACE label will begin with the four
	characters "xn--" and may require as many as five ASCII characters to		additional characters "xn--", and an IDN can require as many as five
	specify a single international character.		ASCII characters to specify a single international character.
	2.3. Update in Section 7.3, IDNs in Distinguished Names		2.3. Update in Section 7.3, IDNs in Distinguished Names
	This update aligns with IDNA2008.		This update aligns with IDNA2008.
	OLD		OLD
	Domain Names may also be represented as distinguished names using		Domain Names may also be represented as distinguished names using
	domain components in the subject field, the issuer field, the		domain components in the subject field, the issuer field, the
	subjectAltName extension, or the issuerAltName extension. As with		subjectAltName extension, or the issuerAltName extension. As with
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 32 ¶
	Where the host-part contains an IDN, conforming implementations MUST		Where the host-part contains an IDN, conforming implementations MUST
	convert all U-labels to A-labels.		convert all U-labels to A-labels.
	Two email addresses are considered to match if:		Two email addresses are considered to match if:
	1) the local-part of each name is an exact match, AND		1) the local-part of each name is an exact match, AND
	2) the host-part of each name matches using a case-insensitive		2) the host-part of each name matches using a case-insensitive
	ASCII comparison.		ASCII comparison.
	Implementations should convert the host-part of internationalized		Implementations SHOULD convert the host-part of internationalized
	email addresses specified in these extensions to Unicode before		email addresses specified in these extensions to Unicode before
	display. Specifically, conforming implementations should convert		display. Specifically, conforming implementations convert A-labels
	A-labels to U-labels for display.		to U-labels for display.
	7.5.2. Local-part Contains Non-ASCII Characters		7.5.2. Local-part Contains Non-ASCII Characters
	When the local-part contains non-ASCII character, conforming		When the local-part contains non-ASCII character, conforming
	implementations MUST place the internationalized email address in the		implementations MUST place the internationalized email address in the
	SmtpUTF8Mailbox within the otherName choice of GeneralName as		SmtpUTF8Mailbox within the otherName choice of GeneralName as
	specified in Section 3 of [ID.lamps-eai-addresses]. Note that the		specified in Section 3 of [ID.lamps-eai-addresses]. Note that the
	UTF8 encoding of the internationalized email address MUST NOT contain		UTF8 encoding of the internationalized email address MUST NOT contain
	a Byte-Order-Mark (BOM) [RFC3629] to aid comparison.		a Byte-Order-Mark (BOM) [RFC3629] to aid comparison.
	The comparison of two internationalized email addresses is specified		The comparison of two internationalized email addresses is specified
	in Section 5 of [ID.lamps-eai-addresses].		in Section 5 of [ID.lamps-eai-addresses].
	Implementations should convert the local-part and the host-part of		Implementations SHOULD convert the host-part of internationalized
	internationalized email addresses placed in these extensions to		email addresses specified in these extensions to Unicode before
	Unicode before display.		display. Specifically, conforming implementations convert A-labels
			to U-labels for display.
	3. Security Considerations		3. Security Considerations
	Conforming CAs SHOULD ensure that IDNs are valid. This can be done		Conforming CAs SHOULD ensure that IDNs are valid. This can be done
	by validating all code points according to IDNA2008 [RFC5892].		by validating all code points according to IDNA2008 [RFC5892].
	Failure to use valid A-labels and valid U-labels may yield a domain		Failure to use valid A-labels and valid U-labels may yield a domain
	name that cannot be correctly represented in the Domain Name System		name that cannot be correctly represented in the Domain Name System
	(DNS). In addition, the CA/Browser Forum offers some guidance		(DNS). In addition, the CA/Browser Forum offers some guidance
	regarding internal server names in certificates [CABF].		regarding internal server names in certificates [CABF].
	4. IANA Considerations		4. IANA Considerations
	No IANA registries are changed by this update.		No IANA registries are changed by this update.
	5. Normative References		5. Normative References
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 31 ¶
	Melnikov, A. (Ed.) and W. Chuang (Ed.),		Melnikov, A. (Ed.) and W. Chuang (Ed.),
	"Internationalized Email Addresses in X.509 certificates",		"Internationalized Email Addresses in X.509 certificates",
	September 2017, <http://www.ietf.org/id/draft-ietf-lamps-		September 2017, <http://www.ietf.org/id/draft-ietf-lamps-
	eai-addresses>, work-in-progress.		eai-addresses>, work-in-progress.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI		Requirement Levels", BCP 14, RFC 2119, DOI
	10.17487/RFC2119, March 1997, <http://www.rfc-		10.17487/RFC2119, March 1997, <http://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
			[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
			for Internationalized Domain Names in Applications
			(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
			<http://www.rfc-editor.org/info/rfc3492>.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
			2003, <http://www.rfc-editor.org/info/rfc3629>.
	[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource		[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
	Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,		Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
	January 2005, <http://www.rfc-editor.org/info/rfc3987>.		January 2005, <http://www.rfc-editor.org/info/rfc3987>.
	[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol		[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
	(LDAP): Internationalized String Preparation", RFC 4518,		(LDAP): Internationalized String Preparation", RFC 4518,
	DOI 10.17487/RFC4518, June 2006, <http://www.rfc-		DOI 10.17487/RFC4518, June 2006, <http://www.rfc-
	editor.org/info/rfc4518>.		editor.org/info/rfc4518>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 26 ¶
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891, DOI		Applications (IDNA): Protocol", RFC 5891, DOI
	10.17487/RFC5891, August 2010, <http://www.rfc-		10.17487/RFC5891, August 2010, <http://www.rfc-
	editor.org/info/rfc5891>.		editor.org/info/rfc5891>.
	[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and		[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
	Internationalized Domain Names for Applications (IDNA)",		Internationalized Domain Names for Applications (IDNA)",
	RFC 5892, DOI 10.17487/RFC5892, August 2010,		RFC 5892, DOI 10.17487/RFC5892, August 2010,
	<http://www.rfc-editor.org/info/rfc5892>.		<http://www.rfc-editor.org/info/rfc5892>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017. <http://www.rfc-editor.org/info/rfc8174>.
	6. Informative References		6. Informative References
	[CABF] CA/Browser Forum, "Internal Server Names and IP Address		[CABF] CA/Browser Forum, "Internal Server Names and IP Address
	Requirements for SSL", Version 1.0, June 2012,		Requirements for SSL", Version 1.0, June 2012,
	<https://cabforum.org/internal-names/>		<https://cabforum.org/internal-names/>
	[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,		[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)",		"Internationalizing Domain Names in Applications (IDNA)",
	RFC 3490, DOI 10.17487/RFC3490, March 2003,		RFC 3490, DOI 10.17487/RFC3490, March 2003,
	<http://www.rfc-editor.org/info/rfc3490>.		<http://www.rfc-editor.org/info/rfc3490>.
	[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications
	(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<http://www.rfc-editor.org/info/rfc3492>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <http://www.rfc-editor.org/info/rfc3629>.
	Acknowledgements		Acknowledgements
	Thanks to Alexey Melnikov for the encouragement to write this update.		Thanks to Alexey Melnikov for the encouragement to write this update.
	Thanks to John Klensin and Patrik Falstrom for confirming many of the		Thanks to John Klensin and Patrik Falstrom for confirming many of the
	details in this update. Thanks to Wei Chuang, Phillip Hallam-Baker,		details in this update. Thanks to Ben Campbell, Wei Chuang, Spencer
	Alexey Melnikov, Tim Ruehsen, and Sean Turner for their careful		Dawkins, Phillip Hallam-Baker, Warren Kumari, Alexey Melnikov, Adam
	review and comments.		Roach, Tim Ruehsen, and Sean Turner for their careful review and
			comments.
	Authors' Address		Authors' Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 15 change blocks.
	36 lines changed or deleted		43 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/