Subject: RE: OCSP RFC and OCSP version 2 ID

From: Ambarish Malpani <[email-masked]>
Date: Thu, 17 Jan 2002 12:13:32 -0800

Here is how I see it:

There are 3 potential questions:
1. How current is your information (on which you based this response)
2. How long can/should I keep/cache/rely on this information.
3. How current will your information be if I ask you in the future.

1. is answered by thisUpdate
2. is answered by nextUpdate (where a client can still decide to
	ignore the nextUpdate field the next time it wants to know
	the status of this certificate)
3. is not dealt with by the RFC. I am not sure we need to deal with
	it. The only case that I can think of it being used, is where
	a client can go to multiple responders and is trying to figure
	out which one it should normally use (like they do with DNS).
	I don't think people are close to dealing with that level of
	complexity with OCSP.

Hope this helps clarify the questions.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Deacon, Alex [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 11:37 AM
To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

OK...you guys have lost me now.  What was wrong with not including the
nextUpdate field to specify that the server is providing real time info and
that the client should ask the server each time it needs the current status?
If a responder is providing real time status info, it can (or will) never
know when newer status info will be available as it is impossible to know
when a certificate will be revoked/suspended in advance. 
 
Alex
 
-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.
-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

Upon further reflection, I think thisUpdate DOES take care of it.
-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).
-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

Santosh, why doesn't thisUpdate meet that need?
 
A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

I agree with what Ambarish and Carlisle are saying. 
I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.
-----Original Message----- 
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 

Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 
So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 
Does this meet your needs? 
Regards, 
Ambarish 
--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com 
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [email-masked] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
>

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Fri, 18 Jan 2002 09:21:59 -0500

Hi Ambarish,

Thank you for clarifying this.  I agree with your three potential questions
and your three responses.  Regarding item 3, I believe this should be
addressed through policy and practices, and not controlled through OCSP.

Yuriy

----- Original Message -----
From: "Ambarish Malpani" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
<[email-masked]>; <[email-masked]>
Sent: Thursday, January 17, 2002 3:13 PM
Subject: RE: OCSP RFC and OCSP version 2 ID