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.
(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?
(c)
What about mobile browsers, what about people with expensive mobile data
plans, or when roaming?
Won't the set of CRLs be too big for download?
Even if they use diffs, what about people who use their mobile browser
only once or twice a week, and will keep the data connection off during
the remainder of the time?
Will there be a full set of diffs for the past days still be available
to recreate the latest set of signed CRLs, or will browsers end up
re-downloading the full set of CRLs on each of those infrequent occassions?
But we will have to see numbers in order to judge whether this point is
valid criticism.
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.
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
