Re: [pkix] Deployment Clarifications about RFC6960 - Section 2.2 and 4.4.8

[Massimiliano Pala <[e-mail]>]

Hi Gerv,

responses inline...

> On Nov 14, 2014, at 5:49 AM, Gervase Markham <[e-mail]> wrote:
> 
> I wasn't involved in writing RFC 6960, but:
> 
>> On 13/11/14 22:18, Dr. Massimiliano Pala wrote:
>> In particular, by extending the responsibilities of 
>> currently standardized, but, I think, useful).
> 
> As far as the web is concerned, HTTP (and stapling) is the way to go.
> CRL retrieval over LDAP (for example) is no longer supported by Firefox,
> if it ever was.

OCSPD over LDAP: I do not think it ever was because there is no standard for that! It is an idea that I was playing with. However, directories are HEAVILY a used in corporate environments (and academia) so it would be another good transport for fast and easy access to revocation information.

On the extended revocation support, as you point out, the web is going to have stapling.. and this is mostly for server-side... but what about client side certificates? I do not remember if the stapling also applies to client side (I do not think so), but If it does, I do not think that there are many client-side applications that implement that. So, we are still missing 1/2 of the puzzle here, AFAIK.

(BTW, the extension that enables the new behavior, if I am not missing something here, is useless when using stapling - only with live signing OCSP responder you have the possibility to use it - therefore in practically all deployment of OCSP for the web that I am aware of - I.e. via CDNs or via stapling, the extension is not useful at all)

> 
>> Also, I think there are some security considerations. The first one is
>> about protecting against certificate enumeration.
> 
> Is that a security consideration, or a "protect a CA's business secrets"
> 
> Yep. That's no longer possible, for the reasons you give. An OCSP
> responder is more than just a CRL-fragment-responder.

And this raises a security / performances and synchronization issue - see my points below.

> 
>> Unfortunately there is no standard for a signed "white" list - this
>> would be huge for many CAs. If CRLs are bad for sizes and they usually
>> are 10% of the overall population of certificates, the list of valid
>> certificates is quite huge and should be updated (and synchronized
>> throughout all the OCSP server cloud) each time a new certificate is
>> issued. This would mean that a CA has now to make 2 signatures each time
>> a certificate is issued - one of which over a huge file (the white list
>> itself).
> 
> Why not just send a copy of the certificate itself? It's signed by the
> CA's key, and it is small.

That would be an option. However, it is not that simple. 

Now, instead of just looking up in a relatively small DB (I.e. most of the time less than few hundred thousands entries), when a request is received, the server has to make a first lookup to see if the certificate is in the CRL, if not (the vast majority of times) then a second lookup (in a much larger DB) is needed to find the certificate itself, and then the certificate's signature must now be validated in order to protect against DB pollution (AFAIK, all this work had lot of push because of a compromised DB in a CA - if that is the case, we just made things worse).

As you can see, by adding this extension (that does not add much in terms of security, IMHO) we now have reduced the performances of live responders (where you have better security via NONCES and possibly secure/validated connections) a lot. Therefore, I think that from a design perspective, the consequences of this change are quite extensive and have not been taken into consideration (or, if they have, I would like to know what was the reasoning for ignoring them).

> 
>> As it is now, I would not implement the feature as I think it reduces
>> the overall security of the OCSP infrastructure.
> 
> If your OCSP responder does not implement this feature, it will not be
> possible for any hierarchy which wishes to be CAB Forum BR-compliant to
> use your software. (I don't know whether this is a matter of concern for
> you or not.)

Herb, thanks for the comments - however, so far, as an implementer (and not just an RFC adopter) there is no good reason to implement this extension, but there are many NOT to implement that. In fact,  that would Uber-complicate the software and open new attack vectors (especially when the responder is run by a different organization other than the one that runs the certification services). For example, what if a consortium of CAs wants to setup an OCSP server for all of the participating parties ? How to integrate the services to offer the extended_revocation extension remains un-specified.

Is there anybody who has implemented the feature and actually use it in a high volume environments? What trust compromises did you have to implement (no signature verification? providing answers off a database? Throw money at the problem by building bigger server farms?).

A small note that I think could be worth think about (maybe by the ADs?) is that the more I think about many of the recent RFCs and draft that have been worked on in the security area, the more it seems to me that the protocols are too skewed towards the Web. The reality is that TLS and PKIs are used in many different non-web environments. Maybe we should have more representatives from other environments to guarantee that standards take in consideration those environments too. Or, another option,  would be to explicitly restrict the scope of these standards and leave open the space for defining protocols better suited for non-web environments.

Just my two cents...

But I am still interested to hear some convincing argument about the benefits of the extension.. anybody?

Cheers,
Max