Subject: [Spasm] Name Constraints on Email Addresses

From: Russ Housley <[email-masked]>
Date: Sun, 2 Apr 2017 12:25:36 -0400

At the LAMPS WG session is Chicago, we discussed the concerns raised during IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion proposed a different way forward for constraints on email addresses.  The suggestion has two parts.  First, an update to RFC 5280, Section 4.2.1.10.  Second, have the constraints against the rfc822Name apply to the SmtpUTF8Name by mapping any A-Labels that paper in the constraint to U-Labels.  No SmtpUTF8Name constraints are ever needed.

RFC 5280, Section 4.2.1.10 offers three ways to constrain email addresses, but no one in the room doing the LAMPS session was aware of any use of the constraint applying to a particular mailbox.  The idea is to remove that capability going forward, which allows the rfc822Name constraint to apply to both rfc822Name and SmtpUTF8Name.

OLD:

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "[email-masked]" indicates the root mailbox on the host
   "example.com".  To indicate all Internet mail addresses on a
   particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com" is satisfied by any mail
   address at the host "example.com".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com" indicates all the Internet mail
   addresses in the domain "example.com", but not Internet mail
   addresses on the host "example.com”.

NEW:

   A name constraint for Internet mail addresses MAY specify all
   addresses at a particular host or all mailboxes in a domain.  To
   indicate all Internet mail addresses on a particular host, the
   constraint is specified as the host name.  For example, the constraint
   "example.com" is satisfied by any mail address at the host
   "example.com".  To specify any address within a domain, the constraint
   is specified with a leading period (as with URIs).  For example,
   ".example.com" indicates all the Internet mail addresses in the domain
   "example.com", but not Internet mail addresses on the host
   “example.com.

It was observed that the conversion of an A-Lable to a U-Label and back to an A-Label may not alway give the same string.  Perhaps we could say: Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint that result in the same result when converted to a U-Label and back again to an A-Label.

The represent a significant change in direction for this document.  Please speak promptly is you disagree with this new direction.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Apr 2017 00:12:30 +0000

On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote:

> At the LAMPS WG session is Chicago, we discussed the concerns raised during
> IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion proposed
> a different way forward for constraints on email addresses.  The suggestion
> has two parts.  First, an update to RFC 5280, Section 4.2.1.10.  Second,
> have the constraints against the rfc822Name apply to the SmtpUTF8Name by
> mapping any A-Labels that paper in the constraint to U-Labels.  No
> SmtpUTF8Name constraints are ever needed.

The proposed interpretation of rfc822Name constraints as SMTPUtf8Name
constraints will of course entail not only decoding A-labels from
to U-labels, but also an identity mapping on NR-LDH labels.

The proposed direction of the mapping (decoding constraints to
UTF-8, rather than encoding SMTPUtf8 subjectAltNames to A-labels)
is crucial and correct.  Decoding from punycode to UTF-8 is a very
mechanical process that does not involve any input normalization,
or differences in the rules beteen IDNA2003 and IDNA2008.

In particular, I think we can add a punycode *decoder* to OpenSSL,
without introducing any dependencies on external libraries.  Adding
an encoder would probably require libicu or similar, and would be
a significant burden.

Well, we could perhaps be able to continue to express mailbox
constraints for ASCII localparts, but it is hardly worth it.

> It was observed that the conversion of an A-Lable to a U-Label and back
> to an A-Label may not alway give the same string.  Perhaps we could say:
> Conforming CAs SHOULD only include A-Labels in the rfc822Name constraint
> that result in the same result when converted to a U-Label and back again
> to an A-Label.

It suffices for the domain names that will appear in SMTPUtf8Name
subjectAltName elements of the certificate to match the decoded
rfc822Name constraints.

The real complexity is in whatever mapping, if any, the application
has to do to construct a "canonical" reference identifier from the
sender address of the message.  The applications I use (at least
all the browsers and the Postfix MTA) perform the mappings from
UTS#46 (<http://unicode.org/reports/tr46/#Mapping>) thereby producing
the same A-label form for many case-variants of UTF-8 strings.
Thus, for example:

    $ posttls-finger -c -Lsummary духовный.org 
    posttls-finger: духовный.org asciified to xn--b1adqpd3ao5c.org
    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

    $ posttls-finger -c -Lsummary Духовный.org 
    posttls-finger: Духовный.org asciified to xn--b1adqpd3ao5c.org
    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

In OpenSSL I don't think that the library can reasonably be expected
to perform the UTS#46 mappings.  Instead, the application will be
responsible for applying any such mapping to hand the library an
email address whose domain part is already suitably mapped.

Would it be appropriate for the draft to align to real-world practice
and converge on UTS#46 mapping of U-labels?

> The represent a significant change in direction for this document.  Please
> speak promptly is you disagree with this new direction.

Looks good to me.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Tue, 4 Apr 2017 11:45:15 -0700

On Sun, Apr 2, 2017 at 5:12 PM, Viktor Dukhovni <[email-masked]>
wrote:

> <http://xn--b1adqpd3ao5c.org>
>     posttls-finger: духовный.org <http://xn--b1adqpd3ao5c.org> asciified
> to xn--b1adqpd3ao5c.org
>     posttls-finger: Verified TLS connection established to smtp.imrryr.org
> [108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
> (256/256 bits)
>
>     posttls-finger: Verified TLS connection established to smtp.imrryr.org
> [108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
> (256/256 bits)
>
Currently the document says to use IDNA2008 only to insure that U-label and
A-label convert 1-1, and to explicitly forbids UTF-8 case folding to
eliminate ambiguity that it may cause.  If we were to specify UTS#46 that
would bring in (at least) two different processing modes: 1) re-introduce
case folding and 2) transitional processing for IDNA2003 to IDNA2008 that
is supposed to go away at some point.  Both introduce uncertainty to the
specification.  Also in practice I understand that UTS#46 may be used in
the application (e.g. display of email address), but does it have to be
part of the normative specification?

-Wei

---

From: Russ Housley <[email-masked]>
Date: Wed, 5 Apr 2017 12:53:50 -0400

> On Apr 2, 2017, at 8:12 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Yes, indeed.

> constraints for ASCII localparts, but it is hardly worth it.

At the meeting, no one knew of anyone using a mailbox constraint, and eliminating that case really does make things much simpler.

> and converge on UTS#46 mapping of U-labels?

I think that John Klensin strongly suggested alignment with IDNA2008.  I do not think John is on this list, so I will try to channel his comment.  The UTS#46 mapping results in more cases where A-Label —> U-Label —> A-Label translations do not return the string that one started with.

>> speak promptly is you disagree with this new direction.

Thanks.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 5 Apr 2017 12:56:45 -0400

> On Apr 4, 2017, at 2:45 PM, Wei Chuang <[email-masked]> wrote:
> 
> 
> 
> On Sun, Apr 2, 2017 at 5:12 PM, Viktor Dukhovni <[email-masked] <mailto:[email-masked]>> wrote:
> UTS#46 (<http://unicode.org/reports/tr46/#Mapping <http://unicode.org/reports/tr46/#Mapping>>) thereby producing
>     $ posttls-finger -c -Lsummary духовный.org <http://xn--b1adqpd3ao5c.org/>
>     posttls-finger: духовный.org <http://xn--b1adqpd3ao5c.org/> asciified to xn--b1adqpd3ao5c.org <http://xn--b1adqpd3ao5c.org/>
>     posttls-finger: Verified TLS connection established to smtp.imrryr.org <http://smtp.imrryr.org/>[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
>     posttls-finger: Духовный.org asciified to xn--b1adqpd3ao5c.org <http://xn--b1adqpd3ao5c.org/>
>     posttls-finger: Verified TLS connection established to smtp.imrryr.org <http://smtp.imrryr.org/>[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> Currently the document says to use IDNA2008 only to insure that U-label and A-label convert 1-1, and to explicitly forbids UTF-8 case folding to eliminate ambiguity that it may cause.  If we were to specify UTS#46 that would bring in (at least) two different processing modes: 1) re-introduce case folding and 2) transitional processing for IDNA2003 to IDNA2008 that is supposed to go away at some point.  Both introduce uncertainty to the specification.  Also in practice I understand that UTS#46 may be used in the application (e.g. display of email address), but does it have to be part of the normative specification?

I would prefer to keep the 1-1 conversion requirement.  That seems to allow the rfc822Name constraints to easily apply to both the rfc822Name and the SmtpUTF8Name.

Russ

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Apr 2017 16:49:58 -0500

On Wed, Apr 05, 2017 at 12:53:50PM -0400, Russ Housley wrote:
> I think that John Klensin strongly suggested alignment with IDNA2008.
> I do not think John is on this list, so I will try to channel his
> comment.  The UTS#46 mapping results in more cases where A-Label ->
> U-Label -> A-Label translations do not return the string that one
> started with.

The issue, the reason for UTS#46, is that what you get in IDNA2008 w/o
UTS#46 depends entirely on the user's choice of case.  That makes for a
*terrible* UX.

That applying UTS#46 doesn't round-trip is neither here nor there, as,
after all, what use is it to round-trip if what you get depends on the
user's mood anyways?  Better do something that works and does not
round-trip than something that doesn't work but does round-trip.

Also, as to PKIX constraints, they absolutely do not need to round-trip
since they are only to be evaluated, therefore the round-trip concern is
simply irrelevant.

As an aside, I'm very much in favor of updating IDNA2008 to REQUIRE the
application of UTS#46.  It really, really cannot be the case that
whether some DNS query (or downstream protocol operation) works or not
depends on the user's choice of capitalization.  I understand that
there's no appetite for this, but if all the browsers, and MTAs, and...
do it... I mean, really!  Are we not about running code?!  Again, the
non-round-trip objection is a non-issue.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Apr 2017 10:35:31 -0400

No one has spoken against this direction for constraints on email addresses (both rfc822Name and SmtpUTF8Name).  Authors, please update the document accordingly.

Russ

> On Apr 2, 2017, at 12:25 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Apr 2017 12:57:51 -0500

> No one has spoken against this direction for constraints on email addresses (both rfc822Name and SmtpUTF8Name).  Authors, please update the document accordingly.

I spoke against the round-tripping concern w.r.t. application of UTS#46.
Was that missed?

> > [...]

I disagree.  Apply UTS#46.  The lack of round-tripping is a non-issue.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Apr 2017 17:29:39 -0400

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

Your comments were not missed.  The core idea in the proposal was not tied to UTS#46.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Apr 2017 19:49:59 +0000

> Your comments were not missed.  The core idea in the proposal was not tied to UTS#46.

Yes, indeed the core change is not affected by the fine points of
Unicode normalization.  Glad to see we've reached a reasonably
practical consensus.

That said, I would like to see further discussion of the suggestion
to recommend non-transitional UTS#46, Nico and I are on the same
page there.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Fri, 14 Apr 2017 12:45:58 -0700

We have a new draft nearly ready.  Two question remains with respect to
backwards compatibility

1) Should use of SmtpUTF8Name subject be restricted to only when the email
address local part contains local part contains UTF-8 with a MUST or SHOULD?
MUST- provides stronger guarantees in the backwards compatibility with
legacy path verifiers
SHOULD- allows some future issuers to use SmtpUTF8Name subject with ASCII
local part email addresses once legacy verifiers are no longer a concern.

2) Should name constraints always use the rfc822Name form with MUST or
SHOULD?
MUST- provides stronger guarantees for backwards compatibility with legacy
path verifiers
SHOULD- allows for future implementation to use SmtpUTF8Name name
constraints once CAs need not worry about legacy verifiers.

thanks,
-Wei

On Sun, Apr 2, 2017 at 9:25 AM, Russ Housley <[email-masked]> wrote:

> At the LAMPS WG session is Chicago, we discussed the concerns raised
> during IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion
> proposed a different way forward for constraints on email addresses.  The
> suggestion has two parts.  First, an update to RFC 5280, Section 4.2.1.10.
> Second, have the constraints against the rfc822Name apply to the
> SmtpUTF8Name by mapping any A-Labels that paper in the constraint to
> U-Labels.  No SmtpUTF8Name constraints are ever needed.
>
> RFC 5280, Section 4.2.1.10 offers three ways to constrain email addresses,
> but no one in the room doing the LAMPS session was aware of any use of the
> constraint applying to a particular mailbox.  The idea is to remove that
> capability going forward, which allows the rfc822Name constraint to apply
> to both rfc822Name and SmtpUTF8Name.
>
> OLD:
>
> It was observed that the conversion of an A-Lable to a U-Label and back to
> an A-Label may not alway give the same string.  Perhaps we could say:
> Conforming CAs SHOULD only include A-Lables in the rfc822Name constraint
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 14 Apr 2017 13:52:20 -0700

See inline.

From: Spasm [mailto:[email-masked]] On Behalf Of Wei Chuang
Sent: Friday, April 14, 2017 12:46 PM
To: Russ Housley <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [Spasm] Name Constraints on Email Addresses

We have a new draft nearly ready.  Two question remains with respect to backwards compatibility

1) Should use of SmtpUTF8Name subject be restricted to only when the email address local part contains local part contains UTF-8 with a MUST or SHOULD?

MUST- provides stronger guarantees in the backwards compatibility with legacy path verifiers

SHOULD- allows some future issuers to use SmtpUTF8Name subject with ASCII local part email addresses once legacy verifiers are no longer a concern.

[JLS] This should be a MUST – you are never going to know when the backwards compatibility problems are going to go away.

2) Should name constraints always use the rfc822Name form with MUST or SHOULD?

MUST- provides stronger guarantees for backwards compatibility with legacy path verifiers

SHOULD- allows for future implementation to use SmtpUTF8Name name constraints once CAs need not worry about legacy verifiers. 

[JLS] I thought that the SmtpUTF8Name constraint option was history and disappeared from the document and processing entirely.  SmptUTF8Name form only uses the RFC822Name constraint option when doing constraints.

Jim

thanks,

-Wei

On Sun, Apr 2, 2017 at 9:25 AM, Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

OLD:

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "[email-masked] <mailto:[email-masked]> " indicates the root mailbox on the host
   "example.com <http://example.com> ".  To indicate all Internet mail addresses on a
   particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com <http://example.com> " is satisfied by any mail
   address at the host "example.com <http://example.com> ".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com <http://example.com> " indicates all the Internet mail
   addresses in the domain "example.com <http://example.com> ", but not Internet mail
   addresses on the host "example.com <http://example.com> ”.

NEW:

   A name constraint for Internet mail addresses MAY specify all
   addresses at a particular host or all mailboxes in a domain.  To
   indicate all Internet mail addresses on a particular host, the
   constraint is specified as the host name.  For example, the constraint
   "example.com <http://example.com> " is satisfied by any mail address at the host
   "example.com <http://example.com> ".  To specify any address within a domain, the constraint
   is specified with a leading period (as with URIs).  For example,
   ".example.com <http://example.com> " indicates all the Internet mail addresses in the domain
   "example.com <http://example.com> ", but not Internet mail addresses on the host
   “example.com <http://example.com> .

Russ

_______________________________________________
Spasm mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Apr 2017 17:03:34 -0400

> On Apr 14, 2017, at 3:45 PM, Wei Chuang <[email-masked]> wrote:
> 

Since IDNs can be represented in rfc822Name, it makes sense to me that SmtpUTF8Name only be used when the left hand side contains at lease one non-ASCII character.  I suggest a MUST, unless you can think of an exception.

> SHOULD- allows for future implementation to use SmtpUTF8Name name constraints once CAs need not worry about legacy verifiers. 

I think the constrains should always appear in rfc822Name and never appear in SmtpUTF8Name.

Do others have a different view?  If so, please speak up now.

Russ

---

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

On Fri, Apr 14, 2017 at 01:52:20PM -0700, Jim Schaad wrote:

> > 1) Should use of SmtpUTF8Name subject be restricted to only when the
> > email address local part contains UTF-8 with a MUST or SHOULD?
> > 
> > MUST - provides stronger guarantees in the backwards compatibility with
> > legacy path verifiers
> >
> > SHOULD - allows some future issuers to use SmtpUTF8Name subject with
> > ASCII local part email addresses once legacy verifiers are no longer a
> > concern.
> 
> This should be a MUST you are never going to know when the backwards
> compatibility problems are going to go away.

I don't see any security risk in use of a SMTPUtf8Name to represent
an all-ASCII subjectAltName.  Legacy verifiers may decide the
certificate does not match, because they did not know to look for
SMTPUtf8Names, but so the issuer SHOULD use rfc822Name whenever
possible, but what would make this a MUST?

> I thought that the SmtpUTF8Name constraint option was history and
> disappeared from the document and processing entirely.  SmptUTF8Name form
> only uses the RFC822Name constraint option when doing constraints.

Indeed, we've just decided to entirely do away with SMTPUtf8Name
constraints, and always use only rfc822Name constraints.  So the
question is moot.

-- 
	Viktor.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 14 Apr 2017 15:33:55 -0700

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Friday, April 14, 2017 2:17 PM
To: 'SPASM' <[email-masked]>
Subject: Re: [Spasm] Name Constraints on Email Addresses

On Fri, Apr 14, 2017 at 01:52:20PM -0700, Jim Schaad wrote:

> > MUST - provides stronger guarantees in the backwards compatibility 
> > with legacy path verifiers
> >
> > ASCII local part email addresses once legacy verifiers are no longer 
> > a concern.
> 

I don't see any security risk in use of a SMTPUtf8Name to represent an
all-ASCII subjectAltName.  Legacy verifiers may decide the certificate does
not match, because they did not know to look for SMTPUtf8Names, but so the
issuer SHOULD use rfc822Name whenever possible, but what would make this a
MUST?

[JLS] My main reason for not wanting to do this is to avoid the issue of
needing/wanting to put in both.  If we have the MUST, then this is no longer
an issue.  I agree that if we allow for this to occur, there will not be a
strong security issue because the name form would not normally be seen.

Jim

> disappeared from the document and processing entirely.  SmptUTF8Name 
> form only uses the RFC822Name constraint option when doing constraints.

Indeed, we've just decided to entirely do away with SMTPUtf8Name
constraints, and always use only rfc822Name constraints.  So the question is
moot.

-- 
	Viktor.