Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit : > My criticism: > > (a) > I don't like it that the amount of CRLs will be a subset of all CRLs. > What about all the revoked certificates that aren't included in the list? > > With a dynamic mechanism like OCSP (and in the future OCSP stapling) you > don't have to make a selection.
OCSPStapling doesn't work. You can have only one OCSP response by the standard, while you need at least 2. It was defined that way in 2006 (RFC4366), and confirmed in 2011 (RFC6066). > (b) > I don't like it that the CRLs are supposed to be filtered. How can you > ensure that no important revocation will be missed? It's the job of CAs to provide good enough CRLs. If they can't do this, can they really be trusted? [...] > In my opinion we should rather get our homework done: finally get > on-demand downloading of CRLs done (which depends on more helping hands > to get the bugs in libPKIX fixed), get OCSP stapling deployed and find a > way to require strict revocation checking. The latter will involve > creating user interface that allows users to override a temporary OCSP > outage, e.g. when using a captive portal in order to get the payment done. That should have been done a long time ago, the revocation checking problem is not new, it only has become more visible with Comodo and DigiNotar events. Mozilla is still the only one to send OCSP requests as POST, bypassing standard cache mechanisms, preventing the use of CDNs to avoid SPOF. I don't share all Google ideas (for example the green bar for "DNSSEC" certificates), but this one could be promising, let's see. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
