Update public_suffix_list.dat (gov.kz / edu.kz)

[freejoins]

Need move 3LD edu.kz and gov.kz from ICANN to Private list to allow generation of Let's Encrypt SSL certificates for this domains.

• Description of Organization
• Reason for PSL Inclusion
• DNS verification via dig
• Run Syntax Checker (make test)

Description of Organization

Organization: KazNIC Organization ccTLD of .KZ and .ҚАЗ
Organization Website: https://www.nic.kz

Reason for PSL Inclusion

Need move 3LD edu.kz and gov.kz from ICANN to Private list to allow generation of Let's Encrypt SSL certificates for this domains.

DNS Verification via dig

$ dig +short TXT _psl.gov.kz
"https://github.com/publicsuffix/list/pull/965"
$ dig +short TXT _psl.edu.kz
"https://github.com/publicsuffix/list/pull/965"

make test

================================================================
# TOTAL: 5
# PASS: 5
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
================================================================

[dnsguru]

This is a very interesting and strange request. I am not aware of where a ccTLD administrator has desired to move associated stub zones away from their association to the primary NIC.

@freejoins I see that the appropriate DNS answers are in place, so clearly there is administrative connection that can be validated.

@sleevi this is a really odd request - would we not want to keep these together within the ICANN section? Is this just a situation of oddness with how letsencrypt are handling business?

[freejoins]

This is a very interesting and strange request. I am not aware of where a ccTLD administrator has desired to move associated stub zones away from their association to the primary NIC.

@freejoins I see that the appropriate DNS answers are in place, so clearly there is administrative connection that can be validated.

@sleevi this is a really odd request - would we not want to keep these together within the ICANN section? Is this just a situation of oddness with how letsencrypt are handling business?

I saw a similar request for gov.ru

Zone edu.kz is used for educational organizations. And the Ministry of Education decided to place on it a portal with a catalog of subdomains resources and the possibility of Single Sign On. Similarly, for gov.kz zone, a portal-catalog of subdomain resources will be created and the possibility of Single Sign On for government organizations.

[sleevi]

No matter where we place it in the PSL, that single-sign-on won’t work at that level. That’s not supported by implementations.

[freejoins]

No matter where we place it in the PSL, that single-sign-on won’t work at that level. That’s not supported by implementations.

This is the task of the ministries, as they plan to implement SSO. Now the problem is that Let's Encrypt does not allow creating certificates for these domains based on this list.

[sleevi]

Gotcha. I definitely don’t think we should move this for Let’s Encrypt, because that’s going to cause issues for other consumers, and you can use other CAs or file an issue with Let’s Encrypt. The more important thing, however, is setting cookies at that level won’t work, so SSO won’t work. Going further, it will likely cause compatibility issues as browsers try to block cross-site tracking. I don’t have an easy answer for the SSO problem, because the very model of setting cookies at the apex while allowing different registrations is, unfortunately, problematic and not supported nor likely to be supported. The answer we tell every other domain operator, such as those looking to facilitate their customers, is to use separate domains for what they allow to be registered and for their business portal. “Holes” where cookies can be set on intermediate levels of hierarchies are basically security bugs. Once a different domain is used, the question of TLS certificates is no longer an issue.

[freejoins]

If I understood correctly. Zones can be transferred to a private list if these domains are no longer reserved on the rule of registry? Like this #815

[sleevi]

Moving them won’t solve the issue. Whether they’re in the ICANN section or the PRIVATE section, software won’t allow them to set cookies or other persistence information. So the SSO won’t work. You basically cannot use any entry in the PSL to host a website, nor (for any useful purpose beyond a redirect), any parent domain either. So moving this won’t allow gov.kz or edu.kz to set a cookie or store data (necessary for an SSO solution), and won’t make browsers start supporting navigating or accessing the site.

[freejoins]

Forget about the SSO. He is still very far away, and I don’t know how they will implement it.

In this time the problem is in Let'sEncrypt use this list and not allow issue certificate.
Moving to a private list will help to solve this problem and will not break anything else!

[sleevi]

Thanks for clarifying. We don’t do merges to work around Let’s Encrypt challenges, and that seems to be the only remaining reason for the request. The issue being had is not an issue with the PSL, it’s with a particular consumer. Changing this wouldn’t be to the benefit of PSL consumers, and would be detrimental. In the past, we moved entries because while the registry policies no longer reserved it, there were existing domains. Unless all of those existing domains have been rescinded, which doesn’t seem to be the case, moving doesn’t seem the right solution.

[dnsguru]

It sounds like the desired change is for a Let's Encrypt workaround. See https://publicsuffix.org/learn/ bottom of page - Let's Encrypt has documentation about following their process for requesting exceptions.

[dnsguru]

@sleevi is this a wontfix?