On Thu, Feb 8, 2018 at 3:14 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 8 Feb 2018 15:50:08 +0000 > Gervase Markham via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > In this case, the certificates are revoked in Firefox via OneCRL and > > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be > > noticed. > > Hi Gerv, > > Independent of this specific case, which I guess is mostly harmless, I > find this worrying. > > Let's assume something like this happens: > * CA xyz, which is trusted by Mozilla and other root stores, issues a > sub-certificate for company SuperShady Inc. Immediately after that > CA xyz asks Mozilla to include it into OneCRL and Google to include > it in CRLsets. > * SuperShady Inc. starts selling certificates. Their offer is that you > can get a certificate for every domain you want, the price depends on > how popular the domain is. If you pay enough you can get a > certificate that's valid for google.com or facebook.com. > * SuperShady Inc. advertises their certificates with the fact that > while they won't be valid in mainstream browsers due to revocation > lists they still work in many situations, i.e. they will be > considered valid by commandline tools or API calls from many > programming languages as they don't include a mechanism like OneCRL. > > I'm aware that this goes into the tricky topic of people consuming the > Mozilla CA root store without implementing the full certificate > validation logic, which is already a problem with deprecated CAs like > the old Symantec roots that are phased out. > But this is much more sever. While we don't expect that the > Symantec roots have been operated with the care we expect from a CA we > also don't have any indication that they're used for outright malicious > purposes. > > Yet I feel what you and others here are implying is that once a subca > is part of OneCRL and revoked they're no longer bound to any standards > at all. > How is this different from CA xyz asks for their root to be removed from Mozilla products and other root stores, but applications and devices use older versions? The simple answer is that those commandline tools and API calls for programming language are responsible for their application security. They always have been. They don't get a free pass now. A root store is as much a product decision as the choice of programming language to write it in. The same argument you're making here is if CA xyz revokes SuperShady Inc's certificate. The same commandline tools and APIs for programming languages don't do revocation checking (often times because their design is such that it's impossible for them to do so, because making network requests is the caller's job or shouldn't be done in the batch processing) We've had the discussion on m.d.s.p. in a variety of ways in the past regarding consumption of the root stores and program decisions. There's even a FAQ about it to cover this question which is periodically raised, as it is now - https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F """Therefore, anyone considering bundling Mozilla's root store with other software needs to be aware of the issues surrounding providing a root store, and committed to making sure that they maintain security for their users by carefully observing Mozilla's actions and taking appropriate steps of their own. On a best-efforts basis, Mozilla maintains a list of the additional things users of our store might need to consider. """ OneCRL is a way that attempts to address impact and risk for Mozilla Firefox users. It is not inherently going to be guaranteed to be appropriate for other use cases - each application vendor needs to evaluate their community of users, the expectations, the stability contracts, the impacts, etc when it decides to handle revocation. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
