* snip - since only OneCRL is relevant to Mozilla users with respect to intermediate certs* >> OneCRL is intended to reduce the exposure of Mozilla's browser to the second >> category of problems, by burning a CRL for intermediates into the software >> itself, so that it will function even offline. But the reality is that CAs >> have not been as forthcoming as they should have with revocation information >> and OneCRL today can't function without either better co-operation on >> revocation by CAs or the exact type of disclosure that we're discussing here. - Then those CAs are in violation of the Mozilla policy and should be treated accordingly. This seems like a *worse* infraction of the policy that failing to disclose an intermediate that is no longer trusted.
Consider a Firefox installed in July 2015 on a laptop which has deliberately been given no Internet access, but it does connect to a handful of systems over perhaps a dial-up or dedicated network. This Firefox thinks the Disney CA is good, it thinks the Verisign Class 3 Public Primary Certification Authority is good. It has no way to find out otherwise, except by being updated to a newer Firefox. Do the legal disclaimers from public CAs say this is the user's problem? Yes they do. Does that mean Mozilla should wave it away as unimportant? That is much less clear. - Same thing as I mentioned. If they haven't updated the browser, how do they know which roots are no longer trusted? I suppose the real difference is one of control. Mozilla can enforce a policy to disclose revoked intermediates but can't force a disclosure of roots that are not part of the Mozilla program (as they are out of scope). _______________________________________________ -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Nick Lamb Sent: Tuesday, June 21, 2016 10:56 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Intermediate certificate disclosure deadline in 2 weeks On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen wrote: > If all paths from a trusted root to a given intermediate are revoked > or expired, then I don't think it "directly or transitively chain[s] > to a certificate included in Mozilla’s CA Certificate Program". It > would be no different than a private CA which isn't part of the WebPKI > graph. It is actually different, but whether each case is different in an _important_ way is a matter for Mozilla to decide. For the expiry case, relying parties may not implement expiry or may not have good local time information. A client which doesn't have a local clock or can't rely on it may not know that an intermediate has expired and still trust it. This is a _risk_ but it's a distinct risk from just accepting certificates which are signed by some untrusted entity and the two shouldn't be muddled. For the revocation case relying parties may not have revocation information. There can be a variety of reasons for this, at one end of the scale they or the CA might be actively under attack, preventing OCSP or CRL downloads. But also the client software might have actively chosen not to implement the revocation mechanism used (e.g. CRLs are often unwieldy, if a CRL is the only revocation offered a client might choose to just not check) and at the far end of the scale the system may be off-line (or at least not connected to the public Internet) and thus unable to perform any revocation checks in real time anyway. OCSP Stapling doesn't buy you much here for non-leaf certificates without multi-stapling, which I believe isn't implemented yet in NSS. And even when we have that, we're years away from OCSP Stapling becoming widespread enough for browsers to realistically reject TLS certificates when there's no stapled OCSP info and either no OCSP servers are listed or they are down. OneCRL is intended to reduce the exposure of Mozilla's browser to the second category of problems, by burning a CRL for intermediates into the software itself, so that it will function even offline. But the reality is that CAs have not been as forthcoming as they should have with revocation information and OneCRL today can't function without either better co-operation on revocation by CAs or the exact type of disclosure that we're discussing here. Consider a Firefox installed in July 2015 on a laptop which has deliberately been given no Internet access, but it does connect to a handful of systems over perhaps a dial-up or dedicated network. This Firefox thinks the Disney CA is good, it thinks the Verisign Class 3 Public Primary Certification Authority is good. It has no way to find out otherwise, except by being updated to a newer Firefox. Do the legal disclaimers from public CAs say this is the user's problem? Yes they do. Does that mean Mozilla should wave it away as unimportant? That is much less clear. Eventually, after we've got past the low bar of CAs actually disclosing all these strange unconstrained subCAs out there I would like to see CAs agree that _even after_ they seek removal of one of their roots they will take responsibility for its continued compliant operation (or safe dormancy) for a period, say 18 months, because in reality clients like Firefox will keep trusting it for some time and so will subsidiary users of the NSS trust store like the various Linux distributions. But that's a subject for another thread. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
