[cabfpub] FW: Short lived OCSP signing certificate

Tue Sep 18 16:05:14 UTC 2012

I am still opposed to issuance of any certificate without revocation
information.  Yes, the BRs allow a signed OCSP response to be good for 10
days.  My understanding for the reasoning behind that is that it is
extremely time consuming to resign hundreds of thousands of "Good" OCSP
responses for all of the valid certificates which a CA may have issued and
some large CAs require nearly that whole time to cycle their responses.  It
does not mean that the CA is going to wait 10 days to publish a "Revoked"
response if they revoke the certificate even minutes after signing an OCSP
"Good" response.  I can't speak for other CAs, but at Comodo, that "Revoked"
OCSP response replaces the previous "Good" response almost immediately no
matter how much time is theoretically left on the "Good" response.  I
suspect that other CAs behave in a similar fashion.  The disconnect here
seems to be that the relying parties take that 10 day lifespan to mean that
they can leave off checking to 10 day intervals and that is faulty
reasoning.  IMO, that 10 day timeframe SHOULD NOT be used in caching OCSP
responses in browsers, nor should it be used in stapling.  Browsers and
servers using stapling do not have to resign hundreds of thousands of
responses, they just have to retrieve responses periodically.  As such, IMO,
they should be doing that at least every 24 hours, not every 10 days.  If
that is the case then revocation information is still useful and SHOULD
remain mandatory.  Moreover, I don't see why this is even an area of
contention.  There is absolutely no reason that a short-lived certificate
REQUIRES the absence of revocation information.  The only reason I can see
is that some parties don't want to be held to account for not properly
checking the revocation status, so if the information is not there they're
off the hook.  I fail to see how that makes anyone more secure.

Regards,

Rich

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Mads Egil Henriksveen
Sent: Monday, September 17, 2012 9:40 AM
To: CABFPub
Subject: [cabfpub] FW: Short lived OCSP signing certificate

Hi

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. 

Regards

Mads 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120918/78f8bee1/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120918/78f8bee1/attachment-0004.bin>