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

["Yngve N. Pettersen" <[e-mail]>]

On Wed, 28 Jul 2010 16:31:37 +0200, Rob Stradling  
<[e-mail]> wrote:

> 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 am a coder, and I am thinking in terms of having only one retrieval  
operation, and then doing a single call from the application to the  
function doing the OCSP verify operation, an operation that in the  
multiple cert chain case will do further OCSP verify operations using the  
response(s) included in the extension, but IMO that still counts as  
handling a single response (compared to downloading and handling multiple  
OCSP responses and/or CRLs directly from the responders).

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

There would definitely be a benefit for the relying party in both cases.

If the server does not implement stapling, then the client would have to  
do a separate request to the responder, and if there was no embedded  
responses it might also have to do CRL lookups. In this scenario the  
embedded responses would cause higher bandwidth usage for the responder,  
since the responses would be larger, but the relying party would only need  
to do one request, reducing overhead.

In the stapling case the client would only have a single response to  
handle, and with the embedded responses not have any need to download  
CRLs, reducing overhead.

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

I suspect that the number TLS server is far larger than the number of OCSP  
responders, and a changeover for the servers would take much longer,  
probably 5+ years (even a high priority patch like the Renego patch still  
looks like it will take 2-3 years, unless something happens to speed it  
up).

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

Not all that much I suspect. Before generation starts for the responses,  
it downloads the OCSP response for the intermediate that signed those  
certifiates, then for each response being generated adds that response as  
an extension in each response. In the non-recursive case it would need to  
download each intermediate OCSP response individually, which shouldn't be  
difficult.

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

If the responder sends the full embedded version in response to relying  
parties, then there might be extra bandwidth costs for the CA. One way to  
handle that would be to have servers ask for the embedded version, but  
that requires server updates. Another way could be for the CA to use  
incentives to the server operator to use stapling, and not send the  
embedded versions for certificates that are not known to use stapling  
(alternatively, it can be done just for high traffic sites).

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

It is, and if all servers and clients use stapling the load on the  
responder will depend on the number of customers, rather than the number  
of visitors aggregated over the customers' sites.

The embedded case may increase the processing cost of generating each  
response a bit, but just copying a prepared response into the buffer, and  
the extra cost when calculating the signature digest probably does not  
increase the cost all that much.

Even if the responses are generated for each request, rather than being  
pre-generated, the additional items would just be copying the response(s)  
(which would be downloaded just every X hours) and digesting that extra  
data.

The significant extra cost might be bandwidth, but that depends on how the  
responder is implemented, and whether or not incentives are used.

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

Yes, unless the different location can be controlled by a preference. But  
see my note about incentives.

You might also decide whether to use the embedded form, or not, based on  
the number of requests for each request. Although that would make for a  
more complex system.

> 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" ?

The goal of this proposal is to avoid updates to servers, if possible.

All clients will have to be updated, but they have a faster pace of  
replacement than servers, anyway.

With this proposal we have two options for how to get more timely  
revocation information to the clients, and we can then see which one makes  
most sense overall.

-- 
Sincerely,
Yngve N. Pettersen

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