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/