[cabfpub] Request for details on CRL Sets

Ryan Sleevi sleevi at google.com
Fri Aug 16 17:29:00 MST 2013


On Fri, Aug 16, 2013 at 4:54 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> This request is directed towards Google and Mozilla, whose browsers
> currently use CRL Sets or are expected to use them in the near future. In a
> discussion among some of the CAs about how CRL Sets worked, it became clear
> that we really don’t know the details, especially with regards to
> exceptions. We know of no formal published specifications.
>
> 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?

I hope you find that these questions have already been answered at
https://www.imperialviolet.org/2012/02/05/crlsets.html

>
> 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.
>
> Google, Mozilla, can you publish detailed specs?

You failed to include Microsoft or Apple in your request - both of
which have mechanisms for leveraging software update channels to
actively distrust certificates. Was this an intentional omission, or
simply an oversight due to misunderstanding the purpose of these
mechanisms?

Mozilla's proposal is not for CRLSets, but to adopt a mechanism akin
to CRLSets. So I cannot comment upon Mozilla's plans or
implementation.

Detailed specs are beneficial for interoperable implementations.
However, as spelled out in the aforementioned post, this is a solution
that is very much tied to the Google Chrome update mechanism. In the
same way that it's not necessary for Mozilla to publish detailed
specifications of their extension or software update mechanisms, or
for Microsoft to publish detailed specifications for their certificate
distrust mechanism or Windows Update mechanisms, I'm not sure there is
particular value in publishing detailed specifications here either.

We remain committed to working with the CA community to see that the
methods employed by Chrome are understood, much in the same way that
Mozilla, Microsoft, and other vendors have worked to do, but a
detailed spec does not necessarily help meet this goal.

Luckily, both Chrome and Firefox are built from open source, and thus
the implementation details you seek are readily available via source -
much the same as all other behaviours related to the treatment of PKIX
certificates, independent of CRLSets. As with all aspects of Chromium,
we always welcome bug reports and patches.

It is important to remember that CRLSets are, strictly speaking, an
improvement over soft-fail validation, as an attacker can always block
such soft revocation failures. As such, in the presence of an active
attacker, soft-fail provides very limited benefits. In this manner,
CRLSets offer a security advantage to end-users, without the
performance penalties inherent in soft-fail.

CRLSets provide a means for actively distrusting intermediates in a
rapid response situation, and, as a secondary benefit, provide a means
for pre-loading revocation information for end-entity certificates
that may represent security threats. Even without end-entity
information, I believe we're in agreement of the unquestionable
positive benefits here of rapid response for intermediate certificates
- and the hopefully infrequent need to deal with such revocation.

Failing to publish CRLs would be detrimental to the goals of providing
actual security to users, but it would not be fatal to the value
proposition of CRLSets - merely detrimental to the efficiency and
reliability of dealing with end-entity certificates.

The first goal - revoking intermediates - may be met through
alternative means, such as those discussed by Mozilla in Item 5 of the
July 30, 2013 CA communications -
https://wiki.mozilla.org/CA:Communications#July_30.2C_2013 . I don't
think it's necessary to discuss the exact details of this, as they're
all improvements over the means previously employed to get reliable
revocation, namely a full software update.

The second goal - revoking end entity certificates - remains a complex
problem for which a variety of solutions that do not suffer the
performance issues of CRLs and OCSP have been proposed. While CRLSets
represent a reasonable, deployable path for this, it does not
represent a complete replacement - merely an improvement over the
status quo. Perhaps the most promising is OCSP stapling (which
provides the equivalent security of 'soft fail'), combined with a CA
policy that mandates a server must staple OCSP responses.

Cheers,
Ryan

>
> -Rick
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>


More information about the Public mailing list