On Tue, Feb 7, 2017 at 9:13 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Mon, Feb 06, 2017 at 06:20:23PM +0000, Viktor Dukhovni wrote:
> 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.
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 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.
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.
As mentioned the draft is trying to avoid this comparison.
In
particular, an issuer CA with only rfc822Name permitted subtrees
cannot issue EE certificates with SmtpUtf8Name altNames bearing
(non-ASCII) UTF-8 domains.
This could be added.
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.
This is mentioned in section 7 and says: "This document RECOMMENDS using SmtpUtf8Name when local-part contains non-ASCII characters, and otherwise rfc822Name."
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.
-Wei
<<attachment: smime.p7s>>