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

[Viktor Dukhovni <[e-mail]>]

On Mon, Jan 23, 2017 at 09:43:04PM -0500, John C Klensin wrote:

> The LAMPS WG apparently decided that it
> wanted to insist on U-labels when IDN labels were concerned and
> that doing so would make comparison rules easier.  I wasn't part
> of their discussions, but believe the issue was that they
> concluded that certificates should contain one form or the
> other, but not both (or either on a per-cert basis), and then
> selected the U-label form.  Doing that avoids their having to
> decide whether [e-mail] and fred@ex᭰le.com were
> equal and, I assume, a whole set of even more complex issues
> about hashes and signatures over certificates.
> 
> I can argue for the choice of A-labels rather than U-labels (or
> vice versa), but the choice is a matter of taste and I'm happy
> to accept the WG's analysis and decision.

I also agree that having a single normal form in the certificate
has some merit.  I must say that the choice of U-label as that form
is somewhat unexpected given the use of an A-label normal form with
DNS subjectAltNames.  Consistency might have been preferable, though
of course the local part offers no similar representation, and so
perhaps the compelling argument in favour of U-labels is using a
consistent encoding for both parts.

This does mean one one will not be able to obtain a useful certificate
for addresses like [e-mail], which is what Apple's
Mail.app (even in the latest MacOS Sierra) emits when I configure
a sender address in the unicode form of that domain.  My MTA delivers
both the U-label and A-label forms to the same mailbox, but my other
(not Mutt) MUA only sends A-labels.

Which leads me to the observation that verification software will
already have the message "From:" (or other purported) signer address
in hand, which it will be comparing with the associated certificate.
So it seems far more natural to use *that* address *verbatim* as
the reference identifier to seek in the certificate.

One might then obtain a certificates with two email subjectAltNames:

    * [e-mail]
    * user@духовный.org

which will work regardless of which form is seen in the message
headers, and would not require any conversions by the verifier.

In other words, check the certificate for whichever address form
appears in the message headers.  If that's how the sending system
knows the author, then perhaps it ought to be good enough in the
certificate too!

This would dramatically simply the implementation, the application
provides the X.509 library with the verbatim author address and
this either matches or does not match the certificate without any
conversions.

-- 
	Viktor.