Hi Gerv, Obviously you are correct, it wouldn't make much sense to say "please constrain yourself to everything...or almost everything!" I think the only way for my alternative to work is to just develop a system of increased scrutiny of the intermediates, to develop a more rigorous set of policy agreements and technical verifications. I myself am conflicted about that since on the one hand it seems like the totally wrong approach yet on the other hand I wonder if it's inevitable, that we'll basically have to come up with a system anyway. Some thoughts: 1) As a first step on the path to fairness, perhaps there can be agreement that the goal of any name constraint policy should be the idea that a single root does not "get the whole internet". Maybe a whole CA organization might, but a single root should not. Could everyone agree? 2) I picture a broadcast mechanism along the lines of OneCRL that would/could play a role in helping determine when a root's scope has become too broad. This mechanism combined with live browsing data could flag potential problems and conflicts with the policy agreements. 3) I was hoping that by now someone would have spoken up here regarding how much of an appetite some of the larger CA's have in discussing constraints. I assume the smaller ones are open to the idea and some are already doing it, but the bigger players...? 4) Do any CA's have public announcements or policies regarding newer TLD's and their plans to issue certs for them? Has anyone said "we will not issue certs for the .ninja domain"? I guess a final thought is that the work Richard (?) did to come up with an initial set of constraints for the trusted roots is a good place to start the conversation of how to fairly divvy up the DNS space. It's like saying to the CA's, "since these are the areas where your business is, why not just constrain yourself to these TLD's?" As long as it's not carved in stone it should be a reasonable way to go...?
On 12/03/15 22:54, Peter Kurrasch wrote: > This backwards compatibility problem is a fatal flaw, but I have an > alternative in mind: establish and enforce boundaries within the > intermediates. The browser can enforce a policy that a technical > constraint be specified somewhere between the root and the end cert. > Where exactly in the chain that happens is not important so long as it's > found and the boundaries established are not violated. The absence of > the constraint would flag an error. Or, perhaps, a special table would > be used to provide "default" boundaries. What would prevent that constraint being extremely lax? Or what would prevent a CA issuing one intermediate for all the TLDs starting a-m, and another for all of the TLDs starting n-z? The mere presence of a restriction is not a meaningful restriction :-) > It is certainly a good idea to encourage any CA to self-constrain but we > do need a way to forcibly constrain all CA's. Allowing any CA to opt-out > defeats the whole purpose. And not allowing CAs to opt out means we are forcibly constraining the business areas in which particular CAs may operate. I shudder at the thought of the task of trying to do that in a fair manner. (And I don't think "preserve the status quo" is fair.) Gerv | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
