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 Feb 3, 2017, at 11:07 AM, John C Klensin <[e-mail]> wrote:
> 
> As to "put all the alternate forms in the cert", we've been
> 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):

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

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

	[e-mail]--p1ai
	ietf-dane@духовный.рф

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:

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

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.