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

[Rob Stradling <[e-mail]>]

On Tuesday 27 July 2010 14:30:56 Yngve N. Pettersen wrote:
<snip>
> Just a clarification: What I was referring to was the
> "CertificateStatus_v2" extension (not the Multiple OCSP method option in
> that extension), which was necessary for a client to be able to signal
> support for both old and new OCSP stapling. The multiple OCSP definition
> would no longer be part of that limite specification.

Sorry Yngve, I missed that subtlety.  I have some more comments...

> This have at least the following benefits:
> 
>    - The relying party only need to parse a single response for each chain

I don't follow you.  If there are multiple certificates in the chain, then the 
relying party will want to verify multiple OCSP Responses, regardless of 
whether those Responses have been "stapled" by the Server (via a TLS 
Extension) or by the OCSP Responder (via an OCSP Response Extension).

I suppose there would be a performance benefit to relying parties when the 
Server doesn't support the existing OCSP "stapling" TLS Extension.  The 
relying party would be able to verify the whole certificate chain just by 
sending 1 OCSP Request to the OCSP Responder, rather than sending a separate 
OCSP Request for each certificate in the chain.  But, hopefully, the vast 
majority of Servers will implement the existing OCSP "stapling" TLS Extension, 
in which case this benefit is insignificant.

>    - No update needed serverside for servers supporting OCSP stapling

That's true.  However, there would be a need to update all the various OCSP 
Responder software.

In contrast, one benefit of the Multiple OCSP TLS Extension approach is that 
none of the various OCSP Responder software would need to be updated.

>    - 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.

Less complex for the Server, but more complex for the Responder.

> 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.

Again, the Responder suffers.  With the existing infrastructure, a Responder 
only sends an OCSP Response for a CA certificate when a relying party has 
asked for it.  But with your OCSP Response Extension idea, the Responder would 
send "embedded" OCSP Responses for CA certificates even in cases where the 
relying party has already got cached copies of those OCSP Responses.

Isn't one of the main goals of OCSP "stapling" to reduce, not increase, the 
processing and traffic loads on the Responders?

> 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).

That would remove "No update needed serverside for servers supporting OCSP 
stapling" from your list of benefits.

If the Servers need to be updated, then why can't they implement the 
"CertificateStatus_v2" TLS extension you originally proposed, including the 
"Multiple OCSP method option in that extension" ?

<snip>
> 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.

If your OCSP Response Extension proposal is accepted, I tend to agree that the 
recursive method would be preferable.

P.S. Nothing I've posted recently to ietf-pkix or ietf-tls has reached the 
list.  I've no idea why.  :-(

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.