[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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. 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.
>