On Fri, Sep 02, 2016 at 11:19:11AM +0100, Gervase Markham wrote: > On 31/08/16 20:43, Nick Lamb wrote: > > This suggests the need for some options short of distrust which can > > be deployed instead, but Mozilla does not seem to have any. If in > > fact it already does, this would be a great place to say what they > > are and discuss why they haven't been able to be used in recent > > cases. > > Have you considered what was done for CNNIC? In that case, we distrusted > all certificates issued after a certain time. We used a whitelist for > determining this, but it would be possible to use the notBefore date in > the certificate. A CA could dodge this by backdating, but if the CA were > also committed to putting all its certs in to CT, then the backdating > would be noticeable.
Is the idea here that the incentive for the CA to "behave" is potential future re-inclusion? If we catch 'em doing the dodgy (which, with Google's super-spider powers and submitting everything to CT, is at least *fairly* likely these days) then any hope of their ever being re-included is completely gone? Pulling the root at that future juncture of misissuance might also be more palatable, since presumably the number of valid certs being used in the wild should be reduced. > > 1. Implement "Require SCTs" for problematic CAs. Notify the CA they > > are obliged to CT log all certificates, inform subscribers etc. or > > their subscriber's certificates will suddenly be invalid in Firefox > > from some future date. > > This is not currently possible in Firefox, as Firefox does not have the > ability to check SCTs. We hope to have that ability soon. Even if Firefox was checking SCTs, as another poster said, if practically every site needs to reconfigure themselves to deal with this, we may as well just pull the root. Heck, getting a cert from somewhere else is almost certainly *less* hassle than setting up SCT-embedded OCSP stapling or SCTs in the TLS handshake. As far embedding SCTs in the certs, I thought the plan was to have the problematic CA *not* issue more certs... > > 2. Create "at risk" category for problematic CAs which lasts some > > finite period of time (or a period to be set in each case). Notify > > the CA they are obliged to warn their subscribers of this status or > > leave the Mozilla programme immediately. Publicly announce "at risk" > > status and drive as PR. > > One issue to consider with this option would be that reputational damage > is harder to quantify and control than a technical measure, which might > be said to increase the risk that the action would be disproportionate. Not to mention, where's the incentive for the CA to do this? If pulling the root was a valid sanction, it'd be done. So, if the CA says "we're not doing that" (or, as is more likely, "we'll do it... later", or "yes, we've done it" but we have no way to verify it) what does Mozilla do next? - Matt -- I don't do veggies if I can help it. -- stevo If you could see your colon, you'd be horrified. -- Iain Broadfoot If he could see his colon, he'd be management. -- David Scheidt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
