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

There is a difference between domains for non-latin scripts and an
xn-- domain that represents a name that can also be written using
plain latin letters. It is just too bad that registrars are allowed to
issues such certificates. So as a simple heuristic a browser can show
the domain as xn-- if it encodes a name that does not require xn--
encoding. Of cause that does not help when somebody uses
xn--eic-0ed.com which is eрic.com with the Cyrillic letter "р", but
that is a different and indeed hard to solve problems with homographs
in Unicode.

On 18 April 2017 at 09:34, Martin Thomson <[email protected]> wrote:
> 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.
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security