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

On 17/04/17 19:43, Martin Heaps 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" . 

This is perhaps a philosophical issue, but I see this viewpoint as
(perhaps inadvertently) telling users of non-Latin scripts that they are
second-class citizens.

A better way of looking at it is:

* The internet community wished to make all currently-used scripts
first-class citizens on the web, including allowing people to have
domain names in their own script

* It was discovered that the current DNS did not support using Unicode
directly for this purpose

* An encoding was developed such that domains in non-Latin letters could
be encoded using Latin letters

So the domain "epic.com" is actually the domain "epic.com". The fact
that it's encoded on the wire as "xn--e1awd7f.com" is an implementation
detail that, in ideal circumstances, should never be exposed to users.

> The word "fake" is probably an inpracise word to use, but in the
> context that the domain name as registered is perporting to be
> another domain name it is not; this is fake. The SSL provider;
> LetsEncrypt in this case seems to not be able to ensure with browsers
> that there is a clear destinction between the two names of the domain
> certified by the CA.

Neither browsers nor CAs have a database of all domain names, such that
they can see that one is visually confusable with another. Registries
have this data, and it is their responsibility to deal with this problem.

Gerv