> On Feb 3, 2017, at 11:07 AM, John C Klensin <john-ietf@xxxxxxx> 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 ietf-dane@xxxxxxxxxxxxxxxxxxxx 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 ietf-dane@xxxxxxxxxxxxxxxxxxx--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: ietf-dane@xxxxxxxxxxxx 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.