Re: [Spasm] Different EAI options for carrying IDNs

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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
> 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] <mailto:[e-mail]>  
> 
> Example name constraint
>   rfc822Name            xn--pss25c.com <http://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 <http://xn--pss25c.com/>
>   rfc822Name            [e-mail] <mailto:[e-mail]>  
> 
> 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
> 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 <mailto:student@%E5%A4%A7%E5%AD%A6.com>
>   rfc822Name            [e-mail] <mailto:[e-mail]>  (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
> 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 <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm