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

[Sean Leonard <[e-mail]>]

On 6/17/2016 11:35 AM, Wei Chuang wrote:
>
>
> On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard <[e-mail] 
> <mailto:[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.


>
>     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.

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