Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Ce contenu est uniquement disponible en
Please consider how the .internal TLD will interact with the certificate authority (CA) system. The current proposal appears to reserve .internal as a TLD without allowing any organization to uniquely own domains. This makes it impossible for a public CA to provide certificates for these domains. Without certificates it's impossible for client software to determine if it is connecting to the correct server (as multiple servers can squat on the same domain name, and computers can switch networks / DNS resolvers). Private CAs partially solve this concern. Some computers (like those of contractors) can end up trusting several private CAs, each of which can impersonate any *.internal domain (or more). Data and credentials can spill across organizations, even accidentally, when this occurs. TLS Name Constraints don't solve this problem either as private CAs would typically constrain to *.internal.
Consider registering domains under .internal such that organizations can uniquely and verifiably own their internal domain names. For example: icann.internal could be registered by ICANN.
I operate three public suffixes that offer free registration and are compatible with the public CAs. The trick I'm using is to allow domain owners to set ACME-DNS01 TXT records, but not other records (A/AAAA/CNAME/...) which must be set on a private DNS resolver. A designated TLD for this purpose would be much better suited. See: https://www.getlocalcert.net/