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

["Dr. Massimiliano Pala" <[e-mail]>]

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