[cabfpub] FW: Short lived OCSP signing certificate

Mads Egil Henriksveen Mads.Henriksveen at buypass.no
Mon Sep 17 13:40:27 UTC 2012


This summer there was a discussion regarding short lived certificates. I didn't find any conclusion on the topic, but apparently there was some disagreement between the participants regarding the usability of short lived Subscriber certificates. However, I do think we already have implicitly introduced the concept of short lived certificates related to OCSP signing certificates, but this has been included in the discussions so far.

For the purpose of analyzing and understanding the usability of short lived Subscriber certificates as an introduction, I use three simplified models describing how an application validates a SSL-certificate received from a web server:

A: Standard OCSP
In this model the application receives the SSL-certificate from the web server and must check the revocation status by using the issuing CA's OCSP service.
The revocation status received in the OCSP-response is time limited (up to 10 days according to BR) and the application should ensure that it always have a un-expired (valid) revocation status.

I assume that the different browsers handle this in some way, although I guess this vary from browser to browser.

B: OCSP-stapling
In this model the web server is responsible for returning the revocation status as an OCSP-response bundled with the SSL-certificate.
The application receives a time limited revocation status from the web server and thus the responsibility for ensuring that a valid revocation status is available, is transferred from the application to the web server. The web server gets a "fresh" time limited revocation status by using the issuing CA's OCSP service similar to A above. This is a more efficient model than A since the traffic towards the CA's OCSP service is dramatically reduced.

However, the application is expected to deal with the time limited revocation status in a proper and secure way (whatever that may be) also in this model. Again, I assume that this is (or will be) handled by the browsers when OCSP stapling is used.

C: Short lived certificates
In this model the web server returns a short lived SSL-certificate (let's assume max 10 days) without the revocation status.
The web server must renew the SSL certificate frequently using another service from the issuing CA. However, this step is similar to getting a "fresh" time limited revocation status as used in B above. Therefore, the protocol between the parties (application, web server and CA) is basically similar to model B.

The application could deal with short lived SSL-certificates in a standard way, i.e. discard expired certificates. However, I assume that browsers to not support short lived Subscriber certificates properly at the moment (?).

To summarize; I find model B and C conceptually equal and don't really understand why model C is less proper and/or secure than model B. Of course, this simplified models do not take all aspects into consideration. But seen from this model at a conceptual level, I do not find any important differences between model B and C.

And this leads me to the main topic: Short lived OCSP signing certificates.

If a CA is using a delegated OCSP responder, BR mandates the usage of id-pkix-ocsp-nocheck in the OCSP signing certificates and RFC 2560 recommends (?) a CA to use a very short lifetime in this case. With this in mind, the concept of short lived certificates is already present, although not as Subscriber certificates but  as OCSP Signing certificates, in the current infrastructure.

Therefore, it could be interesting to understand how the models above are affected by introducing short lived OCSP signing certificates. And are short lived OCSP signing certificates comparable to short lived Subscriber certificates with respect to their lifetime? How should we think when defining a lifetime of a short lived OCSP signing certificate compared to the lifetime of a revocation status? Should they be similar, e.g. 10 days? And should OCSP signing certificates issued from a Root CA have a similar lifetime as certificates issued from a Subordinate CA?

For model A and B, the process is much more complex if the CA uses a delegated OCSP responder to sign OCSP responses. How do the applications deals with such short lived certificates? Will the OCSP response be discarded if the OCSP signing certificate has expired?

The bottom line is that the introduction of short lived OCSP signing certificates complicates the current infrastructure and I think the issues raised for short lived Subscriber certificates must be raised also for short lived OCSP Signing certificates.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120917/f969558a/attachment-0003.html>

More information about the Public mailing list