RE: OCSP RFC and OCSP version 2 ID

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

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

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.                                  ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@xxxxxxxxxxxx]
Sent: Wednesday, January 16, 2002 11:50 AM
To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
Cc: 'ietf-pkix@xxxxxxx '
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:peterw@xxxxxxxxxxxx] 
Sent: Wednesday, January 16, 2002 2:41 PM 
To: 'Denis Pinkas '; 'Santosh Chokhani ' 
Cc: 'ietf-pkix@xxxxxxx ' 
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: ietf-pkix@xxxxxxx 
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.