Issue with *.zm TLD

Another point is the PSL is used for rate limit -> No Problem
If LE would block PSL names from issuing Wildcard -> No Problem
If LE block PSL names fromissuing an Cert this is an Problem.
For example if i own top-dyn-dns.domain and allow users to use subdomains.
I can live with the restriction not to use cookies but i have an problem if can not get an cert for my domain
for securely use it as admin or info domain about this service.

I meant zm in addition to your list.

I believe @weppos is saying the opposite: A Wikipedia article is no longer sufficient proof for changes to the PSL.

However, I think what you're getting at is: If Wikipedia was sufficient in the past, it should be sufficient to undo past decisions that were also based on Wikipedia? I think that's not a practical policy, since it would prevent ratcheting up the requirements.

If LE block PSL names fromissuing an Cert this is an Problem.

Note that there are two "sections" to the PSL: ICANN TLDs and Private suffixes. For the purposes of rejecting issuance, we use the ICANN TLD section. Your example of "top-dyn-dns.domain" would presumably be a Private suffix and so would not be rejected.

Thanks for your participation in this thread @weppos, it's been very helpful!

To summarize: '*.zm' is listed on the current PSL, in the ICANN section, which means that any single DNS label, combined with '.zm', is considered an ICANN public suffix. This may be an error in the PSL, which will require an approval from the .zm registry to fix.

From the Let's Encrypt side: We will wait for such an update. We're not planning to generate overrides.

@guysherman, it sounds like you may have contacts at the .zm registry. Would you like to reach out to them and ask them to request a PSL update?

@jsha OK i was not aware that there are two different sections at all.
But what would be the problem to issue an Certificate for example “kinder” this is an ICANN TLD since this cert would not affect subdomains. Is there any CA/B rule ? And i can understand that you will not make an exception in LE for an single domain.

You get it right, i mean if there was an ICANN TLDs *.TLD instead the normal TLD that someone would expect i based on wiki. I really can not understand why it would require an ICANN request to revert it.

That's correct. We have no written rule, but anybody could edit wikipedia and it can't be considered an authoritative source for such kind of decisions.

My pleasure. I'm prepping a patch for review.

This is a wrong assumption. You are assuming that the entry was added based on the wikipedia state, but this can't be proved (the comment at the top of the section is irrelevant. We used to add it if we could not provide a more exhaustive link).

As there is no ticket history associated with the particular commit that added the entry, then we can't track back what source was used to add it. And to be honest, this is completely irrelevant.

@jsha regardless the fix on the PSL side, there is another potential issue that may delay the merge of the fix. I left a comment today in this ticket on the letsencrypt/boulder repo. Brad mentioned an interesting challenge.

Regardless the follow ups on that specific topic, let me know if there is anything I can do to help you with getting the PSL changes merged into your mirror. I’ll be happy to provide patches.

@jsha I’ll see what I can do, those relationships may have faded with time, but I’ll find out.

FYI https://github.com/publicsuffix/list/issues/140