Subject: Re: [Spasm] Spasm Digest, Vol 13, Issue 21

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Apr 2017 15:27:03 -0400

> On Apr 26, 2017, at 3:00 PM, [email-masked] wrote:
> 
>> Well, but not right, because the text seems to imply that
>> with an ASCII localpart and a UTF-8 domain the email address
>> SAN is to be presented as an rfc822Name, but that would require
>> conversion from U-labels to A-labels.  Is that the intent?  I
>> recall that earlier discussion suggested a desire to normalize
>> to U-labels…
> 
> The conclusion for the discussion in Chicago was to do just that.

I understood the discussion in Chicago to be just about how to store
name constraints.  And agree that the outcome for that was to store
them in rfc822Name form, converting any DNS U-labels to A-labels.

However, though I don't object, I don't recall any discussion of whether
SANs are also to be stored in that form whenever the localpart allows.

If that's the decision, perhaps it should be confirmed on the list and
made much more clear in the document.  In particular the document should
explain that with addresses such as:

	[email-masked]

the email SAN in the certificate becomes:

	[email-masked]

and that when comparing a presented identifier (RFC6125) from the
certificate with a reference identifier (RFC6125) an IDNA-aware
relying party MUST do so in a manner that is equivalent to:

  0.  Optional mapping of just the reference identifier to a suitable normal form
  1.  Converting any A-labels in both to the corresponding U-label form.
  2.  Converting any NR-LDH labels in both to lower-case.
  3.  Comparing the resulting strings byte for byte.

If that's the rough consensus view, and I happened to doze off during
the discussion that got us there, then I'm for it.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Apr 2017 15:32:47 -0500

> 	[email-masked]

I would expect this to be the case simply because the domainname part of
an email address stored in a non-Unicode capable field is an
IDNA-unaware domainname slot and can only carry A-labels.

As for the local parts, that's another story, as you note.

>   3.  Comparing the resulting strings byte for byte.

Does that have UTS#46 issues?

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Apr 2017 16:49:05 -0400

Viktor:

I believe that the "Name Constraints on Email Addresses” thread that was started on April 2nd was for just that purpose.  The first paragraph includes:

> the constraints against the rfc822Name apply to the SmtpUTF8Name by mapping any A-Labels that appear in the constraint to U-Labels.

Russ

> On Apr 26, 2017, at 3:27 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Apr 2017 18:00:12 -0500

On Wed, Apr 26, 2017 at 04:49:05PM -0400, Russ Housley wrote:
> Viktor:
> 
> I believe that the "Name Constraints on Email Addresses” thread that
> was started on April 2nd was for just that purpose.  The first
> paragraph includes:

Viktor appears to be asking about the SANs, not name constraints.

> > the constraints against the rfc822Name apply to the SmtpUTF8Name by
> > mapping any A-Labels that appear in the constraint to U-Labels.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Apr 2017 23:05:31 -0400

> On Apr 26, 2017, at 7:00 PM, Nico Williams <[email-masked]> wrote:
> 

Yes, and the message talked about what was stored in the SmtpUTF8Name that needed to be covered from U-Labels to A-Labels to check he constraints.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Apr 2017 08:38:45 -0400

Viktor has suggested that we consider the pros and cons of two ways of encoding the SubjectAltName when the left-hand side contains non-ASCII characters.

Option 1 is the way described in the current draft, where IDNs are carried as U-Labels.  Victor gave this example, even though the left-hand-side is all ASCII:

	[email-masked] <mailto:[email-masked]>

With Option 1, U-Labels need to be converted to A-Labels when a name constraints extension is present that constrains the rfc822Name.  However, no conversion is needed to compare the SmtpUTF8Name to the email address that appears in the FROM field of a message.  Also, no conversion is needed for display of the SmtpUTF8Name in a user interface.

Option 2 is the way described in Viktor’s message, where IDNs are carried as A-Labels.  Victor gave this example, even though the left-hand-side is all ASCII:

With Option 2, U-Labels need to be converted to A-Labels no conversion is needed when a name constraints extension is present that constrains the rfc822Name.  However, A-Labels need to be converted to U-Labels to compare the SmtpUTF8Name to the email address that appears in the FROM field of a message.  Also, A-Labels need to be converted to U-Labels for display of the SmtpUTF8Name in a user interface.

From my perspective, doing conversion only to enforce name constraints is the more desirable of the two.  What do others think?

Russ

---

From: Wei Chuang <[email-masked]>
Date: Thu, 27 Apr 2017 11:13:49 -0700

On Thu, Apr 27, 2017 at 5:38 AM, Russ Housley <[email-masked]> wrote:

> Viktor has suggested that we consider the pros and cons of two ways of
> encoding the SubjectAltName when the left-hand side contains non-ASCII
> characters.
>
> Option 1 is the way described in the current draft, where IDNs are carried
> as U-Labels.  Victor gave this example, even though the left-hand-side is
> all ASCII:
>
> [email-masked] <[email-masked]>
>
> With Option 1, U-Labels need to be converted to A-Labels when a name
> constraints extension is present that constrains the rfc822Name.  However,
> no conversion is needed to compare the SmtpUTF8Name to the email address
> that appears in the FROM field of a message.  Also, no conversion is needed
> for display of the SmtpUTF8Name in a user interface.
>
> Option 2 is the way described in Viktor’s message, where IDNs are carried
> as A-Labels.  Victor gave this example, even though the left-hand-side is
> all ASCII:
>
> With Option 2, U-Labels need to be converted to A-Labels no conversion is
> needed when a name constraints extension is present that constrains the
> rfc822Name.  However, A-Labels need to be converted to U-Labels to compare
> the SmtpUTF8Name to the email address that appears in the FROM field of a
> message.  Also, A-Labels need to be converted to U-Labels for display of
> the SmtpUTF8Name in a user interface.
>
> From my perspective, doing conversion only to enforce name constraints is
> the more desirable of the two.  What do others think?
>

Option 1 would be my preference.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Apr 2017 19:10:06 +0000

> encoding the SubjectAltName when the left-hand side contains non-ASCII

To be clear, the issue is how to store the email identity (not name
constraints, but the email-valued subjectAltName) in the certificate
when the localpart (left-hand side if you like) DOES NOT contain
non-ASCII characters.  Or, to doubly make sure we're on the same
page, and avoid a double-negative, when the localpart contains ONLY
7-bit ASCII characters.

Had the localpart contained non-ASCII UTF-8, as with:

    [email-masked]

there would be no choice but to store the presented identifier in
the certificate as an SMTPUtf8Name subjectAltName element.

> as U-Labels.  

Well, the "current" draft, Section 3, bottom of page 3, says the
opposite:

   Due to operational reasons described shortly and name constraint
   compatibility reasons described in its section, SmtpUTF8Name
   subjectAltName MUST only be used when the local part of the email
   address contains UTF-8.  When the local-part is ASCII, rfc822Name
   subjectAltName MUST be used instead of SmtpUTF8Name.  The use of
   rfc822Name rather than SmtpUTF8Name is currently more likely to be
   supported.  Also use of SmtpUTF8Name incurs higher byte
   representation overhead due to encoding with otherName and the
   additional OID needed.  This may be offset if domain requires non-
   ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name
   supports A-label.

[ The comment about encoding overhead makes no clear case in either
  direction, is irrelevant, mand should be deleted ]

The draft seems to suggest that email addresses with ASCII localparts
should be converted to A-label form, but fails to then explain all
the associated steps needed to be performed by CAs and relying
parties.

> Victor gave this example:
> all ASCII:
> 
> 	[email-masked]
> 
> constraints extension is present that constrains the rfc822Name.

In Chicago, IIRC the consensus was to convert the A-labels in
rfc822Name name constraints to U-label form for comparison against
the non-converted email address.  Not conversion of the address to
A-labels for comparison with rfc822Name constraints.  Of course
the two implementation strategies can be functionally equivalent
(absent "mappings" in the U->A direction).

> Option 2 is the way described in Viktor�s message, where IDNs are carried
> as A-Labels.  

And the in the *current* draft, not described in sufficient detail.

> Victor gave this example, even though the left-hand-side is all ASCII:

	s/even though/precisely when/

> rfc822Name.  

Indeed the domains in the SAN and the rfc822Name constraint can
just be compared in a case-insensitive manner.

> However, A-Labels need to be converted to U-Labels to compare
> the SmtpUTF8Name to the email address that appears in the FROM field of
> a message.

Right, and possibly the domain in the RFC2822.From header may need
mappings to be normalized to a valid UTF-8 domain.  This is up to
the application.

> the more desirable of the two.  What do others think?

I am slightly in favour of storing A-labels in an rfc822Name SAN
whenever the localpart (when all ASCII) permits.  This is more
consistent with how IDNA domains already appear in DNS-ID, and
is more likely to interoperate in mixed-mode use-case when a
sender has both user@<utf-8-fqdn> and user@<a-label-fqdn>
email addresses routed to the same mailbox, and uses the a-label
form as needed.

That said, pick one or the other, but just be clear about which,
and describe the consequences in the draft in more detail.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Apr 2017 14:11:53 -0500

On Thu, Apr 27, 2017 at 08:38:45AM -0400, Russ Housley wrote:
> Option 1 is the way described in the current draft, where IDNs are
> carried as U-Labels.  Victor gave this example, even though the
> left-hand-side is all ASCII:
> 
> [...]
> 
> Option 2 is the way described in Viktor’s message, where IDNs are
> carried as A-Labels.  Victor gave this example, even though the
> left-hand-side is all ASCII:
> 
> [...]
> From my perspective, doing conversion only to enforce name constraints
> is the more desirable of the two.  What do others think?

I somewhat prefer option 2 as it will increase interoperability with
running code that supports rfc822Name but not SmtpUTF8Name.

Option 3: Always include both, rfc822Name with A-labels and SmtpUTF8Name
with U-labels.

With option 3, newer running code would then ignore rfc822Name SANs and
check only SmtpUTF8Name SANs, while older running code would naturally
do the opposite.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Apr 2017 17:29:42 -0400

RFC 5280 already covers how to carry email address with IDNs on the right hand side and ASCII on the left hand side.  rfc822Name is used, and A-Labels are used on the right hand side.  RFC 5280 uses IDNA2003 terminology to say so,  We are not considering a change to that.

Russ

> On Apr 27, 2017, at 3:10 PM, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Apr 2017 17:32:41 -0400

> On Apr 27, 2017, at 3:11 PM, Nico Williams <[email-masked]> wrote:
> 

Putting data that is supposed to be “the same” in two different formats in the certificate leads to failure cases where the relying party does not agree that they are actually the same.  I’d like to avoid the possibility of such consistency concerns.

Russ

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Apr 2017 16:40:17 -0500

On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote:
> Putting data that is supposed to be “the same” in two different
> formats in the certificate leads to failure cases where the relying
> party does not agree that they are actually the same.  I’d like to
> avoid the possibility of such consistency concerns.

Multiple SANs aren't supposed nor required to be different
representations of the same notional name.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Apr 2017 17:42:27 -0400

> On Apr 27, 2017, at 5:40 PM, Nico Williams <[email-masked]> wrote:
> 

But, that is what you are offering as option 3 whenever there is an IDN in use, carry it in both U-Label and A-Label form.

Russ

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Apr 2017 17:25:35 -0500

On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote:
> But, that is what you are offering as option 3 whenever there is an
> IDN in use, carry it in both U-Label and A-Label form.

I don't understand your concern.

Is it not the case that I could have a cert with multiple SANs of any
one type?  Of course I could.  If I was sending email as
<[email-masked]> and presented to an MSA a certificate that has an
rfc822Name SAN for <[email-masked]> and also an rfc822Name SAN for
<[email-masked]> then why should the MSA complain that one of those
SANs does not match?!  Of course it should not.

Now if I try to send email as <[email-masked]> and present a
certificate with a <[email-masked]> rfc822Name SAN and a
<[email-masked]> smtpUTF8Name SAN, it should be the same story.

Option 3 has the advantage that the relying party has to do no
conversions to find a matching SAN provided the referrent name is
already canonical, whether using A-labels or U-labels (but not a mix,
natch).  But more than that, it means that for ASCII local-parts the CA
doesn't have to know that some MSA for that domain still doesn't handle
smtpUTF8Name, and if that happens to be the case this cert will work.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Apr 2017 20:19:47 -0400

> On Apr 27, 2017, at 6:25 PM, Nico Williams <[email-masked]> wrote:
> 

I have a problem with you saying that the common practice for an email address that includes an IDN is to put both the A-Lable for and the U-Label for in the certificate.  This leads to more checks than are needed to make sure that both conform to the name constraints, and  it might lead to other surprises because some relying parties use on form while other relying parties use the other.  I’m just arguing for the normal practice to be the use of one of the encodings, not both.

Russ

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Apr 2017 20:24:27 -0500

On Thu, Apr 27, 2017 at 08:19:47PM -0400, Russ Housley wrote:
> I have a problem with you saying that the common practice for an email
> address that includes an IDN is to put both the A-Lable for and the
> U-Label for in the certificate.  This leads to more checks than are
> needed to make sure that both conform to the name constraints, [...]

Not so.  You ignored everything I wrote above.  Could you demonstrate
specifically how having both would cause a failure.

Nico
--

---

From: Wei Chuang <[email-masked]>
Date: Fri, 28 Apr 2017 06:57:17 -0700

On Thu, Apr 27, 2017 at 5:19 PM, Russ Housley <[email-masked]> wrote:

> address that includes an IDN is to put both the A-Lable for and the U-Label
> for in the certificate.  This leads to more checks than are needed to make
> sure that both conform to the name constraints, and  it might lead to other
> surprises because some relying parties use on form while other relying
> parties use the other.  I’m just arguing for the normal practice to be the
> use of one of the encodings, not both.
>

+1

Option 3, while agreed it has some nice properties, causes a lot more
complexity and creates a lot more room for implementation and operational
errors.  You can see that complexity in the earlier draft -08 in the
example section where we tried to enumerate most of the cases:
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08
It called for special casing name constraints for backwards compatibility
by the SmtpUTF8Name aware issuer.  That draft also called for SmtpUTF8Name
aware path verifiers to help "police" those name constraint.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Apr 2017 16:59:14 +0000

> aware path verifiers to help "police" those name constraint.

Actually, no!  The complexity in draft 8 is entirely due to using
two types of *name constraints*.  There is no such complexity when
using both types of SANs.

Both types of SANs need to be supported anyway, so what "option 3"
does is make it possible to compare the reference identifier against
the SAN *without* conversions.  That is, the certificate is populated
with all the email identities that the sender intends to use, and the
relying party performs no conversions!  

When the reference identifier has no U-labels, and the localpart
is all ASCII, only rfc822Name SANs are checked (with domain parts
compared in a case-insensitive manner).

When the reference identifier has U-labels, or the localpart is
not all ASCII, only SMTPUtf8Name SANs checked (with U-labels in
the domain parts compared byte for byte and NR-LDH or A-labels in
a case-insensitive manner).

A sender who wants working certificate authentication should not
use addresses that don't appear verbatim (modulo case of NR-LDH or
A-labels of domains) in your certificate.  Or equivalently, a sender
should obtain a certificate with all the desired address forms.

Instead of placing the burden on all the verifiers, place it on
the party obtaining the certificate from the CA.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Apr 2017 17:21:59 -0500

> relying party performs no conversions!  

However, it doesn't do this.  The problem is that there may exist
certificates that have rfc822Name and not smtpUTF8Name that relying
parties should nonetheless support.

So I think option 3 is out because it adds no value even though it
should not cause any problems.

I believe only options 2 and 3 are acceptable, but option 3 is useless,
therefore only option 2 should be considered, and that's no option.

Nico
--