I am generally in favour of this plan - I think it's the right way to go. I am not sure we will ever get to hard-fail for plain OCSP, but I am very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote: > There's one major open issue highlighted in the wiki page. We're > planning to adopt a centralized revocation list model for CA > certificates, which we're calling OneCRL. (Conceptually similar to > Chrome's CRLsets.) In addition to covering CA certifcates, we're > also considering covering some end-entity (EE) certificates with > OneCRL too. But there are some drawbacks to this approach, so it's > not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. I think we should _not_ try and add EE certs (beyond high-profile misissuances) to OneCRL. Here are my reasons, some of which are already noted in the wiki page: * The number of certificates involved means that either the data set is of large size (bad for download and disk performance) or we use a Bloom filter or equivalent which has a false positive rate. This would be such that if a given cert was a false positive, it would be a false positive for every user all the time, until the unrelated revoked cert it was false-positived to fell out of the filter, e.g. by expiring. This means that if Fred owns fred.com and Joe owns joe.com, and joe.com's cert happens to be a Bloom match for a revoked cert, joe.com will have worse performance than fred.com (because every Firefox user will end up doing a hard-fail live OCSP lookup) in a way which is not obvious to Joe. This random aspect to the performance of the solution is not good. * The Bloom filter part is extra engineering which is not needed for the intermediate-only version. Even if the data is transmitted together, OneCRL effectively becomes TwoCRLs, one for intermediates and one for EEs, which work differently. We need to trade off this extra engineering requirement against the priority of the many other things we'd like to be doing. * If we put the EE CRLs of all publicly-trusted CAs into OneCRL, we have a significant information management issue for all the changing data. If we don't, we have to make decisions about who is in and who is out. Whatever we decide and however, the people who end up out suffer a performance (and therefore market) disadvantage for their certs. We are effectively playing favourites. I.e. we could be open and transparent, but it's impossible to be neutral. * If a CA has managed to persuade us to include their CRL in OneCRL, they have no incentive to encourage their users to deploy must-staple or short-lived, because revocation already works fine. That has a number of negative effects, including that there will be less pressure for greater ecosystem support for these technologies. Non publicly-trusted CAs can _only_ use these solutions (they can't be in OneCRL) so they need to work and be well supported. So I am of the opinion that must-staple OCSP and short-lived certs together (plus OneCRL for malicious misissuance) should be our solution for EE cert revocation. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
