Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01

[Wei Chuang <[e-mail]>]

On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard <[e-mail]> wrote:

> A few additional points popped out at me:
>
> Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out
> plain (ASCII-only) e-mail addresses. This means that ASCII-only e-mail
> addresses can be "hidden" from implementations that don't support this new
> eai method. I am not in favor of this. The text is not really clear about
> whether non-internationalized email addresses are allowed in eaiName. It
> should be clear in saying that eaiName is restricted to internationalized
> email addresses, i.e., where there is at least one character beyond the
> ASCII range in the local-part. Email addresses that are limited to ASCII in
> the local-part MUST be encoded in rfc822Name only.
>

Handling coexistence of rfc822Name and eaiName is an interesting question
and in an ideal world we could switch from one to the other to reduce the
implementation cost.  Realistically we'll have to support both for awhile.
I think your suggestion is good which is to support both but restrict usage
and will likely reduce deployment confusion.  This consequence of this will
likely mean keeping rfc822Name and eaiName as acceptable email address
representations for the foreseeable future.

Let me pose another suggestion I received which is to start a transition to
eaiName- we could add a SHOULD recommendation that all future PKIX subject
email addresses be represented as eaiName, with language stating the intent
to transition to eaiName as the sole representation, along with a SHOULD
NOT on future usage of rfc822Name.  Some future revision could change this
to MUST/MUST-NOT.  What do you think of this approach?


>
> Can the ASN.1 reflect this with an appropriate string restriction?


> The comparison algorithm is convoluted.


Domain name represented in A-labels is what RFC5280 requires for its
verification process (step 7.2).  The draft just simply states insuring it
is represented as A-label in the certificate stored form to reduce risk of
translation error by verifier implementation.


> There will be implementations that don't bother with the convoluted
> algorithm, and running the convoluted algorithm over thousands or hundreds
> of millions of certificates is going to have a meaningful impact on
> performance. It's better to put the address in a form that is amenable to
> octet-by-octet comparison. This argues in favor of requiring the domain
> name to be in U-labels instead of A-labels, and to normalize case (to
> lowercase) for characters in the ASCII range.


A better place to ask for this change, is to update RFC5280 to mandate
comparison as U-label domains.  This draft is just taking the position that
there ought to be just one in certificate domain form which is going to be
whatever the RFC5280 comparison form is.

-Wei


>
>
> Sean
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>