Add IDN TLD support

[pfigel]

publicsuffix-go's Find expects suffixes to be in unicode rather than punycode, causing IDN TLDs to be rejected. Convert domains to unicode prior to checking whether the domain ends in an ICANN suffix.

Fixes #2277.

[pfigel]

Further testing revealed that the rate-limiting code in ra.go could be affected by this too. domainsForRateLimiting correctly handles punycoded IDN suffixes with one label:

domainsForRateLimiting([]string{"example.xn--fiqs8s"}) == "example.xn--fiqs8s"

However, it fails for suffixes with multiple IDN labels (.xn--o1ach.xn--90a3ac or упр.срб being a suffix like co.uk):

domainsForRateLimiting([]string{"example.xn--o1ach.xn--90a3ac"}) == "xn--o1ach.xn--90a3ac"

(This is not too bad, since there aren't exactly too many multi-label IDN suffixes on the list and the only effect would be that rate limiting scope is applied too strictly, but we might as well get it right everywhere.)

Converting to unicode would fix this issue as well (though we'd have to convert back to punycode for storage in order for the rate-limit identifier to remain backwards-compatible), but I'm wondering whether handling this conversion (and preserving the encoding for the return values, I guess?) should be done in publicsuffix-go rather than the calling code. @weppos: Any thoughts on this?

[wensheng]

Please merge this.

I was excited by the announcement of IDN support. But when I tried it, it give me:

The request message was malformed :: Name does not end in a public suffix

thx

[jsha]

My preference would be for publicsuffix-go to accept A-labels rather than U-labels. That way we don't have to convert back and forth.

[kachkaev]

I agree with @jsha. U-labels are less likely to be supported by other tools, so it is more reasonable to define host names with ASCII characters inside ENV variables and configs. If Letsencrypt expects Unicode, some developers will end up having the same thing defined twice.

[jsha]

@PatF regarding the domainsForRateLimiting issue, to clarify for other readers xn--o1ach.xn--90a3ac (упр.срб) is a public suffix, so the second example should return example.xn--o1ach.xn--90a3ac.

[cpu]

Hi @PatF - thanks for putting this together. I really appreciate that you took the time to arrive with a solution in addition to a problem. You can't beat that! ❤️

That said I think we're all in agreement that upstream support is better than special-casing in Boulder. I'm going to close this PR and would love if you could give #2339 a 🔍