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.
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.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
