Re: Unicode domain names issue (Encrypting a "fake" domain name)

On Tue, Apr 18, 2017 at 4:43 AM, Martin Heaps <[email protected]> wrote:
> No, a clear destinction should be made; the certificate is for the domain "xn--e1awd7f.com" but in certain browsers this is presented to the user as "epic.com" . It may not be the certificates authority to provide trust to the user that the domain certified is valid; but they should as a bare minimum have an understanding with browser providers that the certificate name is not misconstrued in any way; and that a certificate for "xn--e1awd7f.com" can never be confused with applying to "epic.com".

Anne is right here.  But so also is Martin (I on the other hand cannot
claim any sort of authority).  Let's Encrypt have a firm policy here;
the line is grey and they are (rightly) uninterested in trying to set
where that line exists.  But a browser might be able to do
something... maybe.

This is a hard problem, because even if this case seems obvious,
others are much less so.  People want to use names they know and that
means using their native script.  There are things that a browser can
do, but the task of effectively communicating the true security status
of a site is one of the hard problems.

We're still open to ideas.  I've heard of many ideas, but the gap
between theory and practice is much larger in practice than we'd like.
For example, we could define a set of characters that form the native
script and warn if characters outside that script are used.  That
would work for browsers in an English-native locale, but would
disadvantage English-speakers from Japan in this particular example,
for whom both of these names appear to be special.