Hello,
I enjoy let’s encrypt on several domains on my dedicated server, but can’t enjoy this one.
There is any possibility even in the future?
Thanks a lot for your support
Silvano
Is there any progress on IDN support? E.g., I can’t find any branch on GitHub.
There’s a pull request from a couple of days ago with some relevant changes. I think the Certificate Policy/Certification Practice Statement will need to be updated as well before this can go live, as at least Mozilla’s root program requires documentation on how IDNs are handled.
2 Likes
If I understand the pull request correctly, homophone prevention will simply be offloaded to the domain registrars? That is, if someone manages to successfully register “google.com” where one of the “o” is cyrillic instead of latin, let’s encrypt will happily issue certs for that site?
That’s how I’d read it, yes.
I took a look at a couple of Certification Practice Statement from various popular CAs, and they seem to either not mention IDNs at all (e.g. Comodo) or include a manual review process for certain cases (e.g. Symantec and related brands). Not really sure what the state of the industry is here - the Baseline Requirements are quiet on this issue, and Mozilla’s policy only asks for a CAs policy on IDNs to be included in the CPS, but does not actually state that CAs need to do anything to actively prevent homographic spoofing.
Maybe it really isn’t something that can or should be solved at the CA level, though I’m personally not all that optimistic about how well domain registrars are equipped to handle this problem. Then again, a spoofed google.com domain is bad enough without a valid certificate.
The registrars are definitely not the right people to be making this decision, it’s up to the registries. That’s an important difference, almost all TLDs have a single registry function, operated by a specific ICANN contactable entity, but some have dozens or even hundreds of registrars, which may be fly-by-night operations you’ve never heard of operating from a P/O box. All key security considerations need to be reflected onto the relatively trustworthy registries, not registrars.
Geographic registries are in a good position to manage homograph spoofing. The Swedish for example are in a good position to judge which symbols from Unicode will be necessary to a Swedish person or business and make intelligent decisions that minimise homographic spoofing by restricting unnecessary characters. The 香港 registry is well placed to spot when a Unicode Han disambiguation is either necessary, or worse than useless to the goal of avoiding confusion on the Internet and prohibit or allow it accordingly.
Generic registries are not in a good position. The safest thing for them to do would be prohibit IDNs. For a registry as heavily associated with voracious greed as com that was never going to happen. The result is that last I looked browsers were just ignoring IDNs from some registries or for some unlikely language combinations, showing the A labels in the UI so that users would see something was amiss if they were spoofed. I don’t know if this eventually changed or not, Mozilla could tell you their current policy if you ask.
Probably Let’s Encrypt should just punt, as it sounds like you’re doing. This is not your fight.
4 Likes
I just posted an update on some progress toward IDN issuance at
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.