decode punycode public suffixes in PublicSuffixMatcher.verify

[dxbjavid]

PublicSuffixMatcher.verify (through verifyInternal) resolves the domain against the suffix rules without the normalisation and punycode decoding that getDomainRoot and matches already apply, and the bundled list holds IDN suffixes in their Unicode form. So an ACE-encoded public suffix such as xn--h-2fa.no matches no rule and verify returns true, which lets the cookie PublicSuffixDomainFilter treat a whole IDN TLD as a registrable domain and accept a supercookie scoped to it, even though matches recognises the same suffix correctly. This decodes and lowercases the input in verifyInternal the same way getDomainRoot does, so both the ACE and Unicode forms are rejected consistently while genuine registrable subdomains under an IDN suffix are still allowed.

[ok2c]

@dxbjavid Could we pull the normalization logic up into #verify method and leave #verifyInternal as is under assumption its input is always normalized?

[dxbjavid]

makes sense, done. normalisation now happens in verify and verifyInternal just assumes a normalised input.

one thing worth flagging: DefaultHostnameVerifier.matchIdentity calls verifyInternal directly rather than through verify, so with the logic moved up it now relies on the identity already being in normalised form. that matches the pre-existing behaviour on master, but if you'd like that path covered too i'm happy to normalise the identity at that call site.