Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

["Yngve Nysaeter Pettersen" <[e-mail]>]

Hello all,

Based on the ongoing PKIX discussion about an update of OCSP, I (finally)  
realized the the problem my multiple-ocsp TLS extension is designed to fix  
can be fixed in another way, by adding an OCSP extension instead.

This new OCSP response extension would contain the full OCSP response for  
the intermediate CA certificate used to sign the certificate whose OCSP  
response is being requests.

This have at least the following benefits:

   - The relying party only need to parse a single response for each chain

   - No update needed serverside for servers supporting OCSP stapling

   - Implementation of response generation/forwarding will be less complex,  
since the OCSP response generator will have easier access to the required  
OCSP response(s) to be embedded.

Drawbacks:

   - Larger responses, but not any less than the multiple OCSP extension  
would entail.

   - If used in the normal response (direct to client), this will increase  
traffic load for the OCSP responder in the same fashion as what direct  
client retrieval of intermediate CA OCSP would cause, only more so. (That  
is what the TLS extension was intended to prevent) Avoiding this would  
require updates to server so that they request a different OCSP response  
(which might also be needed to head off the expiration delay problem I  
mentioned earlier).

   - Implementation of relying party OCSP processing will be more complex.

At present I am a little uncertain about how OCSP responses for multiple  
intermediates should be handled: As a list of OCSP responses in the  
containing request, or as recursive list (the OCSP response for the  
signing CA contain the OCSP response for its issuer, and so on).

The recursive method might make for easier processing in the client, as  
well as easier generation of the responses, so I am presently a little  
more in favor of this method, than the list sequence.


As far as the TLS Extension is concerned, if the OCSP extension is used  
instead, the extension is no longer needed immediately, but the  
functionality will be needed if/when a new revocation system is developed,  
so it should IMO be considered for inclusion in the next update of TLS  
extensions.

Comments?

On Sun, 07 Mar 2010 19:54:19 +0100, Yngve N. Pettersen (Developer Opera  
Software ASA) <[e-mail]> wrote:

> Hello all,
>
> I have posted a updated version of draft-pettersen-tls-ext-multiple-ocsp.
>
> Main changes:
>
>    - Allow zero length responses, in case the server does not have a  
> response for a certificate in the middle of the chain
>    - Added an open issue regarding handling of bad OCSP responses, such  
> as expired ones.
>
>
> <http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-01.txt >
>
> Diff:  
> <http://tools.ietf.org/rfcdiff?url1=draft-pettersen-tls-ext-multiple-ocsp-00&difftype=--chbars&submit=Go%21&url2=draft-pettersen-tls-ext-multiple-ocsp-01
>>
>
> A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-01.txt has  
> been successfuly submitted by Yngve Pettersen and posted to the IETF  
> repository.
>
> Filename:	 draft-pettersen-tls-ext-multiple-ocsp
> Revision:	 01
> Title:		 Adding Multiple TLS Certificate Status Extension requests
> Creation_date:	 2010-03-07
> WG ID:		 Independent Submission
> Number_of_pages: 10
>
> Abstract:
> This document introduces a replacement of the TLS Certificate Status
> Extension to allow clients to specify and support multiple
> certificate status methods.  Also being introduced is a new OCSP
> based method that servers can use to provide status information not
> just about the server's own certificate, but also the status of
> intermediate certificates in the chain.
>
>
>


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************