Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalize

On Tue, Feb 7, 2017 at 9:13 PM, Viktor Dukhovni 
<ietf-dane(_at_)dukhovni(_dot_)org>
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

smime.p7s
Description: S/MIME Cryptographic Signature