On 06/03/15 16:26, Richard Barnes wrote: > https://wiki.mozilla.org/CA:NameConstraints
I am unconvinced by the wisdom of this proposal. Others have made some of the same points, but my major objection is that I feel that this will calcify the trust list and entrench existing players, because inevitably the "ubiquity" of CAs who have constraints released under the release process will suffer for years afterwards due to old clients, and so their offerings will be uncompetitive. Other objections include: * This plan can't cope with the flood of new gTLDs without creating some "unconstrained" CAs, at which point we've just handed over a market oligopoly. How do we decide who gets that? * It's not possible for it both to be true that "The name constraints for a root should allow issuance for any name that the CA wishes to issue for" and "The content of the permitted suffix list will be determined by community consensus". Which is it? "Too big to fail" is a problem - the solution is more CAs and more competition. "Weakest CA breaks everything" is a problem - the solution is fewer CAs and less competition. How to reconcile? Many solutions which solve one make the other worse. This is a solution which addresses "weakest CA breaks everything" but makes "too big to fail" worse. There are solutions which address these problems without aggravating them. CAA is one example. But this isn't. I _do_ think we should do the following: * Encourage CAs to volunteer for name constraints, as HARICA did, starting by approaching those CAs who have never issued for .com; * Forcibly name constrain _government_ CAs to their own TLDs. Government CAs are a different breed; slower to update, different audits, no competition to put them out of business. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
