[cabfpub] Request for details on CRL Sets
agl at google.com
Mon Aug 26 22:10:28 UTC 2013
On Fri, Aug 16, 2013 at 7:54 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> We think this is an area where transparency would be beneficial. CAs would
> like to understand exactly how they work and how the information is
> gathered, to insure that design assumptions were correct. Are CRLs filtered
> for certain reason codes? Are very large CRLs included?
When it comes to specific details of how CRLSets are implemented, I
don't think it's unreasonable to check the source code . Things do
change and, most of the time, we'll just be checking the source code
anyway to look at the answer. Unlike the metaphor of the IRS telling
you read the tax code; you're tax experts in this case.
However, several of your questions are about the construction of the
CRLSets, for which the source code isn't public anyway. (It wouldn't
be that hard to publish much of it, but I haven't done so.)
There is an internal list of crawled CRLs that we maintain. The CRLs
from that set go to make up the published CRLSet. For size reasons,
the list doesn't include all CRLs - EV CRLs and CRLs with good reason
codes are taken in preference. Several CAs have requested that I keep
their CRLs in confidence so I'm not going to publish the full list,
publicly here. I can let you know which Symantec CRLs are included if
CRLs on the list are fetched infrequently (at most once every few
hours) and verified against the correct signing certificate for that
CRL. (The signing certs are included in the static config.)
Entries in the CRL are filtered by reason code. Only entries that have
no reason code, or one of the following reason codes are included in
the CRLSet: Unspecified, KeyCompromise, CACompromise or AACompromise.
The limit of the CRLSet size is 250KB. Symantec currently has the #1
and #2 tops in the size tables :)
(The number is the number of bytes taken up in the CRLSet by entries
from the given CRL.)
In the event that something causes a CRL to bloat significantly and
pushes the CRLSet over the size limit, I get alerted and will
typically drop the CRL from the list and notify the CA.
The current CRLSet can be fetched and dumped out using the code at
> Note that for end entity certificates, CAs are required to use OCSP but are
> not required to issue CRLs. We need to know how browsers handle end entity
> certificates without CDP pointers. Those certs would not be covered by a CRL
> Set. CAs may wish to have the freedom to stop issuing CRLs due to their size
> and bandwidth costs, but if many CAs decided to do that, it appears that CRL
> Sets would be negative affected.
CRLSets can (and do) include non-public CRLs - i.e. CRLs that are not
pointed to by any certificate but still exist if one knows the URL.
Removing CDPs from certificates would not cause any issues, at least
none that spring to mind.
The primary purpose of CRLSets is to provide a quick way to revoke
specific certificates when that's acutely required. Carrying bulk CRLs
is secondary, although nice. However, only one CA has really taken
advantage of it. If any CA has non-public CRLs, or other ways to try
and take advantage of CRLSets I'd be happy to hear from them.
More information about the Public