Subject: RE: OCSP RFC and OCSP version 2 ID

From: Santosh Chokhani <[email-masked]>
Date: Fri, 18 Jan 2002 11:52:11 -0500

All:

Last might Ambarish and I had a discussion on the OCSP RFC.  We agreed that
the following modifications need to be made.  Unless Ambarish has some new
concerns based on further reflection, here are the proposed changes.  Please
note that the changes to Section 3.2 have not been discussed with the list,
but I have had them on mind ever since I started analyzing the RFC this
week.  I am sure Ambarish will polish this language.

1.  The absence of nextUpdate means that the client should not cache the
response.  The server may do this either because real-time response is
available all the time or the server itself does not have advise (e.g.,
absence of nextUpdate in CRL) from the CA as to when the newer revocation
information will be available.

2.  The following additional rules should be added in Section 3.2 for the
OCSP client to validate the response.

	a.  productedAt should be reasonably close to current time.
	b.  If the request has a nonce extension, the response must have the
nonce extension with the same value as the request.

-----Original Message-----
From: Yuriy Dzambasow [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:22 AM
To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
[email-masked]
Subject: 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" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
<[email-masked]>; <[email-masked]>
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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 10:31 AM
> To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:53 AM
> To: 'Denis Pinkas'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 8:50 AM
> > To: Ambarish Malpani
> > Cc: 'Santosh Chokhani'; [email-masked] '
> > 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.
> > [email-masked]
> > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Wednesday, January 16, 2002 11:50 AM
> > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > Cc: [email-masked] '
> > 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:[email-masked]]
> > Sent: Wednesday, January 16, 2002 2:41 PM
> > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > Cc: [email-masked] '
> > 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: [email-masked]
> > 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.
> >
>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Jan 2002 18:44:47 +0100

Santosh,

Before leaving my office for nearly a week ...

> All:
> 
> Last might Ambarish and I had a discussion on the OCSP RFC.  We agreed
> that the following modifications need to be made.  Unless Ambarish has
> some new concerns based on further reflection, here are the proposed
> changes.  Please note that the changes to Section 3.2 have not been
> discussed with the list, but I have had them on mind ever since I started
> analyzing the RFC this week.  I am sure Ambarish will polish this
> language.
> 
> response.  

I find it somewhat surprising to see that now we speak of "caching the
response" which is local mater (a client may have no cache at all, so in
that case what is the interpretation ?) and has nothing to do with the
original topic which was how a client shall interpret the response when
nextUpdate is missing.

> The server may do this either because real-time response is

We do not care why a server "may" do this, we care to understand what that
means for the client.
 
>         a.  productedAt should be reasonably close to current time.

What does this mean ? a few seconds ? or a few minutes ? or a few hours ? 
This is uncheckable by a client. Why should we add now this requirement ?

We are now too far from the original proposal made by Ambarish. 
Let is come back to it:

I would also add :

"Note: the Certificate Practice Statement and the Certificate Disclosure
Statement may provide more information about when newer status information
information will be available." 

Regards,

Denis

Note: Do not conclude that silence from me, means an agreement, since, 
as indicated at the top of this e-mail, I will not be in my office most of
next week.

>         b.  If the request has a nonce extension, the response must have
> the nonce extension with the same value as the request.
>

---

From: "Florian Oelmaier" <[email-masked]>
Date: Mon, 21 Jan 2002 13:07:57 +0100

Hello Santosh,

I would like to add some comments to your suggestion b)

> the nonce extension with the same value as the request.

Although I appreciate this change as it improves the security of the
protocol, I have a point that I want you to see clearly before making this
change.

As the client most probably knows nothing about the Validation-System behind
a PKI (except the IP of the OCSP-Responder, he has to contact) it is
advisable for the client to always include a nonce into his request
("well-behaving client"). With "well-behaving clients" and the proposed
change of the RfC we will face problems with these scenarios:

Scenario 1: Setup of a Responder that pre-produces answers as specified in
2.5 of RfC 2560.

Scenario 2: Setup of a PKI that uses HTTP-Caching as given for example in
A.1.1 of RfC 2560.

Scenario 3: Some PKIs use a Root-Responder architecture with various other
responders relaying to this root responder and caching his answer for a
certain period of time. [Although I disregard such an architecture, it is
used today]

These problems may lead to clients not using nonce per default. If a client
does not use a nonce, it is vulnerable to replay-attacks.

Today an OCSP-Responder can decide if he wants to expose himself to
replay-attacks by generating answers without nonces. That means if a
responder generates only ONE response without nonce it is vulnerable. On the
other hand, if an OCSP-responder includes a nonce in every response ever
generated in his lifetime, regardless of a nonce in the request, it is NOT
vulnerable to replay-attacks (at least not to "well-behaving clients").

Therefore I would suggest the following change to clarify the RfC instead of
the proposed change:

"Every client MUST include a nonce into his request. If a nonce is included
in the response, the client MUST match it to the nonce of the request.
Although imposing a security problem, a client MAY trust OCSP-responses
without nonce."

and

"To prevent replay-attaks an OCSP-responder SHOULD include a nonce in every
response."

Rationale:
- Responders can choose between security and functionality
- Clients can detect Responders that chose functionality

--
Dipl.Inf. Florian Oelmaier
syTrust S.A.