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

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 27 Jul 2010 12:35:56 +0200

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) <[email-masked]> 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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 27 Jul 2010 15:30:56 +0200

On Tue, 27 Jul 2010 14:29:21 +0200, Rob Stradling  
<[email-masked]> wrote:

> On Tuesday 27 July 2010 11:35:56 Yngve Nysaeter Pettersen wrote:
>> Hello all,
>>
> Hi Yngve.  That's an interesting idea, but (from my viewpoint as an OCSP
> Responder implementer) I'm not convinced that we should do it.
>
> You ended by suggesting that the Multiple OCSP TLS Extension should  
> still be
> standardized and implemented widely (in clients and servers that support  
> OCSP

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.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Adam Langley <[email-masked]>
Date: Wed, 28 Jul 2010 10:53:47 -0400

> can be fixed in another way, by adding an OCSP extension instead.

I would welcome not having to change TLS to support multiple OCSP responses.

However, with TLS changes, we can deploy without any action on the
part of the OCSP responders. That makes it a possibility. If we are
beholden to updating the responders then I fear that it'll never
happen.

AGL

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 28 Jul 2010 16:03:44 -0500

Adam Langley wrote:
> > 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.
> 
> However, with TLS changes, we can deploy without any action on
> the part of the OCSP responders. That makes it a possibility. If we
> are beholden to updating the responders then I fear that it'll never
> happen.

Plus, it is a privacy issue. If you rely on the CAs to provide this
extension in their OCSP responses, then any CAs that want OCSP traffic (for
user tracking) can just omit the OCSP extension. The multiple OCSP method
lets the server improve the user's privacy without any cooperation from the
CAs involved.

(Most TLS clients issue their OCSP requests before they've
authenticated the server's Certificate and (lack of) CertificateStatus
messages, so while a CA wouldn't be able to force clients to make the OCSP
requests, a MiTM can still force them to do so. This could be prevented
by moving the CertificateStatus and CertificateRequest before the
ServerKeyExchange, and making the ServerKeyExchange signature work like the
CertificateVerify signature, hashing all the prior handshake messages. This
is something that should be considered for extensions like Snap Start that
modify the structure of the handshake, and for the next versions of TLS).

Regards,
Brian

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 30 Jul 2010 10:06:35 +0200

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

> On Tuesday 27 July 2010 14:30:56 Yngve N. Pettersen wrote:
> <snip>
> Sorry Yngve, I missed that subtlety.  I have some more comments...
>
> 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.

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

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

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

---

From: Rob Stradling <[email-masked]>
Date: Tue, 27 Jul 2010 13:29:21 +0100

You ended by suggesting that the Multiple OCSP TLS Extension should still be 
standardized and implemented widely (in clients and servers that support OCSP 
Stapling).  If this happens, then surely it would render your newly proposed 
OCSP Response Extension redundant?

IMHO, implementing a temporary solution with drawbacks (larger responses and 
increased traffic load) doesn't seem like the best way forward.

If the OCSP Response Extension were implemented widely, it might have a 
negative effect on the chances of the OCSP TLS Extension becoming widely 
adopted.
(Consider the ongoing Subject->CN versus SAN->dNSName situation for encoding 
domain names in X.509 certificates for use with the SSL/TLS protocols.  The 
"proper" solution, SAN->dNSName, has been standardized for years.  However, 
the "temporary" solution, Subject->CN, is still widely used and refuses to die 
despite the fact that it is inferior and has been deprecated for a long time).

You say that "the OCSP response generator will have easier access to the 
required OCSP response(s) to be embedded".
For some certificate chains, yes, the same OCSP Responder is authoritative for 
all certificates in the chain.  But this is not a requirement, and it is 
certainly not always the case.
Some OCSP Responders would need to act as OCSP Clients in order to obtain OCSP 
Responses from other Responders which it would then put into your proposed 
OCSP Response Extension.  This is development effort for OCSP Responder 
implementers that would not be needed to support the Multiple OCSP TLS 
Extension.  (Also, note that servers which already support "single" OCSP 
Stapling are already able to act as OCSP Clients).

I think we should just concentrate efforts on the "proper" solution (i.e. the 
Multiple OCSP TLS Extension), in order to increase the likelihood that we'll 
end up where we ultimately want to be.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Rob Stradling <[email-masked]>
Date: Wed, 28 Jul 2010 15:31:37 +0100

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

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

> 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>
> 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: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
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.