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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Alexey,

On Mon, Jan 8, 2018 at 9:11 AM, Alexey Melnikov <[e-mail]>
wrote:

> 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?
>

This was helpful. Thanks. I trust that the right things will happen :-)

Spencer


>
> 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.
>>
>
>