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

From: Sean Leonard <[email-masked]>
Date: Thu, 16 Jun 2016 06:31:36 -0700

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.

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

The comparison algorithm is 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.

Sean

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 16 Jun 2016 10:34:10 -0700

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: Thursday, June 16, 2016 6:32 AM
> To: [email-masked]
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
> 
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.

Almost nobody implements it but it would be

eaiName ::= UTF8String (SIZE(1..MAX)) (PATTERN [^!-}]*)

The pattern can probably be improved if one has a better sense of what
characters are permitted in an email address.  This one just says don't
allow for any string which consists of just these characters.

This is probably a case where you do not care if the pattern matches too
many items as one would not care if you matched things which were not email
addresses.

Jim

> 
> The comparison algorithm is 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.
> 
> Sean
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Wei Chuang <[email-masked]>
Date: Fri, 17 Jun 2016 11:35:35 -0700

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

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

> 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

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

---

From: Sean Leonard <[email-masked]>
Date: Sat, 18 Jun 2016 07:13:09 -0700

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

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

---

From: Wei Chuang <[email-masked]>
Date: Sun, 19 Jun 2016 02:59:35 -0700

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

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

> Section 7.2 of RFC 5280 only applies to dNSName field; it does not apply

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

> 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.
>
> (because it can contain NULLs), and the domain with stricmp. No hunting for
> quotations or "@" needed.
>
> 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
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jun 2016 13:00:36 -0400

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

I think we need to consider internationalized domain names in this work.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jun 2016 13:10:01 -0400

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

Sorry, I hit send before I intend.  Trying again…

I think we need to consider internationalized domain names in this work.  Section 7.2 of RFC 5280 covers this topic.  Notice that it requires conversion to Unicode for display, but they are always carried in their ASCII form.

The approach that Sean recommends allows the domain name to be handled as already specified in RFC 5280, and this allows the group to focus on the left hand side of the @ sign.

I observe that this is not the for that the eaiName will appear in email messages.  We need to be able to compare them in the certificate and the email headers.  So, I’d like to hear from implementors what is the best form for their code.

Russ

---

From: Wei Chuang <[email-masked]>
Date: Wed, 22 Jun 2016 07:26:12 -0700

On Mon, Jun 20, 2016 at 10:10 AM, Russ Housley <[email-masked]> wrote:

> Section 7.2 of RFC 5280 covers this topic.  Notice that it requires
> conversion to Unicode for display, but they are always carried in their
> ASCII form.
>
> The approach that Sean recommends allows the domain name to be handled as
> already specified in RFC 5280, and this allows the group to focus on the
> left hand side of the @ sign.
>
> I observe that this is not the for that the eaiName will appear in email
> messages.  We need to be able to compare them in the certificate and the
> email headers.  So, I’d like to hear from implementors what is the best
> form for their code.
>

I checked with the Gmail delivery folks, and while the delivery system both
supports receiving A and U label domains and can sends both forms depending
on circumstances, they would prefer future standardization around U-labels
domain in the certificate as that's where the perceive e-mail formatting is
going.

I can rewrite the draft to cover this, but want to make sure the folks are
okay with this.  Also if this is the case, then presumably eaiName should
remain as a UTF8String i.e. not need the sequence.  But I also wanted to
check what folks thought too.

-Wei