Skip to main content

Internationalization Updates to RFC 5280
RFC 8399

Revision differences

Document history

Date Rev. By Action
2018-05-23
04 (System)
Received changes through RFC Editor sync (created alias RFC 8399, changed abstract to 'The updates to RFC 5280 described in this document provide alignment …
Received changes through RFC Editor sync (created alias RFC 8399, changed abstract to 'The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-05-23, changed IESG state to RFC Published, created updates relation between draft-ietf-lamps-rfc5280-i18n-update and RFC 5280)
2018-05-23
04 (System) RFC published
2018-05-21
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8399">AUTH48-DONE</a> from AUTH48
2018-05-09
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8399">AUTH48</a> from RFC-EDITOR
2018-05-07
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-03-23
04 (System) RFC Editor state changed to EDIT from MISSREF
2018-02-24
04 Russ Housley Added to session: IETF-101: lamps  Fri-1150
2018-01-02
04 (System) IANA Action state changed to No IC from In Progress
2018-01-02
04 (System) IANA Action state changed to In Progress
2018-01-02
04 (System) RFC Editor state changed to MISSREF
2018-01-02
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-01-02
04 (System) Announcement was received by RFC Editor
2018-01-01
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-01-01
04 Cindy Morgan IESG has approved the document
2018-01-01
04 Cindy Morgan Closed "Approve" ballot
2018-01-01
04 Cindy Morgan Ballot writeup was changed
2018-01-01
04 Cindy Morgan Ballot approval text was generated
2018-01-01
04 Cindy Morgan Ballot writeup was changed
2017-12-27
04 Eric Rescorla This is ready for the announcement
2017-12-27
04 Eric Rescorla IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2017-11-12
04 Eric Rescorla IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2017-10-29
04 Russ Housley Added to session: IETF-100: lamps  Mon-0930
2017-10-18
04 Adam Roach [Ballot comment]
Thanks for addressing my DISCUSS.
2017-10-18
04 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2017-10-12
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-12
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-10-12
04 Russ Housley New version available: draft-ietf-lamps-rfc5280-i18n-update-04.txt
2017-10-12
04 (System) New version approved
2017-10-12
04 (System) Request for posting confirmation emailed to previous authors: Russ Housley <housley@vigilsec.com>
2017-10-12
04 Russ Housley Uploaded new revision
2017-10-12
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-10-12
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-10-12
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tom Yu.
2017-10-11
03 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2017-10-11
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-10-11
03 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-10-10
03 Ben Campbell [Ballot comment]
-1.1: Please consider using the boilerplate from 8174. There's at least at least one use of a lower-case "should" (in 7.5.1, last paragraph).
2017-10-10
03 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-10-10
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-10-10
03 Adam Roach
[Ballot discuss]
The final paragraph in Section 2.4 reads:

  Implementations should convert the local-part and the host-part of
  internationalized email addresses placed in …
[Ballot discuss]
The final paragraph in Section 2.4 reads:

  Implementations should convert the local-part and the host-part of
  internationalized email addresses placed in these extensions to
  Unicode before display.

The mention of converting "local-part" to "Unicode" has a very strong implication that the local-part of internationalized email addresses can be (should be?) ACE-encoded (or otherwise converted to some non-Unicode encoding). Unless my understanding of internationalized email addresses is wildly wrong (and that may be the case), this isn't how they work: the local-part *is* in Unicode, and so conversion to Unicode doesn't make sense.

This seems highly likely to lead developers down the path of ACE-encoding the local-part component of email addresses, which would cause incompatibilities.
2017-10-10
03 Adam Roach Ballot discuss text updated for Adam Roach
2017-10-10
03 Adam Roach
[Ballot discuss]
The final paragraph in Section 2.4 reads:

  Implementations should convert the local-part and the host-part of
  internationalized email addresses placed in …
[Ballot discuss]
The final paragraph in Section 2.4 reads:

  Implementations should convert the local-part and the host-part of
  internationalized email addresses placed in these extensions to
  Unicode before display.

The mention of converting "local-part" to "Unicode" has a very strong implication that the local-part of internationalized email addresses can (should be?) ACE-encoded (or otherwise converted to some non-Unicode encoding). Unless my understanding of internationalized email addresses is wildly wrong (and that may be the case), this isn't how they work: the local-part *is* in Unicode, and so conversion to Unicode doesn't make sense.

This seems highly likely to lead developers down the path of ACE-encoding the local-part component of email addresses, which would cause incompatibilities.
2017-10-10
03 Adam Roach
[Ballot comment]
The document has several instances of (lower-case) "should" where talking about implementation behavior. These look like they should be normative to me -- …
[Ballot comment]
The document has several instances of (lower-case) "should" where talking about implementation behavior. These look like they should be normative to me -- if that's the intention, please make them uppercase. If not, please update to RFC 8174 boilerplate.

The document contains the following normative requirement:

  Note:  Implementations MUST allow for increased space requirements
  for IDNs.

It's hard to determine what an implementation needs to do in order to satisfy this normative requirement. Presumably, "increased" is relative to previous buffer allocations for domain names? Also, the statement can be satisfied as stated by simply increasing such buffers by a single byte. Surely that's not what's intended, is it?

(Aside: I find the use of "Note:" preceding normative text to be confusing, so you might want to remove it)
2017-10-10
03 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2017-10-10
03 Warren Kumari
[Ballot comment]
I had the same question as Spencer -- I'd be interested to know what lack of clarity was (so that people who were …
[Ballot comment]
I had the same question as Spencer -- I'd be interested to know what lack of clarity was (so that people who were unclear, and read this will know what they might have guessed at!). I'm really not knowledgable in this field, so feel free to ignore if this would have been obvious to anyone reading 5280...
2017-10-10
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-10-10
03 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2017-10-08
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2017-10-05
03 Spencer Dawkins
[Ballot comment]
You folks would know best what's actually clear to your intended audience, but the use of  "provide clarity on the handling of" in …
[Ballot comment]
You folks would know best what's actually clear to your intended audience, but the use of  "provide clarity on the handling of" in the Abstract,

  These updates to RFC 5280 provide clarity on the handling of
  Internationalized Domain Names (IDNs) and Internationalized Email
  Addresses in X.509 Certificates.

and in the first paragraph of the Introduction,

  This document updates RFC 5280 [RFC5280].  The Introduction in
  Section 1, the Name Constraints certificate extension discussion in
  Section 4.2.1.10, and the Processing Rules for Internationalized
  Names in Section 7 are updated to provide clarity on the handling of
  Internationalized Domain Names (IDNs) and Internationalized Email
  Addresses in X.509 Certificates.

wasn't particularly helpful to me.  Are there a few words that would describe (at a high level) what the problem with RFC 5280 was, that required this document (I'm suggesting saying "so if you implemented RFC 5280, you can expect problems A and B, so you probably want to implement this specification as well", but in different words)?
2017-10-05
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-10-05
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-09-28
03 Joel Halpern Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2017-09-28
03 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2017-09-28
03 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2017-09-25
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2017-09-23
03 Eric Rescorla Placed on agenda for telechat - 2017-10-12
2017-09-23
03 Eric Rescorla IESG state changed to IESG Evaluation from Waiting for Writeup
2017-09-23
03 Eric Rescorla Ballot has been issued
2017-09-23
03 Eric Rescorla [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla
2017-09-23
03 Eric Rescorla Created "Approve" ballot
2017-09-23
03 Eric Rescorla Ballot writeup was changed
2017-09-04
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-09-04
03 Russ Housley New version available: draft-ietf-lamps-rfc5280-i18n-update-03.txt
2017-09-04
03 (System) New version approved
2017-09-04
03 (System) Request for posting confirmation emailed to previous authors: Russ Housley <housley@vigilsec.com>
2017-09-04
03 Russ Housley Uploaded new revision
2017-08-08
02 Mahesh Jethanandani Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani. Sent review to list.
2017-07-25
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-07-17
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2017-07-17
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2017-07-16
02 Russ Housley Added to session: IETF-99: lamps  Mon-1740
2017-07-14
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-07-14
02 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-lamps-rfc5280-i18n-update-02.txt, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-lamps-rfc5280-i18n-update-02.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-07-13
02 Joel Halpern Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2017-07-13
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tom Yu
2017-07-13
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tom Yu
2017-07-13
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2017-07-13
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2017-07-11
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-07-11
02 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Phillip Hallam-Baker <phill@hallambaker.com>, ekr@rtfm.com …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Phillip Hallam-Baker <phill@hallambaker.com>, ekr@rtfm.com, phill@hallambaker.com, Russ Housley <housley@vigilsec.com>, lamps-chairs@ietf.org, spasm@ietf.org, draft-ietf-lamps-rfc5280-i18n-update@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-lamps-rfc5280-i18n-update-02.txt> (Internationalization Updates to RFC 5280) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Internationalization Updates to RFC 5280'
  <draft-ietf-lamps-rfc5280-i18n-update-02.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  These updates to RFC 5280 provide clarity on the handling of
  Internationalized Domain Names (IDNs) and Internationalized Email
  Addresses in X.509 Certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-07-11
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-07-11
02 Amy Vezza Last call announcement was changed
2017-07-10
02 Eric Rescorla Last call was requested
2017-07-10
02 Eric Rescorla Last call announcement was generated
2017-07-10
02 Eric Rescorla Ballot approval text was generated
2017-07-10
02 Eric Rescorla Ballot writeup was generated
2017-07-10
02 Eric Rescorla IESG state changed to Last Call Requested from AD Evaluation
2017-07-10
02 Eric Rescorla IESG state changed to AD Evaluation from Publication Requested
2017-06-23
02 Russ Housley
Shepherd Write-up for draft-ietf-lamps-rfc5280-i18n-update-02

1. Summary

The document shepherd is Phillip Hallam-Baker. The responsible Area Director is Eric Rescorla.

This new RFC will update RFC …
Shepherd Write-up for draft-ietf-lamps-rfc5280-i18n-update-02

1. Summary

The document shepherd is Phillip Hallam-Baker. The responsible Area Director is Eric Rescorla.

This new RFC will update RFC 5280, which is a Proposed Standard.

This document specifies updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The changes in this document are essentially a changelog on RFC 5280. Additional material relating to email addresses is presented separately in draft-ietf-lamps-eai-addresses-11.txt

The actual encoding of internationalized characters in a certificate is almost straightforward, Unicode works. One major complicating factor is that a PKIX certificate is encoded in ASN.1 which provides multiple mechanisms for character encoding and internationalized DNS names are encoded in yet another encoding which provides multiple options.

For the purposes of PKIX, it is important that the specification pick one encoding and stick to it. PKIX certificate signing certificates may contain name constraints limiting the set of valid end entity certificates that can be signed in a path that contains them. This is used in the field to mitigate the potential damage resulting from compromise of an local issuer. So Carol CA may issue a certificate to example.com allowing it to issue certificates for S/MIME users <any>@example.com using a locally held key but cannot (validly) sign any other certificates.

The specification requires all the DNS labels to be encoded in ACE form which is a canonical form for DNS labels. 5280 allowed constraints to be specific to a particular address, this has been removed as rarely used and introducing unnecessary complications.

The chief security problem faced in the use of internationalized characters in a security specification is that multiple code points in the character set map to identical or near identical glyphs. Attacks exploiting this feature are known as homomorphic attacks and are widely understood as a problem in the field. This document is largely a codification of restrictions that represent common but largely undocumented practice.

This is addressed (although not necessarily for every conceivable corner case) by RFC 5892 (known as IDNA2008) this is incorporated into the PKIX specification in this draft and further consideration given to the issue in draft-ietf-lamps-eai-addresses-11.txt.

2. Review and Consensus

This draft contains the uncomplicated and uncontroversial parts of the problem. Some of the changes are already implied in prior RFCs. The remainder are of the ‘just pick one’ variety.

There has been little discussion on the list on this document but considerably more on the companion. Patrik Fältström read and approved the document. Minor updates made. Further minor updates were made to clear nits in the -02 version in response to queries from the Shepherd. No nits remain, the four comments being for known issues that are addressed.

The draft was discussed by the WG in Chicago as part of the general IDN discussion.

3. Intellectual Property

The author reports no IPR issues and none have been reported.

4. Other Points

Normative reference to draft-ietf-lamps-eai-addresses-11.txt



Proposed Document Announcement Write-Up:

  Technical Summary:

    This document provides updates to RFC 5280 regarding the handling of
    Internationalized Domain Names (IDNs) and Internationalized Email
    Addresses in X.509 Certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    X.509 certificates are supported by many Certification Authorities
    and relying parties, especially browsers and S/MIME clients. Several
    implementers have said that they will implement the features in this
    document.
2017-06-23
02 Russ Housley Responsible AD changed to Eric Rescorla
2017-06-23
02 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-06-23
02 Russ Housley IESG state changed to Publication Requested
2017-06-23
02 Russ Housley IESG process started in state Publication Requested
2017-06-23
02 Russ Housley Notification list changed to Phillip Hallam-Baker <phill@hallambaker.com>, Russ Housley <housley@vigilsec.com> from Phillip Hallam-Baker <phill@hallambaker.com>
2017-06-23
02 Russ Housley Changed document writeup
2017-06-23
02 Russ Housley Notification list changed to Phillip Hallam-Baker <phill@hallambaker.com>
2017-06-23
02 Russ Housley Document shepherd changed to Phillip Hallam-Baker
2017-06-23
02 Russ Housley New version available: draft-ietf-lamps-rfc5280-i18n-update-02.txt
2017-06-23
02 (System) New version approved
2017-06-23
02 (System) Request for posting confirmation emailed to previous authors: Russ Housley <housley@vigilsec.com>
2017-06-23
02 Russ Housley Uploaded new revision
2017-06-14
01 Russ Housley New version available: draft-ietf-lamps-rfc5280-i18n-update-01.txt
2017-06-14
01 (System) New version approved
2017-06-14
01 (System) Request for posting confirmation emailed to previous authors: Russ Housley <housley@vigilsec.com>
2017-06-14
01 Russ Housley Uploaded new revision
2017-05-09
00 Russ Housley Changed consensus to Yes from Unknown
2017-05-09
00 Russ Housley Intended Status changed to Proposed Standard from None
2017-05-09
00 Russ Housley This document now replaces draft-housley-rfc5280-i18n-update instead of None
2017-05-09
00 Russ Housley New version available: draft-ietf-lamps-rfc5280-i18n-update-00.txt
2017-05-09
00 (System) WG -00 approved
2017-05-09
00 Russ Housley Set submitter to "Russ Housley <housley@vigilsec.com>", replaces to (none) and sent approval email to group chairs: lamps-chairs@ietf.org
2017-05-09
00 Russ Housley Uploaded new revision