On Wed, Jul 12, 2017 at 12:12:13PM -0400, Ryan Sleevi wrote: > > Consider, for example, a client that does not support path discovery > (which, for example, includes most actively-deployed OpenSSL versions). If > one were to extract certdata.txt into trust and distrust records, with the > algorithm that OpenSSL uses, this would actively break connections to a > number of sites, as it would encounter the distrusted certificates and > cease path building. Mozilla Firefox, on the other hand, uses mozilla::pkix > and implements a robust path discovery mechanism - the presence of a > distrust record will have it 'unwind' on path discovery and continue trying > alternative paths. > > One can see this having played out in other situations in the past as well > - such as Red Hat's decision to (temporarily) ship 1024-bit roots that were > removed from the Mozilla Root CA store, due to their need to support > OpenSSL clients that could not build alternative paths to the (included) > 2048-bit roots. > > In this sense, by keeping them separated - into certdata.txt and OneCRL - > Mozilla is able to ensure certdata.txt is more usable by these clients. > Including them in certdata.txt, while certainly more complete and > comprehensive, would conversely mean more clients would break when > consuming certdata.txt - or, if Mozilla were to try to maintain > certdata.txt as an 'interoperable source of truth', would prevent the > necessary changes to ensure users are safe. > > Further, consider that while the use of OCSP or CRLs, and in particular, > hard fail, is unsuitable for a client such as Mozilla Firefox, other > products may have different requirements for both performance and > availability. For example, for a mutually authenticating batch processing > system, the additional latency and/or unreliability imposed by these > revocation checking methods is not as significant to the overall product > flow, and thus offers a better alternative than relying on either OneCRL or > certdata.txt updates. > > Because the situation varies by client - and, again, I want to stress that > a "Web PKI" client that wishes to remain interoperable with 'the browsers' > truly needs to be using the same code as 'the browsers' (and this is true > across all major browser platforms) - keeping it distinct best serves the > needs of various consumers, and allows the few distrust records included to > be ones that minimize the large-scale compatibility impact that might > otherwise be introduced.
So I think what you're saying is that adding it to certdata.txt might result in it breaking for for non-browsers while it might keep working for browsers because they behave better, and so you prefer adding it to OneCRL. I'm interested in having OpenSSL behave more like the browsers, and so maybe some of the points you're making might not apply in the future anymore. You could argue that it's a bug in the other implementations that they can't deal with it, and that you should not restrict what is in certdata.txt to what all consumers of it can handle. Kurt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
