[cabfpub] FW: Short lived OCSP signing certificate

Wed Sep 19 00:33:28 MST 2012

I´m agree with Rich about the issuance of any certificate without revocation information, I think this is a must and albeit the short-lived certificates could be interesting, but I see disavantages technically and financially or in the "administration" area.

Technical 

-          In our infrastructure (I don´t know the others) we have set up the duration of the certificates to 4 years, 2 years, 23,45 months J, etc. So, at the time we issue a certificate we know when is going to finish and at the same time the CRL/OCSP "start working" to provide an answer for those who want to check it out. Unless we define a period/duration for the shor lived certificates (24 hours, 7 days, 10 days, ...) that can be implemented by default I can´t issue certifcates one by one depending of what type is and which duration (this is not a butchery, I want one of 2 days, 3 certs of 24 hours, and a couple of 7 days)

-          Regarding the stapling, cached responses, etc. yes, you´re right, but the users can always check the status of the certificate by themselves, well, not "all" the users but the option is there, but the issuance whithout that "option" wouldn´t add more security because you can´t check it.

Administration

-          For every cert I issue I create an invoice (it´s the way we work, sorry) to the customer, so they´ll have one invoice every 2 years if we´re lucky (and you know we issue just a few of them) but with this short lived maybe we have to issue one invoice every day, so after 2 years, we have issued like 730 invoices (even in christmas, easter, etc, L ) and send them to the customer and manage them here and see if they pay all of them, or they forget, etc. it´s a mess.   

o   Yes, you can argue that do not need to do it that way, and send just one invoice with all the certs issued in 1 year, or month, or whatever, but it´s done automatically and that would make an economic impact. I´d need to change my SAP

-          For the BR, and similar to EV, it´s needed to check all the info previously to the issuance so that would generate a big impact in the "validation team" (yes, you can argue that if the info does not change I can use the same but for how long?, is this a solution?)

-          Besides, I need to keep all the info of the certificates issued, so the folder of these kind of certificates can be quite big and again not easy to manage. The "archiving team" will have to check that all the info has been provided in terms of forms, like the request form (I understand that I need a request form every time, so a request form every day? Or every 2 days or 7 days?) and the same for the validation checks, etc.

These are only some arguments that came to my mind but I see a lot of problems in the administrative tasks than in the Technical ones, which by the way, not including the "revocation information" don´t make them more secure albeit they "live" less and this is about security and I think it won´t improve it.

Regards

PS: Like Tom uses to say, this is my opnion, if you don´t like I have others (and if I can explain them in spanish/basque with some "polite" words, much better J )

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Rich Smith
Enviado el: martes, 18 de septiembre de 2012 18:05
Para: 'Mads Egil Henriksveen'; 'CABFPub'
Asunto: Re: [cabfpub] FW: Short lived OCSP signing certificate

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://cabforum.org/pipermail/public/attachments/20120919/9e11cdd3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
Url : http://cabforum.org/pipermail/public/attachments/20120919/9e11cdd3/attachment-0001.png 