[cabfpub] FW: FW: Short lived OCSP signing certificate

Mads Egil Henriksveen Mads.Henriksveen at buypass.no
Tue Sep 25 15:32:12 UTC 2012


I got the reply below from Peter Breur last week. Unfortunately, it took some time before I realized that this message probably did not go the full list, only to me. I think he has some interesting comments so I am therefore distributing this message to the list. 


-----Original Message-----
From: Breur, Peter [mailto:Peter.Breur at ordina.nl] 
Sent: 17. september 2012 19:17
To: Mads Egil Henriksveen; public at cabforum.org
Subject: RE: [cabfpub] FW: Short lived OCSP signing certificate

Hi Mads,

Noticing your post on short lived OCSP signing certificates, I felt the urge to react.
Especially because this is currently a very hot topic in the governmental PKI in The Netherlands
(PKIoverheid). Please note that, although I work closely with two PKIoverheid CSPs, and a
number of parties within PKIoverheid share my views, the reactions below are my own.

To start, I fully agree with your bottom-line statement, that
>> the introduction of short lived OCSP signing certificates complicates the current infrastructure.

Even more so, I think that the introduction of OCSP support in itself complicates the current

I do not, however, agree with the point of view that short lived certificates (for OCSP responders
or anything else) would be difficult to be validated by clients like web browsers. Such clients just should
do what they must do: discard / distrust every certificate that has a validity.notAfter which is earlier
than the current time.

Complications are more likely to occur on the CA/CSP side. In that light, it really does not matter
whether model A, B, or C is chosen. Any of the models puts much extra strain on a CA's key.
This is because each of these models is based on something that must be signed by the CA key,
but at the same time is short lived, whether is an OCSP responder certificate, an SSL server certificate,
or an OCSP response itself. My argumentation for this statement is:

Model A (Standard OCSP):
Puts extra strain on a CA key, because it either has to sign (many) short lived OCSP responses itself,
or it has to frequently renew a short lived OCSP responder certificate (i.e. resign the authorized
responder's signing key).

Model B (OCSP-stapling):
Also puts extra strain on the CA key for the same reasons as model A. The only difference is that
in this model, the web servers, instead of the web browsers, are the OCSP service's clients.
Indeed, the gain from this model is the decreased number of clients of the CSP's OCSP service.
In itself however, this model does not decrease the number of OCSP-related signatures that are
needed per time interval.

Model C (short lived end-entity certificates, e.g. SSL server certificates):
Again this puts extra strain on the CA key. Only now for signing multitudes of end-entity certificates.

To make things worse, the BR soon requires everybody to support OCSP throughout their entire
CA hierarchy, even Root CA's MUST provide an OCSP service regarding the certificates they
have issued to their subordinate CA's.

Especially on CA levels that high, the chance of the CA being offline is very large. So either all
must be made online (a CSP's worst nightmare) or the concept of "short lived" becomes a joke
on those levels.

In conclusion, I think we need a mechanism that is not dependent on something short lived to
be signed (frequently) by a CA, while at the same time obtaining the speed-advantage that OCSP
promises as well as give CSP's the opportunity to maintain their levels of security.

Within the boundaries the current RFCs (RFC5280 and RFC2560) allow, I feel the BR should:
1. Allow the continued use of CRLs-only on high-level (especially offline) CAs
2. Allow an OCSP responder certificate to contain a CDP that points to an indirect CRL that
    is maintained (signed) by a CA that is higher in the hierarchy than the CA that issued the
    OCSP responder certificate.

In my opinion, this would not put much stress on CSPs, while still providing speedy and secure
certification services.

Note: CRLs maintained by high level CAs tend to be very small. Many such CRLs are even empty,
making them not much bigger than an average OCSP response.

Kind regards,



In response to:

Van: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] Namens Mads Egil Henriksveen
Verzonden: maandag 17 september 2012 15:40
Aan: CABFPub
Onderwerp: [cabfpub] FW: Short lived OCSP signing certificate


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.



Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. .

Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de afzender te waarschuwen en dit bericht met eventuele bijlagen direct te verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid voor schade die voortvloeit uit de inhoud en/of de verzending van dit bericht.

This e-mail and any attachments are confidential and are solely intended for the addressee. If you are not the intended recipient, please notify the sender and delete and/or destroy this message and any attachments immediately. It is prohibited to copy, to distribute, to disclose or to use this e-mail and any attachments in any other way. Ordina N.V. and/or its group companies do not accept any responsibility nor liability for any damage resulting from the content of and/or the transmission of this message.

More information about the Public mailing list