Internationalized Email Addresses in X.509 Certificates
draft-ietf-lamps-eai-addresses-18
Yes
(Eric Rescorla)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Kathleen Moriarty)
Recuse
(Alexey Melnikov)
Note: This ballot was opened for revision 15 and is now closed.
Warren Kumari
No Objection
Comment
(2018-01-01 for -15)
Unknown
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.
Adam Roach Former IESG member
Yes
Yes
(2018-01-09 for -15)
Unknown
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.
Ben Campbell Former IESG member
(was No Objection, Discuss)
Yes
Yes
(2018-01-10 for -15)
Unknown
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
Eric Rescorla Former IESG member
Yes
Yes
(for -15)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -15)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -15)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -15)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-01-04 for -15)
Unknown
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!
Spencer Dawkins Former IESG member
No Objection
No Objection
(2017-12-27 for -15)
Unknown
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.
Suresh Krishnan Former IESG member
No Objection
No Objection
(2018-01-10 for -15)
Unknown
I think some of the comparison issues brought up in RFC6943 might be relevant in the Security Considerations here.
Alexey Melnikov Former IESG member
Recuse
Recuse
(for -15)
Unknown