Subject: Lightweight OCSP Profile for high volume environments...

From: "Deacon, Alex" <[email-masked]>
Date: Tue, 2 Dec 2003 11:42:34 -0800

All,

On a related topic, we (Ryan and myself) have recently submitted an
informational internet-draft which describes a lightweight profile of OCSP
(RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
signing and secure messaging. (i.e. environments where pre-produced and
distributed responses may be desirable).  

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
.txt

Alex

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Dec 2003 20:10:54 -0500

Alex:

I think I understand what you are trying to say, but I fail to see much
added utility of nextPublish over nextUpdate.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [email-masked]
Subject: Lightweight OCSP Profile for high volume environments...

All,

Alex

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Tue, 2 Dec 2003 19:14:57 -0800

Santosh -

One of the things we have been discussing is how a client can retrieve data from the responder before it expressly needed without abusing the responder.

This is needed so that clients do not need to interrupt their transaction to wait for a OCSP response, this is particularly interesting in the TLSEXT case where the webserver server is likely to maintain a cache of responses it provides to clients as part of the TLS negotiation.

Typically nextUpdate (plus or minus some) is used by clients as the expiration of the response, the responder also typically will have some overlap in the responses they produce, in the case of a pre-production responder there is also going to be a delay between when the responses were produced, and when they become generally available.

Without this value clients will simply guess at a value which may not be accurate for that particular responder resulting in un-necessary network traffic to the responder and delays for the client.

Ryan

From: Santosh Chokhani
Sent: Tue 12/2/2003 5:10 PM
To: [email-masked]
Subject: RE: Lightweight OCSP Profile for high volume environments...

Alex:

-----Original Message-----

All,

Alex

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Dec 2003 07:38:31 -0500

Ryan:  Thanks.  I understand.  But, given that network delays and clock
synchronization issues are still there, you still need the same delta.
Since nextUpdate was designed to serve this purpose, the response generator
should put nextUpdate by which the response will be available.
 
However, I do know if some PKI implementations where nextUpdate for CRL is
well ahead (say a week) and actual issuance is daily or every two days.  In
those scenarios, I can see nextUpdate being a week ahead, but nextPublish
could be day or two days ahead.

-----Original Message-----
From: Ryan M. Hurst [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Lightweight OCSP Profile for high volume environments...

Santosh -
 
One of the things we have been discussing is how a client can retrieve data
from the responder before it expressly needed without abusing the responder.
 
This is needed so that clients do not need to interrupt their transaction to
wait for a OCSP response, this is particularly interesting in the TLSEXT
case where the webserver server is likely to maintain a cache of responses
it provides to clients as part of the TLS negotiation. 
 
Typically nextUpdate (plus or minus some) is used by clients as the
expiration of the response, the responder also typically will have some
overlap in the responses they produce, in the case of a pre-production
responder there is also going to be a delay between when the responses were
produced, and when they become generally available.
 
Without this value clients will simply guess at a value which may not be
accurate for that particular responder resulting in un-necessary network
traffic to the responder and delays for the client.
 
Ryan

  _____  

From: Santosh Chokhani

Alex:

-----Original Message-----

All,

Alex

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Dec 2003 15:23:35 +0100

Santosh,

> Since nextUpdate was designed to serve this purpose, the response 
> generator should put nextUpdate by which the response will be available.
>  
> However, I do know if some PKI implementations where nextUpdate for CRL 
> is well ahead (say a week) and actual issuance is daily or every two 
> days. 

  ... and in such a case in case of an attack, these daily CRLs will
      not be seen. :-(

Denis

> In those scenarios, I can see nextUpdate being a week ahead, but 
> nextPublish could be day or two days ahead.
> 
>     One of the things we have been discussing is how a client can
>     retrieve data from the responder before it expressly needed without
>     abusing the responder.
>      
>     This is needed so that clients do not need to interrupt their
>     transaction to wait for a OCSP response, this is particularly
>     interesting in the TLSEXT case where the webserver server is likely
>     to maintain a cache of responses it provides to clients as part of
>     the TLS negotiation. 
>      
>     expiration of the response, the responder also typically will have
>     some overlap in the responses they produce, in the case of a
>     pre-production responder there is also going to be a delay between
>     when the responses were produced, and when they become generally
>     available.
>      
>     Without this value clients will simply guess at a value which may
>     not be accurate for that particular responder resulting in
>     un-necessary network traffic to the responder and delays for the client.
>      
>     Ryan
> 
>     ------------------------------------------------------------------------
>     From: Santosh Chokhani

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Dec 2003 11:01:09 -0500

Denis:

I agree and the organizations do recognize that the CRL replay attack window
is determined by nextUpdate and not the issuance frequency.

The point I was making to Ryan is that in nextPublish can be useful when the
revocation information is published more frequently than implied by the
nextUpdate.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2003 9:24 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Lightweight OCSP Profile for high volume environments...

Santosh,

Denis

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Wed, 3 Dec 2003 08:27:46 -0800

Santosh - Yes, clients will still have to have some padding to accommodate for time skew but that's not what this is about. 

Most clients out there treat nextUpdate as a expiration, I know that's not what the RFC stated but that is what the common interpretation of this value ended up as being.

Given this interpretation, new data is needed on the client no later than nextUpdate; typically when issuers produce revocation information there is a overlap of validity (I have seen values in the range of hours, and some in days). 

NextPublish value allows the responder to communicate this window explicitly to the client, thus allowing the client to make intelligent decisions on when it can pre-fetching of this data.

Ryan

From: Santosh Chokhani
Sent: Wed 12/3/2003 4:38 AM
To: [email-masked]
Subject: RE: Lightweight OCSP Profile for high volume environments...

Ryan:  Thanks.  I understand.  But, given that network delays and clock synchronization issues are still there, you still need the same delta.  Since nextUpdate was designed to serve this purpose, the response generator should put nextUpdate by which the response will be available.

However, I do know if some PKI implementations where nextUpdate for CRL is well ahead (say a week) and actual issuance is daily or every two days.  In those scenarios, I can see nextUpdate being a week ahead, but nextPublish could be day or two days ahead.
-----Original Message-----
From: Ryan M. Hurst [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Lightweight OCSP Profile for high volume environments...

Santosh -

Ryan

From: Santosh Chokhani

Alex:

-----Original Message-----

All,

Alex

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Wed, 3 Dec 2003 08:29:30 -0800

Thats a good point Denis, but it is a very common practice on that has its purpose and its costs.

Ryan

From: Denis Pinkas
Sent: Wed 12/3/2003 6:23 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Lightweight OCSP Profile for high volume environments...

Santosh,

Denis