Re: [Spasm] Different EAI options for carrying IDNs

[Russ Housley <[e-mail]>]

I agree with everything that Viktor has proposed with one, hopefully minor, point to discuss regarding comparison of rfc822Name.  My understanding is that the left-hand-side of the at sign is a case-sensitive compare, but the right-hand-side of the at sign is case-insensitive compare.

With the change to the name constraints discussed in Chicago, the name constraints never include the at sign or anything on the left-hand-side, so this has no impact on enforcing name constraints.  It does impact the comparison of the SAN (SubjectAltName) to the email message.

Russ


> On May 9, 2017, at 1:32 AM, Viktor Dukhovni <[e-mail]> wrote:
> 
> 
>> On May 7, 2017, at 6:42 PM, Wei Chuang <[e-mail]> wrote:
>> 
>> To resolve the direction of the EAI draft, I've tried to summarize the different
>> options from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 and
>> highlight particular features that might help differentiate the approaches.  In
>> particular there might have been confusion with the earlier Option 1, so this
>> describes draft -09 take on it.  This then tries to summarize the two very
>> different approaches of carrying IDNs solely as A-label (Option 2) and U-label
>> (Option 4).  This also describes the option of providing both SAN forms
>> rfc822Name and SmtpUTF8Name that was brought up in the thread as well (Option 3). 
>> I've tried CC'ing the folks who proposed these different options, in case I've missed
>> anything in the summary.  Comments welcome, particularly about about a preferred
>> direction.
> 
> This is clearly a difficult area to pin down without being *very* precise in
> one's language.  Some of the alternatives described, that are attributed to
> me differ from what I actually attempted to propose.  So whatever we ultimately
> agree on, it will be very important that the draft describe it clearly, in detail,
> with good examples, and with strategic redundancy (i.e. repetition) that it will
> be unlikely to be misconstrued.
> 
> My preference at this point is I think roughly option 1.  That is:
> 
> 1.  When the localpart is ASCII, store the SAN as an rfc822Name SAN with
>    U-labels in the domain part encoded as A-labels.
> 
>    1.1.  The CA must make sure that the U-labels corresponding to any A-labels
>    used are valid IDNA2008 U-labels (without application of any "mappings").
>    All A-labels must be lower-case ASCII.
> 
>    1.2.  When comparing against the reference identifier, decode the A-labels
>    in the SAN back to U-labels (this just requires a punycode decoder,
>    and does not require an IDN library).  Likewise convert any A-labels
>    in the From address back to U-labels.  Then compare NR-LDH labels
>    case-insensitively, but compare U-labels byte for byte.
> 
>    1.3  The comparison with rc822Name constraints is case-insensitive as
>         it has always been.
> 
> 2.  When the localpart is not ASCII, store the SAN as SMTPUtf8Name with
>    U-labels replacing any A-labels in the domain part.
> 
>    2.1.  The CA must make sure that the U-labels are valid IDNA2008 U-labels
>          (without application of any "mappings")
> 
>    2.2.  When comparing an SMTPUTF8Name SAN against the From address, decode
>          any A-labels in the From address to U-labels.  The compare the result
>          with the SAN, comparing NR-LDH labels case insensitively, and U-labels
>          byte for byte.
> 
>    2.3   The comparison with rfc822Name constraints is done by decoding A-labels
>          in the name constraint to U-labels and comparing with the labels in the
>          SAN as above (case-insensitive for NR-LDH, verbatim for U-labels).
> 
> Note that I am careful to avoid all U-label -> A-label conversions.  Rather all
> conversions are from A-labels to U-labels, and trusted CAs are expected to only
> generate A-labels that decode to valid IDNA2008 U-labels.  This avoids the whole
> question of IDNA2003 transitional form and all that.  All that one needs is a
> punycode decoder.
> 
> -- 
> -- 
> 	Viktor.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm