[cabfpub] Request for details on CRL Sets

[Rick Andrews]

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

Ryan, I had already looked at that page, and not only does it *not* answer my questions, I don't know if it's official Google documentation. AFAIK, this is Adam's personal blog. And it says, for example, "we're currently planning on disabling online revocation checks in a future version of Chrome". Also, there is no detail at all on reason code filtering.

I don't think it's unreasonable to ask for official Google documentation that is served from a google.com web page and includes detail like when a certain feature was introduced, exactly how the feature works, and when any changes are made to the feature.

> 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?

It was intentional, because as I said, only Google and Mozilla have said that they do or will use CRL sets or something like it.

I may follow-up with requests to the other browsers for details on their blacklist mechanisms, but I thought I would start small. I didn't expect pushback!

...
> 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.

I can't disagree more. Note that I'm not asking for details of Chrome's update mechanism. I would like details on how Google collects the data from our CRLs that Google pushes out via the update mechanism. 

> 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.

It may or it may not, but I can't tell if it helps or not until you've published it.

> 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.

Again, I disagree. Only a fraction of the PKI community has enough know-how to dive into code and figure out how it works. It's possible, but it's very expensive and potentially misleading. If I may make an analogy, it feels to me like the IRS telling me to read the tax code to figure out how much I owe. 
 
> 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.

I agree with you here, but that doesn't change my request: I'd like to know exactly how it works. I think it's a reasonable request.

-Rick