On Tue, March 24, 2015 11:26 am, Kai Engert wrote: > Thoughts? I don't believe this is reasonable/responsible.
For example, is it your intent to prevent Let's Encrypt from becoming cross-certified? That's the effect of this proposal. For example, is your intent to prevent Google from running its own intermediate for its properties? That's the effect of this proposal. If it is, I think you're mistaken. If it is not, then I think that can demonstrate why the proposal is broken. The current Mozilla Policy sets forth sensible guidelines for how to deal with and manage this situation. It, along with the Baseline Requirements, requires both Point-in-Time Readiness Assessments and Period-of-Time Audits for such intermediates; a PITRA before, a POT after 60 and before 90 days. This is no different than Mozilla's requirements for root inclusions. The fundamental difference between a sub-CA such as Let's Encrypt or Google Internet Authority G2 and a Root CA is that the CP/CPS has not yet been publicly reviewed. However, Mozilla updated the program requirements in v2.1 to require disclosure. The work of Kathleen to further streamline such disclosures (via Salesforce) represents a further accumulation of machine-readable data for such discussions and eventual public review. The cross-certifying CA certainly bears responsibility for those that they have certified, a necessary tradeoff of circumventing the public review. However, we must consider such subordinate failures "as if" it was the root had done it, and carefully evaluate the circumstances surrounding it. Your proposal fails to do this, and in short only recognizes "Technically Constrained" sub-CAs as valid. I think that is mistaken, for all the reasons that have been discussed repeatedly during such conversations on technical constraints. Name constraints are simply insufficient here, nor is it fair to assume that the failings of one CA are representative of the ecosystem. Hopefully you will be able to incorporate this feedback, as well as the past three years' worth of discussion surrounding this, to find a proposal that doesn't throw the baby out with the bathwater. If this is intended to be a response to CNNIC, I think the policies are and have been clear on this. I also think extreme care is needed before proposing blanket zero-tolerance policies. It's no accident that no program spells those out - it's a recognition of complexities. Even the few places in the Baseline Requirements that spell out hard actions - such as revocation periods - have and do cause real and painful service disruptions, and need revamping. If you're not sure what I'm referring to, [1] provides further context. Cheers, Ryan [1] https://cabforum.org/pipermail/public/2015-March/005288.html _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
