Of late, there seems to be an ever increasing number of misissuances of various forms arising.
Despite certificate transparency, increased use of linters, etc, it's virtually impossible to find any CA issuing in volume that hasn't committed some issuance sin. Simultaneously, there seems to be an increasing level of buy-in that the only useful identifying element(s) in a WebPKI certificate today are the domain labels covered by the certificate and that these certificates should be issued only upon demonstrated control of the included domain labels. DNS is already authoritatively hierarchical. ICANN has pretty broad authority to impose requirements upon the gTLDs... What if the various user agents' root programs all lobbied ICANN to impose a new technical requirement upon TLD REGISTRY operators? Specifically, that all registry operators would: 1. Run one or more root CAs (presumably a Root CA per TLD under their management), to be included in the user agents' root program trust stores, such that each of these certificates is technically constrained to the included gTLD(s) contractually managed by that registry operator. - and further - 2. That all such registries be required to make available to the registrars an automated interface for request of certificates signed by said CA (or a registry held and controlled issuing CA descendent of said root) over domain labels within that TLD on behalf of the customer holding a domain. (For example, Google Domains has an interface by which it can request a certificate to be created and signed over a customer provided public key for requested labels within that registrar's customer's account.) - and further - 3. The registrars be required to provide appropriate interfaces to their customers (just as they do for DNSSEC DS records today) to have the registry issue certificates over those domains they hold. If you wanted to spice it up, you could even require that the domain holder be able to request a signature over a technically constrained SubCA. Then the domain holders can do whatever they like with their domains' certificates. Perform validation of technical requirements (like no 5 year EE certs) into the product and enforce at the product level. If the WebPKI is truly to be reduced to identifying specific domain labels in certificates issued only for those demonstrating control over those labels, why do we really need a marketplace where multiple entities can provide those certificates? The combination of registrar and registry already have complete trust in these matters because those actors can hijack control of their domains in an instant and properly ask any CA to issue. That can happen today. What this would improve, however, is that there's one and only one place to get a certificate for your example.com. From the registrar for that domain, with the signing request authenticated by the registrar as being for the customer of the registrar who holds that domain and then further delegated for signature by the registry itself. Such a mechanism could even be incrementally rolled out in parallel to the current scheme. Over time, modern TLS endpoints meant to be accessed to browsers would migrate to certificates issued descending from these registry held and managed roots. >From a practicality perspective, I don't see why this couldn't happen, should >enough lobbying of ICANN be provided. Today, ICANN already imposes certain >technical requirements upon both Registries and Registrars as well as >constraints upon their interactions with each other. As a not entirely >unrelated example -- this one involving cryptography and key management -- >today registries of generic TLDs are required to implement DNSSEC. I recognize it's a radical departure from what is. I'm interested in understanding if anything proposed here is impossible. If what's proposed here CAN happen, AND IF we are confident that valid certificates for a domain label should unambiguously align to domain control, isn't this the ultimate solution? Thanks, Matt Hardeman _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
