On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy < [email protected]> wrote: > > Note that I also had a second, related, point: The possibility that such > a new piece of infrastructure was, for other reasons, not endorsed by > Mozilla, but of great interest to one of the other root programs (not > all of which are browser vendors). > > Conversely consider the possibility that some other root programs had a > similarly restrictive policy and refused to support the introduction of > CT PreCertificates. This could have stopped a useful improvement that > Mozilla seems to like. > > The Golden rule would then imply that Mozilla should not reserve to > itself a power it would not want other root programs to have.
As much as I love an application of the Golden Rule as the next person, I think it again misunderstands the realities on the ground in the Web PKI, and puts an ideal ahead of the practical security implications. Root programs do sometimes disagree. For example, Microsoft reserves the right to revoke certificates it disagrees with. That right means that other browser programs cannot effectively use CRLs or OCSP for revocation, as to do so is to recognize Microsoft's ability to (negatively) affect their users. They have means of working out those disagreements. You're positioning the hypothetical as if it's inflexible - but the reality is, each root program exists to first and foremost best reflect the needs of its userbase. For Microsoft, they've determined that's best accomplished by giving themselves unilateral veto power over the CAs they trust. For Mozilla, recognizing its global mission, it tries to operate openly and best serving the ecosystem. The scenario you remark as undesirable - the blocking of precertificates - is, in fact, a desirable and appropriate outcome. As Nick has noted, these efforts do not spring forth like Athena, fully grown and robust, but iteratively develop through the community process - leaving ample time for Mozilla to update and respond. This, too, has ample evidence of it happening - see the discussions related to CAA, or the validation methods employed by ACME. The idealized view of SDOs - that they are infallible organizations or represent some neutral arbitration - is perhaps misguided. For example, it's trivial to publish an I-D within the IETF as a draft, and it's not unreasonable to have an absolutely terrible technology assigned an RFC (for example, an informational submission documenting an existing, but insecure, technology). As Nick mentions, the reality - and far more common occurrence - is someone being clever and a half and doing it with good intentions, but bad security. And those decisions - and that flexibility - create significantly more risk for the overall ecosystem. I suspect we will continue to disagree on this point, so I doubtful can offer more meaningful arguments to sway you, and certainly would not appeal to authority. I would simply note that the scenarios you raise as hypotheticals do not and have not played out as you suggest, and if the overall goal of this discussion is to ensure the security of Mozilla users, then the contents, provenance, and correctness of what is signed plays an inescapable part of that security, and the suggested flexibility is inimical to that security. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
