[Spasm] Different EAI options for carrying IDNs

[Wei Chuang <[e-mail]>]

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          医生@大学.com <http://xn--pss25c.com>
  rfc822Name            [e-mail]

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          医生@xn--pss25c.com
  rfc822Name            [e-mail]

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          医生@大学.com <http://xn--pss25c.com>
  SmtpUTF8Name          student@大学.com
  rfc822Name            [e-mail]  (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          医生@大学.com <http://xn--pss25c.com>
  SmtpUTF8Name          student@大学.com

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