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

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Thu, 13 Nov 2014 12:18:01 -1000

Hello PKIX,

recently I have been asked to implement the "Extended Revoked 
Definition" in our implementation of the OCSP server (OpenCA). However, 
after reviewing RFC 6960 I have serious issues with that, and I would 
like to know what your opinions are about my concerns. Just to be 
precise: I do not want to re-open any work on this topic, but I would 
like to know if my concerns are sensible or if I should add support for it.

In particular, by extending the responsibilities of the OCSP responders 
to provide also information about the issuing status (instead of just 
the revocation information) we might have potential deployment issues - 
that is, for pre-computed responses, it seems difficult to make any 
useful use of the Extender Revoked extension. This also applies for 
other transport protocols that could be defined to make the OCSP 
responses easily accessible (e.g., OCSP over DNS or OCSP over LDAP - not 
currently standardized, but, I think, useful). If there are people who 
deployed support for this, could you please let me know how did you 
managed to make any use of this option ?

Also, I think there are some security considerations. The first one is 
about protecting against certificate enumeration. Originally, the OCSP 
standard was designed in such a way to protect the number of issued 
certificates. Since the request does not need to have the certificate in 
order to build the OCSP request (just the serial number and the issuing 
CA certificate), answering "Good" was seen as a protection against 
certificate enumeration. That is the same reason that pushed almost all 
Internet Certification Authorities to move from an incremental serial 
number to a randomized one few years ago. I have the impression that 
when the new RFC was issue, there was a lot of pressure to fix the issue 
of  compromised CAs that draw the integration of this feature into the 
new RFC (specifically coming from the the Web/Browsers world). To 
address that issue, other venues are also today explored (e.g., DANE, 
Certificate Pinning) that, I think, are more appropriate than OCSP 
(personal opinion). Is certificate enumeration not seen as a possible 
threat anymore ? If so, why CAs not going back to sequential serial 
numbers (easier to verify which certs have been issued since the S/N is 
unique and monotonic).

The second security consideration is about the source of trust for the 
validity information.

Historically, CRLs were the source of revocation information for the 
OCSP. The use of signed data establishes the trust with the CA so that 
nobody can change the revocation status by simply change a configuration 
file (which is not signed by the CA key) or a database entry. The use of 
the CA's Key is required (much simpler to monitor). This also enables 
the secure transfer across different OCSP responder and CAs (i.e., the 
OCSP can safely retrieve the CRLs, verify the signature from the CA and 
provide responses for CAs that are not tightly coupled with). 
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). IF the "white" list is not updated and distributed to the OCSP 
responders as soon as the new certificates are issued, you will not be 
able to use the certificate until that happens (as noted in the security 
considerations). This approach adds, IMHO, a level of complexity that is 
not necessary. From the security considerations:

<<For this service to be effective, certificate-using systems must
    connect to the certificate status service provider.  In the event
    such a connection cannot be obtained, certificate-using systems could
    implement CRL processing logic as a fall-back position.>>

seems to address the point, however it does not mandate for any form of 
authentication to be performed on the source of information. That means, 
according to me, that the security of OCSP responders that use CRLs is 
definitely better that any unspecified "connection to the certificate 
status service provider". Isn't this an under-specification for the 
security considerations in the RFC ? If the source of "white-list" inf

Sorry for the long e-mail, please let me know your point of view (even 
offline).

As it is now, I would not implement the feature as I think it reduces 
the overall security of the OCSP infrastructure.

Cheers,
Max

---

From: Gervase Markham <[email-masked]>
Date: Fri, 14 Nov 2014 15:49:05 +0000

I wasn't involved in writing RFC 6960, but:

On 13/11/14 22:18, Dr. Massimiliano Pala wrote:
> 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.

> about protecting against certificate enumeration. 

Is that a security consideration, or a "protect a CA's business secrets"
consideration? Regardless, CT means CAs in the Web PKI need to disclose
everything anyway. Serial numbers remain random because randomness in
certificate contents is a good "belt and braces" defence against various
types of attack.

> OCSP.

Yep. That's no longer possible, for the reasons you give. An OCSP
responder is more than just a CRL-fragment-responder.

> itself).

Why not just send a copy of the certificate itself? It's signed by the
CA's key, and it is small.

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

Gerv

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 14 Nov 2014 07:14:22 -1000

Hi Gerv,

responses inline...

> On Nov 14, 2014, at 5:49 AM, Gervase Markham <[email-masked]> wrote:
> 
>> In particular, by extending the responsibilities of 

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)

> responder is more than just a CRL-fragment-responder.

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

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

> use your software. (I don't know whether this is a matter of concern for

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