Internationalized Email Addresses in X.509 Certificates
RFC 8398

Note: This ballot was opened for revision 15 and is now closed.

(Ben Campbell) (was No Objection, Discuss) Yes

Comment (2018-01-10 for -15)
No email
send info
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)"

(Eric Rescorla) Yes

Adam Roach Yes

Comment (2018-01-09 for -15)
No email
send info
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.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2017-12-27 for -15)
No email
send info
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

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.

Suresh Krishnan No Objection

Comment (2018-01-10 for -15)
No email
send info
I think some of the comparison issues brought up in RFC6943 might be relevant in the Security Considerations here.

Warren Kumari No Objection

Comment (2018-01-01 for -15)
No email
send info
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.

Mirja Kühlewind No Objection

Comment (2018-01-04 for -15)
No email
send info
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!

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Alexey Melnikov Recuse