On Wed, Jul 12, 2017 at 10:40 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 2017-07-12 16:12, Ryan Sleevi wrote: > >> I don't know if this currently happens, but I would like to see all CA >>> certificates that are in OneCRL but are not revoked to be added to the >>> root >>> store as distrusted too. >>> >>> >> Why? I can share reasons why it might not be desirable, but rather than >> start out negatively, I was hoping you could expand upon the reasons for >> including. >> > > My understanding is that certdata.txt is what is the trust of the root > store is, and that OneCRL is mostly a browser only thing to get revocation > information, but is also (ab)used to distrust something. > > The certdata.txt currently does explicitly list CA certificates that > shouldn't be trusted. > > As far as I know external user of the trust information currently only use > certdata.txt. So only adding it to OneCRL will not reach all the users of > the trust store. > > It could be that maybe the combination is what should be used, but as far > as I know it's not documented as such and I doubt it gets used much outside > Mozilla products. You're correct that OneCRL is specific to Firefox. OneCRL has the (highly desirable) properties of being able to be rapidly updated, much like CRLSets. In times of compatibility issues, it's possible to 'un'revoke a certificate - as has been necessary, in the past, due to high-profile revocations causing various path building issues. As a concrete example, both Symantec and Comodo had revocations which - while, on a pure technical level, were entirely correct - the processing of these revocations caused issues for clients as diverse as Apple macOS, Microsoft Windows, and, perhaps unsurprisingly, Google Chrome. The risk in moving these to certdata.txt (which is consumed by a wide variety of clients - and in particular, those not using the current version of Mozilla NSS as Mozilla Firefox) is generally that carried out by https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F . That is, it is patently unwise (and, at times, unsafe) to consume the Mozilla Root CA Store without using and validating certificates using the same code as Mozilla Firefox. I know this dismays some members, but that's the reality due to the complexity of chain and path building. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
