What problem(s) are you trying to solve with this concept? If it's misissuance as broadly defined, then I'm highly skeptical that Registry Operators - the number of which is on the same order of magnitude as CAs [1] - would perform better than existing CAs in this regard. You also need to consider the fact that ICANN has little authority over ccTLDs.
- Wayne [1] https://icannwiki.org/Category:Registries On Thu, Aug 16, 2018 at 12:51 PM Matthew Hardeman via dev-security-policy < [email protected]> wrote: > 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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
