Subject: [Spasm] Different EAI options for carrying IDNs

From: Wei Chuang <[email-masked]>
Date: Sun, 7 May 2017 15:42:24 -0700

Hi all,

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.

-Wei

=====

Option 1 is described in the -09 draft.  When the local part of a email
address
SAN is non-ASCII, the SAN is in SmtpUTF8Name form which carries the IDNs as
U-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as
A-label.
Name constraints always use rfc822Name as it only now represents hostname
and
domain only.

* FROM comparsion- no conversion for SmtpUTF8Name; conversion of FROM
U-Labels
  to A-label for comparison with rfc822Name; more frequent.
* Display- no conversion for SmtpUTF8Name; conversion of rfc822Name SAN
A-labels
  to U-label for display; more frequent.
* Name constraint- no conversion for rfc822Name SAN for path verification;
  conversion needed for SmptUTF8Name path verification where rfc822Name name
  constraint A-labels is converted to U-label; name constraints are very
  infrequently issued.
* Internationalization library needed for path verifier for name constraint
  conversion, FROM comparison and display.
* Lower byte overhead as rfc822Name more frequently used which is generally
  more compact.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name          [email-masked] <http://xn--pss25c.com>
  rfc822Name            [email-masked]

Example name constraint
  rfc822Name            xn--pss25c.com

Option 2 is described in Viktor and Russ's message, where IDNs are always
carried as A-Labels.  When the local part of a email address SAN is
non-ASCII,
the SAN is in SmtpUTF8Name form which carries the the IDNs as A-Labels,
otherwise the SAN is in rfc822Name which carries the IDNs as A-label.  Name
constraints always use rfc822Name as it only now represents hostname and
domain
only.

* FROM comparsion- conversion of FROM U-labels to A-labels for comparison
with
  rfc822Name and SmtpUTF8Name IDNs A-label; more frequent
* Display- conversion of rfc822Name and SmtpUTF8Name SAN IDNs A-labels to
  U-labels; more frequent
* Name constraint- No conversion of IDNs; name constraints are very
infrequently used.
* Internationalization library needed for FROM comparison and display.
* lower byte overhead as rfc822Name more frequently used which is generally
  more compact.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name          [email-masked]
  rfc822Name            [email-masked]

Example name constraint
  rfc822Name            xn--pss25c.com

Option 3 is described in William’s message where both SAN forms rfc822Name
and
SmtpUTF8Name are present for a given email address and represent equivalent
information (except when local-part can't be represented as in rfc822Name
and
non-ASCII local-part).  SmtpUTF8Name carries the IDNs as U-Labels while
rfc822Name carries the IDNs as A-labels.  Name constraints presumably
always use
rfc822Name and it only now represents hostname and domain only.

* FROM comparsion- Select SmtpUTF8Name for comparison which does not need
IDN
  label conversion; more frequent.
* Display- Select SmtpUTF8Name for display which does not need IDN label
  conversion; more frequent.
* Name constraint- Select rfc822Name for path verification comparison which
does
  not need IDN label conversion; name constraints are very infrequently
used.
* Internationalization library not needed for conversion.
* Higher byte overhead as duplicate SAN are present.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name          [email-masked] <http://xn--pss25c.com>
  SmtpUTF8Name          [email-masked]
  rfc822Name            [email-masked]  (equivalent to above)

Example name constraint
  rfc822Name            xn--pss25c.com

Option 4 is alluded to in Russ's and Viktor's emails (as an idealized
Option 1)
and takes some elements of -08.  The SAN of up-to-date issuers SHOULD use
the
SmtpUTF8Name form which carries the the IDNs as U-Labels for all email
addresses, though rfc822Name SAN which carries the the IDNs as A-Labels may
be
present particularly from legacy issuers.  Name constraints MUST now present
both SmtpUTF8Name and rfc822Name forms (for backwards compatibility), and
still
only represents hostname and domain only.

* FROM comparsion- No conversion for SmtpUTF8Name (though required for
legacy);
  more frequent.
* Display- No conversion for SmtpUTF8Name (though required for legacy); more
  frequent.
* Name constraint- Select form needed hence no conversion (though required
for
  legacy); name constraints are very infrequently used.
* Internationalization library needed for legacy or backwards compatibility
  during FROM comparison or path verification.
* Moderately more byte overhead as SmtpUTF8Name has an extra OID vs
rfc822Name.
  Some penalty for duplicate name constraint though that is infrequent.
* Fully backwards compatible.

Example SAN
  SmtpUTF8Name          [email-masked] <http://xn--pss25c.com>
  SmtpUTF8Name          [email-masked]

Example name constraint
  SmtpUTF8Name          大学.com <http://xn--pss25c.com>
  rfc822Name            xn--pss25c.com  (equivalent to above)

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 May 2017 18:00:12 -0400

I can live with either Option 1 or Option 2, but I have a preference for Option 1.  As was discussed in Chicago, the rfc822Name constraint works with both of these options.  With Option 1, the U-Labels in the SmtpUTF8Name need to be converted to A-Labels to enforce the constraints, but no conversion is need to display the SmtpUTF8Name.  With Option 2, the A-Labels in the SmtpUTF8Name need to be converted to U-Labels for display, but no conversion is need to to enforce the name constraints.  In both cases, the CA should make sure that conversion back and forth results in the same IDN, otherwise there will be errors in either display or name constraint enforcement.

I have already spoken against Option 3, and I will not repeat those points here.

I think the concerns with draft -08 that were discussed in Chicago apply to Option 4.  In particular, the need to provide independent name constraints for rfc822Name and SmtpUTF8Name will lead to trouble.

Russ

> On May 7, 2017, at 6:42 PM, Wei Chuang <[email-masked]> wrote:
> 
> Hi all,
> 
> 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
> different approaches of carrying IDNs solely as A-label (Option 2) and U-label
> 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.
> 
> -Wei
> 
> =====
> 
> Option 1 is described in the -09 draft.  When the local part of a email address
> U-Labels, otherwise the SAN is in rfc822Name which carries the IDNs as A-label.
> Name constraints always use rfc822Name as it only now represents hostname and
> domain only.
> 
> * FROM comparsion- no conversion for SmtpUTF8Name; conversion of FROM U-Labels
> * Display- no conversion for SmtpUTF8Name; conversion of rfc822Name SAN A-labels
>   SmtpUTF8Name          [email-masked] <http://xn--pss25c.com/>  
>   rfc822Name            [email-masked] <mailto:[email-masked]>  
> 
> Example name constraint
>   rfc822Name            xn--pss25c.com <http://xn--pss25c.com/>  
> 
> 
> carried as A-Labels.  When the local part of a email address SAN is non-ASCII,
> constraints always use rfc822Name as it only now represents hostname and domain
> only.
> 
> * FROM comparsion- conversion of FROM U-labels to A-labels for comparison with
> * Name constraint- No conversion of IDNs; name constraints are very infrequently used.
>   SmtpUTF8Name          [email-masked] <http://xn--pss25c.com/>
>   rfc822Name            [email-masked] <mailto:[email-masked]>  
> 
> Example name constraint
>   rfc822Name            xn--pss25c.com <http://xn--pss25c.com/>  
> 
> 
> Option 3 is described in William’s message where both SAN forms rfc822Name and
> information (except when local-part can't be represented as in rfc822Name and
> rfc822Name carries the IDNs as A-labels.  Name constraints presumably always use
> * FROM comparsion- Select SmtpUTF8Name for comparison which does not need IDN
> * Name constraint- Select rfc822Name for path verification comparison which does
>   not need IDN label conversion; name constraints are very infrequently used.
>   SmtpUTF8Name          [email-masked] <http://xn--pss25c.com/>
>   SmtpUTF8Name          [email-masked] <mailto:student@%E5%A4%A7%E5%AD%A6.com>
>   rfc822Name            [email-masked] <mailto:[email-masked]>  (equivalent to above)
> 
> Example name constraint
>   rfc822Name            xn--pss25c.com <http://xn--pss25c.com/>  
> 
> 
> Option 4 is alluded to in Russ's and Viktor's emails (as an idealized Option 1)
> and takes some elements of -08.  The SAN of up-to-date issuers SHOULD use the
> addresses, though rfc822Name SAN which carries the the IDNs as A-Labels may be
> both SmtpUTF8Name and rfc822Name forms (for backwards compatibility), and still
> * FROM comparsion- No conversion for SmtpUTF8Name (though required for legacy);
>   more frequent.
> * Name constraint- Select form needed hence no conversion (though required for
> * Moderately more byte overhead as SmtpUTF8Name has an extra OID vs rfc822Name.
>   SmtpUTF8Name          [email-masked] <http://xn--pss25c.com/>
>   SmtpUTF8Name          [email-masked] <mailto:student@%E5%A4%A7%E5%AD%A6.com>
> 
> Example name constraint
>   SmtpUTF8Name          大学.com <http://xn--pss25c.com/>
>   rfc822Name            xn--pss25c.com <http://xn--pss25c.com/>  (equivalent to above) 
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 May 2017 01:32:18 -0400

> anything in the summary.  Comments welcome, particularly about about a preferred

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.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 9 May 2017 10:38:04 +0300

Dear Victor,

> question of IDNA2003 transitional form and all that.  All that one needs

Are you ready to link openssl with punycode decoder or implement the
necessary functions in it?

Doesn't the Option 2 fit better? In that case the punycode decoder is
linked with applications
where we need it for visualization purpose, not with the library itself.

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 17:35:39 -0400

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 <[email-masked]> wrote:
> 
>