[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP RFC and OCSP version 2 ID
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" <ambarish@xxxxxxxxxxxx>
To: "'Deacon, Alex'" <alex@xxxxxxxxxxxx>; "'Santosh Chokhani'"
<chokhani@xxxxxxxxxxxx>; <ietf-pkix@xxxxxxx>
Sent: Thursday, January 17, 2002 3:13 PM
Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> 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. ambarish@xxxxxxxxxxxx
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; 'ietf-pkix@xxxxxxx '
> 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:chokhani@xxxxxxxxxxxx]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; 'ietf-pkix@xxxxxxx '
> 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:chokhani@xxxxxxxxxxxx]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; 'ietf-pkix@xxxxxxx '
> 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:chokhani@xxxxxxxxxxxx]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; 'ietf-pkix@xxxxxxx '
> 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:ambarish@xxxxxxxxxxxx]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; 'ietf-pkix@xxxxxxx '
> 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. ambarish@xxxxxxxxxxxx
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
> -----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 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: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.
> 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.
> >
>