On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I am saying that setting an administrative policy for inclusion in a > root program is not the place to do technical reviews of security > protocols.
Of course it is. It is the only one that has reliably worked in the history of the Web PKI. I would think that would be abundantly evident over the past five years. > And I proceeded to list places that *do* perform such peer > review at the highest level of competency, but had to note that the list > would be too long to enumerate in a stable root program policy. > Except none of them are, as evidenced by what they've turned out. The only place where Mozilla users are considered, en masse, is in Mozilla policy. It is the one and only place Mozilla can ensure its needs are appropriately and adequately reflected. > SDO? Unfamiliar with that TLA. > Standards defining organization. > And why should Mozilla (and every other root program) be consulted to > unanimously preapprove such technical work? This will create a massive > roadblock for progress. I really see no reason to create another FIPS > 140 style bureaucracy of meaningless rule enforcement (not to be > confused with the actual security tests that are also part of FIPS 140 > validation). > This is perhaps the disconnect. It's not meaningless. A significant amount of the progress made in the past five years in the Web PKI has come from one of two things: 1) Mozilla or Google forbidding something 2) Mozilla or Google requiring something The core of your argument seems to be that you don't believe Mozilla can update it's policy in a timely fashion (which this list provides ample counter-evidence to this), or that the Mozilla community should not be consulted about what is appropriate for the Mozilla community (which is, on its face, incorrect). Look, you could easily come up with a dozen examples of improved validation >> methods - but just because they exist doesn't mean keeping the "any other >> method" is good. And, for what it's worth, of those that did shake out of >> the discussions, many of them _were_ insecure at first, and evolved >> through >> community discussion. >> >> > Interestingly, the list of revocation checking methods supported by > Chrome (and proposed to be supported by future Firefox versions) is > essentially _empty_ now. Which is completely insecure. > Not really "interestingly", because it's not a response to the substance of the point, but in fact goes to an unrelated (and technically incorrect) tangent. Rather than engage with you on that derailment, do you agree with the easily-supported (by virtue of the CABF Validation WG's archives) that CAs proposed the use of insecure methods for domain validation, and those were refined in time to be more appropriately secure? That's something easily supported. > Within *this thread* proposed policy language would have banned that. > And neither I, nor any other participant seemed to realize this specific > omission until my post this morning. > Yes, and? You're showing exactly the value of community review - and where it would be better to make a mistake that prevents something benign, rather than allows something dangerous, given the pattern and practice we've seen over the past decades. > However the failure mode for "signing additional CA operational items" >>> would be a lot less risky and a lot less reliant on CA competency. >>> >> >> >> That is demonstrably not true. Just look at the CAs who have had issues >> with their signing ceremonies. Or the signatures they've produced. >> > > Did any of those involve erroneously signing non-certificates of a > wholly inappropriate data type? > I'm not sure I fully understand or appreciate the point you're trying to make, but I feel like you may have misunderstood mine. We know that CAs have had issues with their signing ceremonies (e.g. signing tbsCertificates that they should not have) We know that CAs have had issues with integrating new technologies (e.g. CAA misissuance) We know that CAs have had considerable issues adhering to the relevant standards (e.g. certlint, x509lint, Mozilla Problematic Practices) Signing data is heavily reliant on CA competency, and that's in unfortunately short supply, as the economics of the CA market make it easy to fire all the engineers, while keeping the sales team, and outsourcing the rest. > I am not an AV vendor. > > Technical security systems work best with whitelists wherever possible. > > Human-to-human policy making works best with blacklists wherever > possible. > > Root inclusion policies are human-to-human policies. > Root inclusion policies are the embodiment of technical security systems. While there is a human aspect in determining the trustworthiness for inclusion, it is the technical competency that is the core to that trust. The two are deeply related, and the human aspect of the CA trust business is deeply flawed - as the past decade of issuance shows you. The mitigation for this was, is, and will be technical mitigation for human failures. You want to remove humans from the loop, not depend on them. > Just trying to preserve existing ontologies. Prior to this thread, > failures in OCSP and CRL operations were never classified as > "mis-issuance", because it shares nothing relevant with "mis-issuance". > > For example you cannot "revoke a mis-issued OCSP response" within 24 hours > by adding it to CRLs etc. It's nonsense. > Of course they were! They were and are part of the Baseline Requirements as policy violations (e.g. 'unrevoking' a certificate, a CRL with a certificateSuspension, etc). The ontology you seek to preserve wasn't actually an enshrined policy. If your debate is that the word 'issue' can only apply to certificates, and that OCSP responses are 'signed', as are CRLs, then all you've stated is that there is 'misissuance' and 'missigning', which are technically identical activities, but utilize different verbs. A CA that unrevokes an intermediate has violated the Mozilla Root Certificate Policy. That's always been the case. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
