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

[Wei Chuang <[e-mail]>]

On Sat, Jun 18, 2016 at 7:13 AM, Sean Leonard <[e-mail]> wrote:

> On 6/17/2016 11:35 AM, Wei Chuang wrote:
>
>
>
> 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.
>
>
> Okay.
>
>
> 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?
>
>
> TL;DR: I don't believe that rfc822Name [1] can formally or practically be
> deprecated unless you work closely with ITU-T, and evaluate market impact.
>
> The way that GeneralName works is that there are certain "core" name types
> that are given an explicit "CONTEXT-SPECIFIC" tag class identifier, leading
> to a very compact representation. rfc822Name is [1], dNSName is [2], etc.
>
> For "non-core types", GeneralName works using the general model of type
> extension using TYPE-IDENTIFIER, namely, an OID and the open type defined
> by the OID. The otherName extended type is itself tagged with [0]. When
> otherName = eaiName gets an OID, that OID is going to bloat the
> GeneralName, for each and every name. (We are only talking about ~10 bytes,
> but ~10 bytes multiplied over possibly multiple e-mail addresses multiplied
> over billions of certificates...and other protocols in which it might be
> used...) Moreover, it's going to make validation and name-comparing logic
> more complicated. Consider that Section 4.2.1.10 of RFC 5280 says that both
> dNSName and rfc822Name SHOULD be supported for name constraints.
>
> If the long-term goal is to use one field exclusively, it makes a lot more
> engineering sense to change the definition of rfc822Name to UTF8String, or,
> to add a new eaiName [9] UTF8String. Both of those paths will have to be
> done with ITU-T coordination. I have raised this issue before and the
> consensus on this list was against those approaches. Just pointing it out.
> As long as GeneralName is formally controlled by ITU-T X.509, if you want
> to take a step beyond "supporting eaiName" and go to "mandate eaiName and
> deprecate rfc822Name", you have to do something in X.509 to deprecate it.
> At that point, you may as well do something in X.509 to replace rfc822Name
> with a name form the compact way.
>

Got it.  Sure I can add language to restrict eaiName to when needed to
support UTF-8 local parts only.


>
>
>
>
>> 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.
>
>
> Section 7.2 of RFC 5280 only applies to dNSName field; it does not apply
> to other fields.
>

Sorry I should have been more precise for purposes of discussion as I
skipped a step.  See section 7.5 "Internationalized Electronic Mail
Addresses" which then points back to 7.2.


   To accommodate email
   addresses with internationalized domain names using the current
   structure, conforming implementations MUST convert the addresses into
   an ASCII representation.

   Where the host-part (the Domain of the Mailbox) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to the ASCII Compatible Encoding (ACE) format as specified in
Section <https://tools.ietf.org/html/rfc5280#section-7.2>
   7.2 <https://tools.ietf.org/html/rfc5280#section-7.2>.

   Two email addresses are considered to match if:

      1)  the local-part of each name is an exact match, AND

      2)  the host-part of each name matches using a case-insensitive
          ASCII comparison.


The approach in the draft comes from this precedence and a desire to
eliminate the conversation at verification time.

To do what your requesting, I think we need to get context as to why
RFC5280 converts domains to A-labels instead of U-labels.  Its certainly
useful to explore if this change is reasonable, as the upside is a more
compact representation and typically a simpler comparison- just have to
make sure there isn't a significant negative impact though.  Hopefully some
of the RFC5280 authors can help clarify why the domain in ASCII format is
required for comparison?

thanks,
-Wei


> That also doesn't change the fact that it's convoluted. :)
>
>
>
>> 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.
>
>
> Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't say
> anything about other name slots, including URI or rfc822Name. The reason
> why RFC 5280 says anything is because dNSName is limited to IA5String, but
> IDNs were "a real thing" back in 2008. EAI was not a real thing back then.
>
> If folks insist on case-sensitive comparison of the local-part and
> case-insensitive comparison of the domain part in the ASCII range, then
> maybe it makes more sense to define eaiName as:
> SEQUENCE {
>  localPart UTF8String,
>  domain IA5String }
>
> That way, an application can easily compare the localPart with memcmp
> (because it can contain NULLs), and the domain with stricmp. No hunting for
> quotations or "@" needed.
>
> The advantage of using U-labels (in conjunction with mandatory
> quote-or-no-quote rules) is that the eaiName can be represented in a single
> UTF8String, and can be compared in a single memcmp.
>
>
> Sean
>
>