Internationalized Email Addresses in X.509 Certificates
RFC 8398

Received changes through RFC Editor sync (changed abstract to 'This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.

This document updates RFC 5280.')

Received changes through RFC Editor sync (created alias RFC 8398, changed title to 'Internationalized Email Addresses in X.509 Certificates', changed abstract to 'This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.', changed pages to 12, 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-eai-addresses and RFC 5280)

[Ballot comment]
I cleared my DISCUSS concerning the need to update RFC 5280, since Russ tells me those updates are already in draft-ietf-lamps-rfc5280-i18n-update. However, I still think the text in sections 1, 4, and 6 should be clarified to avoid the impression that those updates are done by _this_ document.

Editorial Comments and Nits:

- section 3:
--  Please proofread section 3 for missing articles.
-- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..."  (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.")

- 4: "... (and avoids any "mappings" mentioned in that document)"
s/avoids/avoid

[Ballot comment]
Thanks for your work on this document. One thing I noticed is that the name for what I presume is an early registration at IANA ("id-on-smtputf8Name") varies from the final name used in this document ("id-on-smtputf8Mailbox"). I would ask the authors and shepherd to please carefully review the final IANA registrations upon document approval to ensure this is updated appropriately.

[Ballot comment]
Thanks for you work on this document. One thing I noticed is that the name for what I presume is an early registration at IANA ("id-on-smtputf8Name") varies from the final name used in this document ("id-on-smtputf8Mailbox"). I would ask the authors and shepherd to please carefully review the final IANA registrations upon document approval to ensure this is updated appropriately.

[Ballot discuss]
This should be easy to resolve, after which I plan to ballot "yes":

It seems like this needs to update at least RFC 5280. Section 4 creates what I assume to be a new requirement for all email address domains in X.509 certificates to conform to IDNA2008. That seems like a reasonable requirement, but if we want people reading 5280 to know about that requirement, we need the "updates" relationship.

Also, section explicitly says it updates a section of 5280.

[Ballot comment]
Editorial Comments and Nits:

- section 3:
--  Please proofread section 3 for missing articles.
-- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..."  (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.")

- 4: "... (and avoids any "mappings" mentioned in that document)"
s/avoids/avoid

[Ballot comment]
I don't know much about this subject, so I'm balloting 'No Objection', however, section 4 and section 6 read to me that this doc should update RFC5280. Please check!

[Ballot comment]
I found this clean and understandable; unfortunately, I know basically nothing about the subject matter and so am balloting NoObj instead of Yes.

Thanks to Ron Bonical for the OpsDir review.

[Ballot comment]
I know that you guys have been doing this longer than I've even been thinking about it, but I'm looking at

  Due to operational reasons to be described shortly and name
  constraint compatibility reasons described in Section 6,
  SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part
  of the email address contains non-ASCII characters.  When the local-
  part is ASCII, rfc822Name subjectAltName MUST be used instead of
  SmtpUTF8Mailbox.  This is compatible with legacy software that
  supports only rfc822Name (and not SmtpUTF8Mailbox).  The appropriate
  usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1
  below.

and, if I'm reading this correctly, the plan is

IF you don't NEED to send non-ASCII characters
use rfc822Name
and all implementations know what that means
                and all implementations will work fine
ELSE you DO have non-ASCII characters so
use SmtpUTF8Mailbox
and all the new implementations will work fine
and all the old implementations will barf
which is OK because they can't handle non-ASCII anyway

Am I getting that right? Assuming so, I looked at the "operational reasons to be described shortly" and "name constraint compatibility reasons described in Section 6", and didn't see anything that was was quite that blunt.

Assuming that you're sending SmtpUTF8Mailbox to an implementation that doesn't support it, and you figure that out, is there a well-understood fallback that could be either referenced or described in a sentence or two?

If the answer is "what an implementation does at that point is up to the implementation, and different implementations may have different reasons to respond differently", that could be a fine answer, of course.

[Ballot comment]
I know that you guys have been doing this longer than I've even been thinking about it, but I'm looking at

  Due to operational reasons to be described shortly and name
  constraint compatibility reasons described in Section 6,
  SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part
  of the email address contains non-ASCII characters.  When the local-
  part is ASCII, rfc822Name subjectAltName MUST be used instead of
  SmtpUTF8Mailbox.  This is compatible with legacy software that
  supports only rfc822Name (and not SmtpUTF8Mailbox).  The appropriate
  usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1
  below.

and, if I'm reading this correctly, the plan is

IF you don't NEED to send non-ASCII characters
use rfc822Name
and all implementations know what that means
and all implementations will work fine
ELSE you DO have non-ASCII characters so
use SmtpUTF8Mailbox
and all the new stuff will work fine
and all the old implementations will barf
which is OK because they can't handle non-ASCII anyway

Am I getting that right? Assuming so, I looked at the "operational reasons to be described shortly" and "name constraint compatibility reasons described in Section 6", and didn't see anything that was was quite that blunt.

Assuming that you're sending SmtpUTF8Mailbox to an implementation that doesn't support it, and you figure that out, is there a well-understood fallback that could be either referenced or described in a sentence or two?

If the answer is "what an implementation does at that point is up to the implementation, and different implementations may have different reasons to respond differently", that could be a fine answer, of course.

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

The IANA Services Operator has completed its review of draft-ietf-lamps-eai-addresses-15. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the SMI Security for PKIX Module Identifier registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a single, new registration will be made as follows:

Decimal [ TBD-at-Registration ]
Description: id-mod-lamps-eai-addresses-2016
Reference [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in the SMI Security for PKIX Other Name Forms also on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a single, new registration will be made as follows:

Decimal [ TBD-at-Registration ]
Description: id-on-SmtpUTF8Mailbox
Reference [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.


The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-09):

From: The IESG
To: IETF-Announce
CC: lamps-chairs@ietf.org, ekr@rtfm.com, Russ Housley , housley@vigilsec.com, draft-ietf-lamps-eai-addresses@ietf.org, spasm@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internationalized Email Addresses in X.509 certificates) 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: -
'Internationalized Email Addresses in X.509 certificates'
  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-10-09. 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


  This document defines a new name form for inclusion in the otherName
  field of an X.509 Subject Alternative Name and Issuer Alternative
  Name extension that allows a certificate subject to be associated
  with an Internationalized Email Address.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-housley-rfc5280-i18n-update: Internationalization Updates to RFC 5280 (None - )

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines a new name form for inclusion in the otherName
  field of an X.509 Subject Alternative Name and Issuer Alternate Name
  extension that allows a certificate subject to be associated with an
  Internationalized Email Address.

Working Group Summary

  The LAMPS WG reviewed the document and reached consensus on the
  content.

Document Quality

  Vendors associated with major implementations of S/MIME have
  indicated that they intend to support EAI, and this capability
  is needed for them to do so.

Personnel

  Document Shepherd: Russ Housley
  Responsible Area Director: Stephen Farrell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Russ Housley reviewed the document during WG Last Call.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  This document is about adding support for EAI to certificates for
  use by S/MIME.  It has been reviewed by people with a strong
  background in internationalization, PKIX, and S/MIME.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Both authors have stated that they are unaware of any IPR
  related to this work.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  During development of this document, it has been known by three
  Internet-Draft file names:
 
      - draft-ietf-pkix-eai-addresses
      - draft-melnikov-spasm-eai-addresses
      - draft-ietf-lamps-eai-addresses

  No IPR disclosures have been submitted against any of these names.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The LAMPS WG is pretty small, but the participants have the needed
  expertise for this document.  The consensus of the LAMPS WG is
  strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal or otherwise indicated discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits reports that two lines exceed 72 characters.  They are
  easy to correct, and there is no doubt that the RFC Editor will
  do so.

  IDnits incorrectly marks "[0]" as a reference, but it is an ASN.1
  tag, so those warnings need to be ignored.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews are required, and the document shepherd is
  the IANA expert for the registries that require assignments.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  RFC 5912 is an Informational RFC, but it is a normative reference.
  This may need to be called out in the IETF Last Call.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document shepherd is the IANA expert for the entries to be added.

  No new IANA registries are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The document shepherd is the IANA expert for the entries to be added.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ASN.1 module in Appendix A compiles properly.

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

The IANA Services Operator has completed its review of draft-ietf-lamps-eai-addresses-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the SMI Security for PKIX Module Identifier subregistry of the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry located at:

https://www.iana.org/assignments/smi-numbers/

the following registration will be made:

Decimal: [ TBD-at-Registration ]
Description: LAMPS-EaiAddresses-2016
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in the SMI Security for PKIX Other Name Forms subregistry of the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry located at:

https://www.iana.org/assignments/smi-numbers/

the following registration will be made:

Decimal: [ TBD-at-Registration ]
Description: SmtpUtf8Name
Reference: [ RFC-to-be ]

Because this registry also requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, housley@vigilsec.com, spasm@ietf.org, "Russ Housley" , stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internationalized Email Addresses in X.509 certificates) 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:
- 'Internationalized Email Addresses in X.509 certificates'
  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-01-30. 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


  This document defines a new name form for inclusion in the otherName
  field of an X.509 Subject Alternative Name and Issuer Alternate Name
  extension that allows a certificate subject to be associated with an
  Internationalized Email Address.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ballot/


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

RFC5912 is already noted as an acceptable downref.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines a new name form for inclusion in the otherName
  field of an X.509 Subject Alternative Name and Issuer Alternate Name
  extension that allows a certificate subject to be associated with an
  Internationalized Email Address.

Working Group Summary

  The LAMPS WG reviewed the document and reached consensus on the
  content.

Document Quality

  Vendors associated with major implementations of S/MIME have
  indicated that they intend to support EAI, and this capability
  is needed for them to do so.

Personnel

  Document Shepherd: Russ Housley
  Responsible Area Director: Stephen Farrell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Russ Housley reviewed the document during WG Last Call.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  This document is about adding support for EAI to certificates for
  use by S/MIME.  It has been reviewed by people with a strong
  background in internationalization, PKIX, and S/MIME.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Both authors have stated that they are unaware of any IPR
  related to this work.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  During development of this document, it has been known by three
  Internet-Draft file names:
 
      - draft-ietf-pkix-eai-addresses
      - draft-melnikov-spasm-eai-addresses
      - draft-ietf-lamps-eai-addresses

  No IPR disclosures have been submitted against any of these names.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The LAMPS WG is pretty small, but the participants have the needed
  expertise for this document.  The consensus of the LAMPS WG is
  strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal or otherwise indicated discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits reports that two lines exceed 72 characters.  They are
  easy to correct, and there is no doubt that the RFC Editor will
  do so.

  IDnits incorrectly marks "[0]" as a reference, but it is an ASN.1
  tag, so those warnings need to be ignored.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews are required, and the document shepherd is
  the IANA expert for the registries that require assignments.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  RFC 5912 is an Informational RFC, but it is a normative reference.
  This may need to be called out in the IETF Last Call.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document shepherd is the IANA expert for the entries to be added.

  No new IANA registries are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The document shepherd is the IANA expert for the entries to be added.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ASN.1 module in Appendix A compiles properly.

At IETF 97, the people in the room felt that this document was ready for WG Last Call.  Due to travel home from IETF 97 and the US Thanksgiving, many people felt that a 3 week last call was desirable.