Re: OCSP RFC and OCSP version 2 ID

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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