Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Feb 2017 21:01:56 +0000

On Tue, Jan 24, 2017 at 07:31:09PM -0000, John Levine wrote:

> >My impression is that there is little problem with the intended
> >underlying spec, but the document text needs some tuning.
> 
> Agreed.  The subsequent section on comparing names would likely
> benefit from clearer instructions, e.g.
> 
> a) if the domain contains A-labels, turn them into U-labels
> b) if the domain still contains R-LDH labels, stop, not a valid name.
> c) if the domain contains NR-LDH labels, make them all the same case
> d) do a straight byte comparison of the addresses

I think that restricting R-LDH labels that are not A-labels is too
strict, see for example Phil Hallam-Baker's proposed encapsulation
of email addresses with "the mesh" (attached).

  TL;DR: [email-masked]

The "mm" R-LDH namespace (if/when implemented) or some other future
namespace should probably not be excluded at this time.

If the intent is to canonicalize A-labels to U-labels, then perhaps
only "xn--" labels should be proscribed, if any.

On the other hand, I see there is some support for allowing
certificates to contain whatever form is actually used in email
headers, and perhaps more than just one such form.  If so, there
is no need to proscribe any names at all.  The client performs no
conversions, and the certificate would need to be inclusive of any
addresses that are in actual use.

-- 
	Viktor.

Subject: How to make the Internet secure
From: Phillip Hallam-Baker <[email-masked]>
To: IETF Discussion Mailing List <[email-masked]>
Date: Wed, 1 Feb 2017 12:52:56 -0500
List-Id: IETF-Discussion <ietf.ietf.org>

One of the big problems I have found in trying to argue for ways we can
improve Internet security is that there are two camps. The incrementalists
will only look at solutions that provide an improvement on the status qujo
in one area and the perfectionists insist that any solution that does not
solve every possible problem isn't worth considering.

How about we do both?

Also to save time:

* Yes, I understand the deployment problem very well, I worked with the guy
who solved the network hypertext deployment problem after 20 years of
people failing.
* Yes, everything is end to end secure,
* Yes the transport is also secure to prevent metadata attacks.
* Yes it works with OpenPGP
* Yes it works with S/MIME
* Yes you can use it with SMTP/IMAP/POP
* Yes you can use it with Jabber
* No, you do not have to use a CA
* Yes, you may use a CA where a CA adds value
* Yes, I have considered the lock in problem
* Yes, you can bolt in your own trust model
* REST/HTTPS/JSON.
* AES/RSA/DiffieHelman, moving to CurveX for production.
* Yes it is unencumbered, apart from one part which will unlock this year.
* Yes I have a strategy for QRC
* No, it is not a walled garden
* Yes, you can adapt the system to use escrow cryptography but not without
the parties knowing so this is a frontdoor, not a backdoor.
* My employer sells endpoint protection systems, the Mesh is not a
substitute for endpoint protection, thank you for your interest.
* Reference code runs on Windows, Linux and should run on OSX. It is all
MIT license, so are the protocol compiler tools.

* Yes, it is easy to use. In fact it is exactly as easy to use as the
existing protocols because the user doesn't need to know that they are
doing security
* Yes it is easy to configure.
* Yes, I need help, a lot of help

OK so how is this possible?

First observation is that we now have several protocols that provide users
with end to end security that are really easy to use. The only real problem
I have with those systems is that they operate inside walled gardens. They
are not going to be a replacement for email.

Second is that public key cryptography is now cheap in terms of both cost
and performance. We couldn't do very interesting crypto in the 90s because
machines bogged

There are three contributions made by the Mathematical Mesh:

1) An infrastructure for managing and using client keypairs.

Adding cryptography to a protocol is actually quite easy when both parties
have public keypairs. So if we have an infrastructure that allows a user to
'glue' all their devices together into a personal mesh such that they all
have keypairs provisioned for each cryptographic purpose they might need
them for, cryptography becomes really easy for the user.

2) Extend a direct trust model into the DNS

We all know about TOR and onion routing. Well what if I could have an email
address that included my OpenPGP fingerprint? Well we can. Just use the
xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
and we can make the fingerprint the TLD:

[email-masked]

This means, 'only send mail to this address in compliance with a policy
signed under the fingerprint MBTVK...' Said policy could be an OpenPGP key
or it could be a Mesh mail profile.

3) Use of Proxy Re-Encryption (Recryption)

HTTPS provides end to end encryption between the user's client and the web
site serving the content. Using Proxy Re-Encryption we can provide end to
end encryption between the content creator and the user's client. This is
the part of the system that will be locked until late this year, (not that
I am sure the patent is valid, why bother checking when it expires)

We all know that two key cryptography is better than one. It is better
because encryption and decryption are different functions and using
separate keys for separate functions allows these to be done by different
parties. Recryption is three key cryptography and it is better than two key
for the same exact reason.

Using recryption allows us to develop protocols in which Alice is able to
publish a single encryption key but read her email on three different
devices, each of which has a separate decryption key so that she can
mitigate the risk if one of the devices is lost.

Job one is making it easy to manage client side keys.

Once we have that infrastructure, all else becomes straightforward. My
original goal with the Mesh was to make it easy to configure S/MIME and
OpenPGP. David Clark asked me to add SSH which I immediately realized could
be the killer app because the big problem with configuring SSH is that if
you do it to a machine at a remote site, 1000 miles away and you screw up,
someone has to get on a plane to fix it.

However, any infrastructure that allows mail application to say 'here are
the encryption keys to use to send mail to me and when to use them' can
also say 'I accept JSON format nextgen mail'. So this is an infrastructure
that allows us to lock down the legacy email systems as best as can be
managed but also eliminates the biggest barrier to deployment of a
successor system.

I am looking for help to make this happen.

http://prismproof.org/

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Feb 2017 11:07:33 -0500

Victor, Wei Chuang, and IESG,

The more this discussion goes on, the more I become convinced
that this document should make an explicit reference to the IDNA
2008 and SMTPUTF8 documents, say that strings in certificates
MUST conform to whatever is allowed there and then, other than
making a statement about preference for U-labels over A-labels
(or vice versa), say as little as possible.  The problem is that
use of forms that might have coded meanings without knowing what
those meanings are is an opportunity for mischief, something
that should be of special concern for a piece of work that is
security-specific.   

I note that "prohibit everything that has a prefix consisting of
two ASCII letters followed by '--' unless the letter sequence is
specifically allowed" has been discussed at length and then
agreed on in at least three WGs specialized about the
identifiers, not just their embeddings (original IDN, IDNbis,
and PRECIS).  Even if there were a growing consensus that a
different rule would be more appropriate (and, AFAICT, there
definitely is not), it would be a bad idea for LAMPS or other
certificate-related work to get ahead of that consensus and
specify something inconsistent with the identifier standards
themselves.

Phill's proposal, independent of its merits, is almost
irrelevant to the question.  From the standpoint of the present
work, it is one of many proposals to do interesting things with
the DNS by using ACE-style (or trick-prefix) labels.  If the
community concludes that it is a good idea and has a plausible
chance of global deployment, the DNS/IDNA and SMTP (or SMTPUTF8)
specs will need to be modified to allow the prefix.  The LAMPS
"eai" spec should be written so that, if those specifications
are modified, whatever they allow should be allowed in certs,
but should, again, not be allowed to get ahead.   If that means
we are now in need of an IANA registry of such prefixes (with
exactly one initial entry plus maybe one long-deprecated one),
that ought to be easy to do.

As to "put all the alternate forms in the cert", we've been
there too and it hasn't ended happily.  Fully-qualified DNS
names are part of a hierarchy.   Transcoding between A-labels
and U-labels is an algorithmic matter, not a hierarchy of
choices but, if there are even two choices for the form of a
label at each of several different levels of the hierarchy, one
rapidly gets to a combinatorial explosion.  I trust everyone
here can do the arithmetic.  If listing all of the possible
variations on an FQDN in the certificate is the solution, then
the WG -- on behalf of those who issue, certify, validate, and
check certificates -- needs to be prepared for certs with
dozens, sometimes hundreds, of names in them, not just the
examples that have been floated with perhaps two or three.  

Remembering that, if, as Porky Pig, I can get a cert issued to
me with Mickey Mouse as an alternate name that is treated as a
synonym for all purposes, much of the value of certification is
lost and, IMO, we are all in big trouble.   If the WG wants to
encourage alternate name behavior, I think it is imperative that:

	(i) The document contain explicit instructions to
	certificate issuers and CAs about what should be checked
	and to client systems about what should be
	believed/trusted and under what circumstances.
	
	(ii) Certificate provisions to specify certification
	levels and exactly what is being certified need to be
	reexamined and probably expanded to identify trust
	levels and accountability around alternate names.
	
	(iii) The "Security Considerations" section of the I-D
	should be expanded to explicitly discuss these cases and
	the risks.

The document should not be approved until that work is complete
and reaches consensus.

   best,
      john

--On Wednesday, February 1, 2017 21:01 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> > My impression is that there is little problem with the
>> > intended underlying spec, but the document text needs some
>> > tuning.
>> 
>> Agreed.  The subsequent section on comparing names would
>> likely benefit from clearer instructions, e.g.
>> 
>> b) if the domain still contains R-LDH labels, stop, not a
>> valid name. c) if the domain contains NR-LDH labels, make
>> them all the same case d) do a straight byte comparison of
>> the addresses
> 
> I think that restricting R-LDH labels that are not A-labels is
> too strict, see for example Phil Hallam-Baker's proposed
> encapsulation of email addresses with "the mesh" (attached).
> 
>   TL;DR:
> The "mm" R-LDH namespace (if/when implemented) or some other
> future namespace should probably not be excluded at this time.
> 
> If the intent is to canonicalize A-labels to U-labels, then
> perhaps only "xn--" labels should be proscribed, if any.
> 
> headers, and perhaps more than just one such form.  If so,
> there is no need to proscribe any names at all.  The client
> performs no conversions, and the certificate would need to be
> inclusive of any addresses that are in actual use.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 11:49:27 -0500

> On Feb 3, 2017, at 11:07 AM, John C Klensin <[email-masked]> wrote:
> 
> there too and it hasn't ended happily.

I must say that I am quite sympathetic to many of the points
you raise.  As is often the case in discussions of the finer
points of an issue, we're not as far apart as it may seem.
That said, I do want to comment on the objection to having
to deal with "all the alternative forms".

My suggestion is not to publish a combinatorial explosion.
Rather, my suggestion is to publish precisely the verbatim
forms that users will emit as their purported email addresses
in message origin headers.  If they use an address form that
is not published in the certificate (without any coversions)
then the certificate will not match the purported author.

Thus I would expect that for a user with an all-ASCII localpart
name, there might in be a need to use one of two addresses.
For me that might be (neither address is currently provisioned):

	[email-masked]
	[email-masked]

I might then use the former in email with peers whose systems
support "EAI" and the latter with peers whose systems do not.
Had I, hypotheticall, registered a related domain under a
Cyrillic TLD, I would still use one of two address forms

	[email-masked]
	[email-masked]

and these (or whatever the user actually needs to be known
as) would be the only ones in the certificate.  This is not
very different from a certificate with two addresses in
domains that are simply distinct, rather than just being
variant encodings of the same thing:

	[email-masked]
	[email-masked]
	...

Such a certificate (like many a PGP public key) carries
multiple personae.  Putting multiple extant address forms
in a certificate can free the verifier from performing any
encoding conversions.  Perhaps that's worthwhile.

A certificate that lists multiple address forms, whether
semantically distinct, or just variant encodings, may be
more likely to work with verifiers that predate the
specification and do no conversions.  Forbidding variant
forms can close off interoperability options.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2017 17:20:47 -0000

In article <D45CE6A5317D4B373CD90742@PSB> you write:
>(or vice versa), say as little as possible. ...

I'd like to endorse John's point -- if these things look like e-mail
addresses, they should *be* e-mail addresses, with the same rules.
Particularly in a security context, we're not doing people any favors
by allowing strings that look almost like addresses but aren't, or
alternate forms where users have to decide whether they're equivalent.

If people want to do experiments with other kinds of names, that
is fine, but they don't go into a standards track document.  If
they turn out to be useful, we can add them to the spec later.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Fri, 3 Feb 2017 10:59:15 -0800

On Fri, Feb 3, 2017 at 8:07 AM, John C Klensin <[email-masked]> wrote:

> 2008 and SMTPUTF8 documents,

There is a recently posted 06 draft now, that calls out the IDNA 2008
requirement (RFC 5890) for the domain of the email address explicitly.
This is for SmtpUtf8Name and rfc822Name.  In the very brief time its been
up, we haven't gotten feedback in the WG for that proposal.  It currently
and previously called out that the format of SmtpUtf8Name is SmtpUtf8Mailbox,
and that is a modified form of Internationalized Mailbox defined in Section
3.3 of (RFC6531).

say that strings in certificates
> (or vice versa), say as little as possible.

The document calls for SmtpUtf8Name to use U-labels or NR-LDH ASCII labels
for domain but not A-labels.  We got advice to minimize alternative domain
forms as some implementations have had bugs doing the transform.  We chose
U-labels to be consistent as the local-part is already UTF8 form and to
simplify implementations.  The document recommends that SmtpUtf8Name only
be used when the local-part requires UTF8 and otherwise use rfc822Name.

-Wei

> The problem is that

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 14:23:53 -0500

> On Feb 3, 2017, at 1:59 PM, Wei Chuang <[email-masked]> wrote:
> 

Can you clarify what this means for addresses such as:

	U: [email-masked]
	A: [email-masked]

The local part is all ASCII, so should the "U" or "A" variant be used?

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Fri, 3 Feb 2017 11:38:40 -0800

>         U: [email-masked]

Not recommended but supported by SmtpUtf8Name.

>         A: [email-masked]

Use rfc822Name.  This is recommended.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Feb 2017 14:51:24 -0500

> On Feb 3, 2017, at 2:38 PM, Wei Chuang <[email-masked]> wrote:
> 

So, to be clear, for the same domain, some addresses will be
represented as rfc822Name SAN elements (with the domain in
A-label form), and other addresses (those with non-ASCII
localparts) will be represented as SmtpUtf8Name SAN elements
(with the domain in U-label form).

A verifier checking for an address with a non-ASCII localpart
will compare against SmtpUtf8Name elements with U-label domain
encodings, while a verifier checking for an address with an all
ASCII localpart will check against rfc822Name elements using an
A-label domain encoding (of the same domain).

Is that right?  Thus the verifier would sometimes need to convert
from U-labels to A-labels (when the localpart is all ASCII), and
at other times from A-labels to U-labels (when the localpart is not
all ASCII)...

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Feb 2017 09:14:17 -0500

--On Friday, February 3, 2017 14:51 -0500 Viktor Dukhovni
<[email-masked]> wrote:

>...
> Is that right?  Thus the verifier would sometimes need to
> convert from U-labels to A-labels (when the localpart is all
> ASCII), and at other times from A-labels to U-labels (when the
> localpart is not all ASCII)...

Victor,

I think there is another issue hidden behind this that is worth
mentioning and that interacts with your concern above.  While it
may or may not be important for any given protocol in the
abstract (it will be for some, but not others), using strings
containing non-ASCII characters in ways that interface with
users is always going to involve tricky issues that require
understanding and understanding, not just plugging code points,
possibly with an encoding specified, into slots.  People who
"just" want to be told what to do so they don't need to think
about it, or who want to apply a package they don't understand,
are going to sooner or later find themselves or their users in
trouble, whether the issues are identified as security problems,
matching/equivalence errors of various kinds, user confusion due
to violation of the law of least astonishment, or something
else.   The underlying issues are the result of the wide and
very rich diversity of human writing systems and languages --
systems that are diverse enough that almost any simple statement
or rule one can come up with will have exceptions.

In general, that diversity is something we should celebrate
rather than trying to find quick fixes or tricks to get around,
only partially because those fixes or tricks aren't going to
work well for some group of people.  Narrow views of the
situation just lead to other traps.  In particular, while useful
lessons can be learned, one cannot extrapolate from knowledge or
experience of Latin-based scripts (even if one knows more than
one language that uses them differently) to all others, from
very closely related scripts (e.g., Greek-Latin-Cyrillic, some
subsets of Indic (or neo-Brahmi) scripts, or so-called CJK) to
writing system outside those groups without missing important
cases and causing problems elsewhere.

Like the kinds of diversity we deal with in some other areas,
the differences did not show up overnight.  A large fraction of
the human population has been cr4ating and practicing them for
centuries and, in many cases, tens of centuries.  

If IDNA enters the mix, another layer of knowledge and
understanding is required.  It is actually easier to grasp (or
grok) than the above, but may have even greater impact in
protocol design.  Unlike the above, IDNA is artificial and a
recent invention to solve a very specific problem with
incremental deployment, a decision most of us, including most of
those in the IDN business and those who use non-Latin scripts on
a daily basis, think was probably a good idea.    People simply
need to understand how it works and is intended to evolve, with
the U-label <-> A-label symmetry and checking requirements as
particularly important.  In particular for this case, protocols
which reach the user simply need to be ready to handle U-labels
and A-labels interchangeably.  Because of the combinatorial
explosion problem, trying to do that by enumerating the possible
FQDNs just won't work -- people may know what, e.g., they intend
to push out in email or use in the text of an HTML "a" element,
but there are going to be just too many things in the network
toat will change things back and forth for their own (perfectly
rational) reasons.   At least IMO, that makes a very strong
argument for protocols, where it is possible, defining and using
a single canonical form and expecting user interfaces to do
conversions as needed.

You may reasonably disagree with that last conclusion because it
is just a protocol design preference, but most of the rest
almost certainly must to be treated as immutable facts, at least
until and unless we all agree to use the same language and the
same orthography and writing system for that language.

   best,
      john

---

From: Wei Chuang <[email-masked]>
Date: Mon, 6 Feb 2017 10:03:27 -0800

> (with the domain in U-label form).

Yes that right.

> all ASCII)...

Yes that right.

Now that said what we've done is an extension of current practice keeping
them in place.  Conversions have been what's being done with rfc822Name
comparison for awhile, and that hasn't been changed by this document.  What
we've done is taken a new unhandled circumstance (UTF8 local part) and
specified its behavior.  With the SmtpUtf8Form we kept its scope and form
limited to reduce implementation overhead and limit the likelihood of
bugs.  As noted before we got advice to minimize conversions so we opted
for consistency and for the form where we think email will move towards.
In time those conversions will becomes fewer and fewer.  Yes the verifier
has to do conversions but that's already been practice now for many years
now.

If we focused solely on eliminating conversion as the objective, yes, we
could have done things differently but that would been disruptive to
existing practices.  The approach in the draft is incremental over those
practices since there's a large amount of deployed software.

While the draft does not preclude different email "personae" in a PKIX
certificate, I don't think this would be a good to specify in this draft.
I can see confusion between whether those "personae" represents a single
single person or multiple persons and that should be thought through in its
own draft.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Feb 2017 18:20:23 +0000

> > at other times from A-labels to U-labels (when the localpart is not

Understood.  As I mentioned, I think that avoiding all conversions,
and checking for whatever verbatim address is found in message
headers is less likely to lead to problems at the cost of some more
names in the certificate (all the names that the author uses in
practice, no combinatorial explosion).

We'll see how this plays out in practice.  It will take some time,
as adoption of SMTPUTF8 is still quite low.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Feb 2017 05:13:11 +0000

> as adoption of SMTPUTF8 is still quite low.

There's already a complication, in a pull request for OpenSSL,
Dmitry Belyavsky proposes an implementation of SmtpUtf8 in OpenSSL.
In this proposed implementation OpenSSL acquires a new dependency
on libicu (a widely used IDNA conversion library).  Such a new
dependency is a significant barrier to adoption of the pull request.

[ Donning OpenSSL team-menber hat ]

I am asking the author to remove that dependency, leaving construction
of the normal form of the reference identifier to the application
rather than the X.509 stack.  If he is unsuccessful, and there is
a fundamental requirement for X.509 certificate validation code to
become IDNA aware, that'd be a major barrier to widespread support
for this specification.

Review of the pull-request brings us to another (perhaps the main)
issue.  The security considerations section of the draft fails to
note a significant name-constraint issue.  Suppose an existing CA
is constrained to email addresses in a particular DNS subtree:

       CA Cert
         Name Constraint Extension
           Permitted
             rfc822Name: example.com
             rfc822Name: .example.com

with "example.com" an ordinary LDH domain.  Prior to the proposed
specification, this precludes, e.g., issuance of valid EE certificates
with rfc822 email addresses with a domain part of "example.net".

This draft breaks the existing name constraint restrictions, because
the same CA can now issue EE certificates with SmtpUtf8 addresses
outside the permitted rfc822Name tree.  Possibly including all-ASCII
addresses that just happen to be found in an SmtpUtf8 subjectAltName.

The problem is that the namespaces of the existing "rfc822Name"
constraints and the new "SmtpUtf8Name" constraints substantially
overlap leading to unexpected behaviour.

I therefore propose that:

    When validating an EE certificate that contains SmtpUtf8Name
    subjectAltName values, all such subjectAltName values must
    match any rfc822Name name constraints in each issuer certificate
    that does not also include SmtpUtf8Name constraints.  In
    particular, an issuer CA with only rfc822Name permitted subtrees
    cannot issue EE certificates with SmtpUtf8Name altNames bearing
    (non-ASCII) UTF-8 domains.

I don't recall seeing language in the draft that expains whether
addresses that are valid rfc822Name values can be instead presented
in the certificate as SmtpUtf8Name values, or whether any SmtpUtf8Name
value MUST contain either a non-ASCII localpart or a valid non-ASCII
UTF-8 domain.

It should also be possible to evaluate name constraints and match
an EE certificate against an email address reference identifier
without imposing a dependency on libraries that convert domain
names between A-label and U-label forms.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Feb 2017 05:18:22 -0500

--On Wednesday, February 8, 2017 05:13 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>...
> I am asking the author to remove that dependency, leaving
> construction of the normal form of the reference identifier to
> the application rather than the X.509 stack.  If he is
> unsuccessful, and there is a fundamental requirement for X.509
> certificate validation code to become IDNA aware, that'd be a
> major barrier to widespread support for this specification.

As you and others have pointed out, SMTPUTF8 is deploying rather
slowly.   That should not be a surprise to anyone who
participated in the WG discussions and understands the issues --
there are a complex sequencing and support tradeoffs involved
although with a number of problems some would describe as
involving "chicken and egg" relationships and others would claim
would benefit from a flag day.

So, as I understand it, you want to shift the issues to the
application in order to get more rapid deployment.  I prefer to
keep the decisions, including a single canonical form, bound to
the X.509 certificate because I think, especially given the
security implications of either false positives or false
negatives, that getting implementations right (and consistent)
is more important than getting quick deployment.   A preference
for "right" over "quick" is particularly important where IDNs
are concerned given the number of inconsistent implementations
of things claiming to be IDNA in the wild.

best,
   john

---

From: Wei Chuang <[email-masked]>
Date: Wed, 8 Feb 2017 06:46:41 -0800

> overlap leading to unexpected behaviour.

I wouldn't say unexpected.  The draft says the rfc822Name and SmtpUtf8Name
name constraints are applied separately, and don't affect other results
(see section 6).  It is followed by examples illustrating the behavior of
the overlap case.  The reason for separating the rfc822Name and
SmtpUtf8Name constraints was to minimize the domain A-label to U-label
conversions (and vice versa) (which I believe you're asking for too).

The assumption being made in the draft is that a SmtpUtf8Name aware issuer
will also be aware of the name constraints on that type.

>     that does not also include SmtpUtf8Name constraints.

As mentioned the draft is trying to avoid this comparison.

>     In

This could be added.

> value MUST contain either a non-ASCII localpart or a valid non-ASCII

This is mentioned in section 7 and says: "This document RECOMMENDS using
SmtpUtf8Name when local-part contains non-ASCII characters, and otherwise
rfc822Name."

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Feb 2017 15:19:43 +0000

On Wed, Feb 08, 2017 at 06:46:41AM -0800, Wei Chuang wrote:

> I wouldn't say unexpected.

It may well be expected as a consequence of decisions in the draft,
but it is objectively unwanted new behaviour for a name constrained
CA, to suddenly be able to issue certificates for previously excluded
addresses.  Software that allows such violations of previously
enforced constraints would IMHO be CVE-worthy.

> The draft says the rfc822Name and SmtpUtf8Name
> (see section 6). 

Yes, that's what I'm objecting to.  This is a design error in the
draft.  The namespaces are *not* separate, and orthogonal constraints
are not desirable.

> It is followed by examples illustrating the behavior of

This is not a valid reason to violate the meaning of existing name
constraints.  It is not even clear why any conversions would be
required.  All that one needs to do is satisfy rfc822Name constraints
when no SmtpUtf8Name constraints are present in the same certificate.
When the domain is a non-ASCII domain, no permitted tree or excluded
sub-tree matches without conversion.  Thus the address is acceptable
only if the rfc822Name constraints contain only excluded sub-trees.

The only corner case is when an all-ASCII address (both localpart
and domainpart) for some reason appears in SmtpUtf8Name.  Such
names could match a full address in rfc822Name constraints (not
just a domainpart sub-tree).  This is why it is important to be
clear about whether all-ASCII names are valid in that context.

> The assumption being made in the draft is that a SmtpUtf8Name
> aware issuer will also be aware of the name constraints on that type.

The issuer may be SmtpUtf8 aware, but the parent CA that sets the
issuer's constraints (possibly some time ago in the past) may not.
The issuer should not be able to evade name constraints.

> As mentioned the draft is trying to avoid this comparison.

This comparison MUST happen to avoid evasion of name constraints.
I see no need for "conversions" to implement these comparisons.
An issuer with only rfc822Name constraints present should only be
able to issue email altNames with ASCII domains that satisfy the
rfc822Name constraints.

> >     (non-ASCII) UTF-8 domains.

This needs to be added, and also language about how to match
SmtpUtf8Name elements against rfc822Name constraints in the
case that the domainpart is all-ASCII.

> SmtpUtf8Name when local-part contains non-ASCII characters, and otherwise

This effectively makes all-ASCII names valid in SmtpUtf8Name, which
increases scope for implementation errors.  I would prefer that
the draft prohibit use of SmtpUtf8Name when rfc822Name is an option.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Thu, 9 Feb 2017 09:34:27 -0800

> draft.  The namespaces are *not* separate, and orthogonal constraints

You are stretching the language used above.  They are "applied separately".

I think we're open to changing how name constraints are applied.  But its
worth spelling out the design concern clearly before going down that path.
The concern is that as we add a new representation for international email
address that we are seeing that combinatorial increase in comparisons
needed for name constraints.  An alternate design of SmtpUtf8Name would
have to check constraints for rfc822Name and legacy email address in
Distinguished Names in addition to SmtpUtf8Name and vice versa for those
forms.  This design chooses to simplify that by keeping rfc822Name name
constraint behavior and separately defining a new SmtpUtf8Name name
constraint behavior that works only on SmtpUtf8Name names.  That simplifies
the work of the path verifier and eliminates potential domain (A/U label)
conversions between the alternate forms.  Work is now shifted to the issuer
which must explicitly define SmtpUtf8Name name constraint.

> The issuer should not be able to evade name constraints.

Assuming we keep the current name constraint design, we can add a
requirement that name constraints on email addresses has to be consistently
applied on the certificate issuance path.  In other words, an issuer with
only rfc822Name name constraints in its path can only issue rfc822Name
subAltName email addresses.  Similarly SmptUtf8Name.  An issuer with both
SmtpUtf8Name and rfc822Name in its path can issue both subjectAltName name
form email addresses.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Feb 2017 17:57:38 +0000

[ Sorry about the duplicate post, Somehow the original body got
  "Content-Disposition: attachment", reposting as "inline". ]

> You are stretching the language used above.  They are "applied separately".

Separate application is not sufficient when the issuer's certificate
contains only rfc822Name constraints.

> needed for name constraints.

My proposal creates no combinatorial increase of any kind.  When
the issuer CA has *only* rfc822Name constraints, any SmtpUtf8Name
subjectAltNames in the certificate, instead of getting a free ride,
would have to satisfy the rfc822Name constraints.  Each rfc822Name
constraint becomes (under the identity function) a valid SmtpUtf8
constraint.

> This design chooses to simplify that by keeping rfc822Name name
> constraint behavior that works only on SmtpUtf8Name names.

Yes, buts this evades rfc822Name constraints created SmtpUtf8-agnostic
parent issuers.  The namespaces are not disjoint.

> That simplifies

The simplest thing for the verifier is to do no checks at all.
Presumably we make things as simple as possible, but no simpler.
The security requirements should be to correctly process existing
name constraints.  And I don't believe that *any* conversions are
required to do this.

Specifically, rfc822Name constraints that include a non-empty list
of permitted subtrees, in the absence of explicit SmtpUtf8Name
constraints would imply that the CA cannot issue *any* email altnames
for a non-ASCII domain.   If the domain is all-ASCII, no conversions
are required.  If the rfc822Name constraints have only excluded
subtrees, then no non-ASCII domain is excluded.

> subAltName email addresses.

No that's too limiting.  If the issuer is permitted to issue altnames
for "example.org", it should be able to issue "[email-masked]".

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Thu, 9 Feb 2017 16:33:44 -0500

Viktor:

RFC 5280 says:

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

I think you are talking about constraints on addresses at a particular host and constraints on mailboxes in a domain, but not constraints on a particular mailbox.  Please correct me is I got that wrong.

I think you are suggesting that any A-label in the rfc822Name be converted to a U-label, and the result is used to constrain the SmtpUtf8Name.

If people like your suggestion, then a constraint for a particular mailbox will still require a SmtpUtf8Name, so I think the mechanism described in the draft is needed.  It would just be used in combination with the above.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Feb 2017 22:39:51 +0000

On Thu, Feb 09, 2017 at 04:33:44PM -0500, Russ Housley wrote:

> I think you are talking about constraints on addresses at a particular
> host and constraints on mailboxes in a domain, but not constraints on a
> particular mailbox.  Please correct me is I got that wrong.

Primarily, but not exclusively.  In the case that an issuer CA is
constrainted to a specific rfc822Name, it should not be possible
to evade that constraint by using the same (all-ASCII) address as
an SmtpUtf8Name.

> I think you are suggesting that any A-label in the rfc822Name be converted
> to a U-label, and the result is used to constrain the SmtpUtf8Name.

No.  I am *not* suggesting *any* conversions.  If a CA has rfc822Name
constraints and no SmptUtf8Name constraints, and the rfc822Name
constraints limit the CA to "example.com", ".example.com", or as
you suggest above, a particular set of explicit rfc822Name addresses,
my suggestion is that it MUST NOT be able to issue SmtpUtf8Name altnames
that violate those constraints.  For example:

    * CA is constrained to permitted subtree rfc822Name: example.com
	- can issue SmtpUtfName: [email-masked]
	- cannot issue SmtpUtf8Name: [email-masked]

In the current form of the draft both would be allowed, the second
is a clear violation of the principle of least surprise (and the
policy of the parent CA that created the name constraint).

> If people like your suggestion, then a constraint for a particular mailbox
> will still require a SmtpUtf8Name, so I think the mechanism described in
> the draft is needed.  It would just be used in combination with the above.

As to particular addresses, again:

    * CA is constrained to permitted subtree rfc822Name: [email-masked]
	- cannot SmtpUtfName: [email-masked]
	- cannot issue SmtpUtf8Name: [email-masked]

In the current form of the draft both would be allowed, in clear
violation of the name constraint on the permitted email addresses.

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:02 -0500

Viktor:

[bottom posting]

> violation of the name constraint on the permitted email addresses.

Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be completely separate.

You are arguing for some crossover, but I do not understand how A-labels in the rfc822Name are handled in your proposal.

If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated to 'faß.de’ for comparison in SmtpUtf8Name.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:05 -0500

Viktor:

[bottom posting]

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:15 -0500

Viktor:

[bottom posting]

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:16 -0500

Viktor:

[bottom posting]

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:06 -0500

Viktor:

[bottom posting]

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Feb 2017 19:56:09 +0000

> Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be

This introduces a means to evade name constraints placed on existing
(intermediate) CAs whose issuer (parent CA) was/is not SmtpUtf8 aware.
Software that introduces such bypass mechanisms would rate a CVE.
OpenSSL will not implement the proposal in its current form.

Once again, a CA with *ONLY* rfc822Name constraints should not be
able to able issue EE certificates with SmtpUtf8Name altNames that
conflict with its rfc822Name constraints.

Once again, I am not concerned about A-labels, U-labels, etc.,
rather, if a CA is constrained to example.com (an ordinary LDH
domain) email addresses via rfc822Name, and no SmtpUtf8Name
constraints are present, then the CA in question MUST NOT be able
to bypass that constraint via SmtpUtf8Name altnames with a domain
part of "example.com".

> You are arguing for some crossover, but I do not understand how A-labels
> in the rfc822Name are handled in your proposal.

So far, I've said nothing about about A-labels in rfc822Name
constraints.  Now that you ask, my view is that in the absence of
SmtpUtf8 constraints, an rfc822Name constraint that restricts a CA
to issue EE altnames with a domain part of xn--b1adqpd3ao5c.org
means that the CA should only be only issue rfc822Name altnames with
that verbatim A-label form only.  Thus, that same hypotheical CA would
not be able to issue SmtpUtf8Names with a domain part of духовный.org,
because that UTF-8 name does not match the literal rfc822Name constraint.

> If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated
> to 'faß.de’ for comparison in SmtpUtf8Name.

I did not want to conflate the rfc822Name constraint bypass issue
with the issue of A-label/U-label conversions.  My take is still
that conversions are not a good idea, and that a reference identifier
should be found verbatim in the certificate as a matching presented
identifier with no conversions.  With that a 'faß.de' SmtpUtf8Name
altname would not be allowed for a CA constrained to just
'xn--fa-hia.de'.

A CA that wants to start issuing 'faß.de' altnames can use a
suitable new intermediate certificate with appropriate additional
SmtpUtf8 constraints.

Requiring conversions from rfc822Name constraints that are A-labels
to correspoding U-label constraints would IMHO be a mistake, and
would require the introduction into OpenSSL and other X.509 stacks
of code that converts from A-labels to U-labels.  I think such
complexity is unwarranted, and I'd very much like to avoid the
need for any such conversions.

-- 
	Viktor.