On 04/12/2015 15:58, Kurt Roeckx wrote:
On 2015-12-04 15:21, Jakob Bohm wrote:
On 04/12/2015 11:19, Kurt Roeckx wrote:
On 2015-12-04 02:55, Jakob Bohm wrote:
How huge and unwieldy are CRLs really, especially if letting the
computer (NSS/Firefox) do the updating?
Individual CRLs are in the range of a few kB to a few MB. For the CA
that issues the subscriber certificates they have a maximum validity of
10 days but should be updated at least every 7 days.
The problem is that you want to check that CRLs before you send anything
to that site, so either you need to download that CRL during the
handshake, delaying the whole thing, of you would need to download all
the CRLs beforehand and update them regularly.
If you want to download them before you connect, you have a problem that
you don't know them all. You only know about the root CAs, not the
intermediate ones. But you do cache the intermediates that you've seen.
You know the ones for all the certificates you have during validation,
because each certificate lists all the applicable URLs directly. Root
CA certs only list the (optional) CRL whose sole job is to self-revoke
the root itself in worst case scenarios. This CRL may or may not be the
same URL as the CRL that is used to revoke directly issued certificates.
It should be a different CRL. A CRL is only about a specific CA
certificate.
The point is, that the two (one) CRLs are both for certificates issued
by that self-signed root CA.
Downloading for all the intermediates would be in the order of several
GB a week that you need to download.
As for timing, there is the bootstrap problem of slowing down the first
connection needing a specific CRL (whose URL may not, in general, be
known in advance), but subsequent connections to certificates pointing
to that URL can use a cached CRL, which is preemptively updated at the
first few "update by" times until N such downloads have been done
without any reuse of that CRL. Thus for a typical user surfing mostly
sites signed by the biggest 3-4 CAs plus 1 or 2 regional CAs, the
weekly update would be limited to those (and only to those subCAs
actually referenced).
I currently have 197 non-root CAs in my browsers cache.
But how many of those were accessed /recently/ and how big are their
CRLs. And how does this compare to your regular weekly network usage,
since I suspect a close correlation between the general level of user
Internet activity and the number of subCAs involved in any given month.
However this is also why I wrote at length about how ensuring that all
mainstream/common browsers accept the more "recent" CRL format version
will allow CAs to set up bandwidth-saving delta CRL schemes for
certificates issued after this becomes a reality (remember that CRLs
are referenced by the certificates they can revoke, not the subCA that
signed those certificates).
This general availability of v2+ CRL format compatibility applies
regardless if those specific browsers use CRL download by default or
not, just like the slow adaptation of SHA-2 in Microsoft browsers and
e-mail clients held back the SHA-2 transition for at least a decade
(and is still holding it back for code signing certificates because
Microsoft officially refuses to provide this update for some of its
OSes that software developers still need to support.)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
