RE: OCSP RFC and OCSP version 2 ID

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

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:ambarish@xxxxxxxxxxxx]
Sent: Thursday, January 17, 2002 11:53 AM
To: 'Denis Pinkas'; 'ietf-pkix@xxxxxxx '
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.

---------------------------------------------------------------------
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: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; 'ietf-pkix@xxxxxxx '
> 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.
> 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.
>