Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Spencer,

Thank you for your comments.

On 27/12/2017 16:02, Spencer Dawkins wrote:
> ----------------------------------------------------------------------
> 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
Almost. Old implementations will just ignore such values in 
certificates, which is fine, 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.
My co-editor and I should double check that the text you quoted (at 
least the promise of explanation) is still accurate.
> 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?
I think fallback will depend on how certificates with SmtpUTF8Mailbox 
are to be used. If they are used with S/MIME, then an email client that 
supports EAI and S/MIME also need to be updated to support EAI in 
S/MIME. As there is no algorithmic mapping defined between non-ASCII 
SmtpUTF8Mailbox and traditional ASCII-only email addresses, your mileage 
will vary.

Similarly if this is used in TLS for user authentication, email server 
implementation need to be updated to recognize SmtpUTF8Mailbox in client 
TLS certificates.

Does this help or did I misunderstand the type of fallback you are 
talking about?

Best Regards,
Alexey
> 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.