Subject: Re: OCSP RFC and OCSP version 2 ID

From: [email-masked] (Peter Gutmann)
Date: Wed, 16 Jan 2002 15:28:12 +1300 (NZDT)

Santosh Chokhani <[email-masked]> writes:

>I am looking at both the RFC and version 2 ID for OCSP.  Each document
>contains statements that seem contradictory to me.  This relates to the
>meaning of nextUpdate field in the OCSP SingleResponse.  Some places each
>document states that:
>
>"If nextUpdate is not set, the responder is indicating that newer revocation
>information is available all the time"
>
>Other places each document states that:
>
>"Responses where the nextUpdate value is not set are equivalent to a CRL
>with no time for nextUpdate"
>
>Now, this appear contradictory to me since I do not interpret X.509 to imply
>that absence of nextUpdate field in CRL means near real-time CRL generation.
>
>I assume that the above is editorial oversight and the authors of both the RFC
>and ID mean that for OCSP, absence of nextUpdate means newer revocation
>information is available all the time.

There appears to be quite a bit of confusion over these fields among
implementors because the RFC is so vague over how they're handled.  I've seen
responses where nextUpdate isn't set, where it's set to a value later than
thisUpdate, and where it's set to a value equal to thisUpdate (which seems
bogus since it auto-invalidates itself, but I haven't heard any complaints
about this so I guess no-one notices).  Other responders just copy the info
across from the CRL, which leads to funny results if the CRL doesn't contain a
notAfter (== nextUpdate), since the client is supposed to think that new info
is always available even though it's coming from a CRL which may only be
updated once a day (a truth-in-advertising problem).  My solution has been to
ignore the fields and let users decide, which I suspect means they just check
whenever they feel like it, because I doubt anyone's going to try and handle
all the weird special cases which crop up.  I seem to remember something on the
OpenSSL list where someone was grumbling about having to implement variable-
configuration options to handle this as well, so others have run into this
problem too.

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 16 Jan 2002 14:50:25 -0500

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: Santosh Chokhani <[email-masked]>
Date: Wed, 16 Jan 2002 16:45:22 -0500

Ambarish:

It seems that your approach to modify is fine.  It seems to align the
semantics of the nextUpdate field with CRL.

I have no problem with that.  Keeping the other language is guarantying
freshness and it means that the OCSP responder is getting real-time
revocation information from CA.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 4:38 PM
To: 'Santosh Chokhani'
Cc: [email-masked] '
Subject: RE: OCSP RFC and OCSP version 2 ID

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

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: 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,

---

From: Carlisle Adams <[email-masked]>
Date: Thu, 17 Jan 2002 11:18:13 -0500

Hi,

> ----------
> From: 	Ambarish Malpani[SMTP:[email-masked]]
 
Me too.  I get fewer opportunities to follow the PKIX list these days...

> modify the document to reflect this point of view.
 
That's exactly the sort of wording I had in mind, too, when I read Santosh's
e-mail on this.  I'd be happy to see the above text included in the
document.

Carlisle.

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 17 Jan 2002 08:53:05 -0800

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

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; [email-masked] '
> Ambarish,
> 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
> 
> > Architect                                                
> 650.567.5457

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 13:30:35 -0500

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,

Regards,
Ambarish

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 17 Jan 2002 10:56:08 -0800

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
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message----- 
From: Ambarish Malpani [ mailto:[email-masked]
<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, 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Peter Williams [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 14:01:04 -0500

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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 14:08:27 -0500

Upon further reflection, I think thisUpdate DOES take care of it.

 

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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 17 Jan 2002 11:08:21 -0800

Hi Santosh,
    No, what I am suggesting, is that when thisUpdate ~= NOW, is when the
response is
real-time/near real-time.
 
A

 

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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 14:22:38 -0500

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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 14:40:34 -0500

Because, if we use that semantics, and the server does not get nextUpdate
from the CA CRL, what will it do?
 
By the way, since 2459 and son of 2459 require nextUpdate to be present, I
do not have a problem with this interpretation.  It will mean a compliant
OCSP responder can not take CRL from a CA that is not compliant with 2459.
 
I just want the issue resolved and contradiction in the RFC removed.

-----Original Message-----
From: Deacon, Alex [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 2:37 PM
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: 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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: "Deacon, Alex" <[email-masked]>
Date: Thu, 17 Jan 2002 11:37:24 -0800

Alex

 

 

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

 
A

-----Original Message----- 

Hi Denis, 

Regards, 
Ambarish

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 17 Jan 2002 15:26:52 -0500

Ambarish:

I can buy that.  Item 3 is not so cut and dried.  It can imagine when the
server wants to say, do not cache the information and come to me each time
for the latest.  The client may need to know that and service needs a way to
adverstise that.

Again, I am not saying that RFC should address this.  I am just bringing up
the potential need.  Of course, client can do this on its own for any high
value transaction and not cache.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 3:14 PM
To: 'Deacon, Alex'; 'Santosh Chokhani'; [email-masked] '
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

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

Alex

 

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

A

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

> > modify the document to reflect this point of view. 
http://www.valicert.com

---

From: Peter Williams <[email-masked]>
Date: Fri, 18 Jan 2002 09:54:26 -0800

Santosh finally asked a valid and proper question: how is 
revocation-notice freshess information handled by OCSP clients 
(such as a DPV server)

So far, the list's analysis has established that the reliability
of X.509 revocation-notices at use-time is, in part, handled by 
a technical signal, and in another part policy, as enforced by 
clients.

OCSP used certificate-based policy mechanisms
to signal validation-policy. For example

(a) add to the Bridge-CA-style 
assurance policy oid in the relevant CA cert (pertinent to
the OCSP responder) another cert policy oid to signal 
validation-semantics to the cert path processing
module and the PKI application that decides how to use a
chain.

(b) When the OCSP client 
application uses a cert chain to process an EE cert supporting an 
OCSP response signature, the OCSP client UA  get to impose the full 
X.509 cert processing logic: require certain cert policy oids (2: a
Federal assurance level, and an application-specific validation
policy controlling the accuracy of revocation-notices) and qualifiers.

While architecturally correct, the example method described above 
is rarely used in practice. (Why this is so is an interesting 
design question, for another time and place.)

In DPV we get to use protocol-based validation policy signals,
rather than rely on certificate-based mechanisms for
communicating and controlling policy to applications using
revocation-notices.

Id recommend that, in the context of DPV, we not only specify
message formats and handling semantics, but we also specify
one particular validation policy: one that qualifies the policy
of a DPV server using an OCSP server to access revocation-notices, and
be able to assert to the DPV client via a DPV-style 
validation policy "IETF-CRL" that this means the OCSP source 
was equivalent to the DPV server using the current CRL from the 
CA directly.

In this way, we establish in public standards one of the 
important baselines to,  finally, relate the reliability of OCSP 
to CRLs from the PKI-application's perspective. As a DPV server 
is only a simple "remote" path processing 
engine that supports application logic coresident with
the DPV-client, it is fitting to treat the DPV validation policy signal
to a DPV client as a signal to the co-resident PKI application 
indicaating the reliability of the validation infrastructure 
supplying the revocation notices.

Peter.
-----Original Message-----
From: Yuriy Dzambasow
To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani'; [email-masked]
Sent: 1/18/02 6:21 AM
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

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 18 Jan 2002 13:39:12 -0500

Denis Please comments in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, January 18, 2002 12:45 PM
To: Santosh Chokhani
Cc: Ambarish Malpani; [email-masked]
Subject: Re: OCSP RFC and OCSP version 2 ID

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.
> 
> 1.  The absence of nextUpdate means that the client should not cache the
> 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.

[What I am saying is that the OCSP responder does not make advertise the
nextUpdate, either because it does not know or because the field is
meaningless since the response is real-time.  What the client does is, its
problem.  The cache item may not go in the RFC.  It was provided as
background]

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

We do not care why a server "may" do this, we care to understand what that
means for the client.

[What it means to client is that it does not have nextUpdate.  Thus, if the
client needs real-time or reasonably current information, it needs to
contact the responder each time and use thisUpdate to determine the
freshness of the response]
 
> 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.

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:

[If you look at Section 3.2, we need these rules in order to deal with
replay detection.  Please note that producedAt is always > = thisUpdate.
The language for producedAt should be similar to that for thisUpdate.]

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

[I do not see a particular benefit to citing a policy document in a
protocol]

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: Yuriy Dzambasow [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 9:22 AM
> ----- 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
> > thisUpdate=NOW may not prove that since this could be simply
> coincidence.
> A
> > proposed meaning of nextUpdate, the additional capability can be handled
> 
> via

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 21 Jan 2002 08:47:49 -0500

I think nonce is an extension and  we can not force it.

Please note that thisUpdate and producedAt can also be used to detect the
freshness of the response.  After all, with thisUpdate, the OCSP becomes as
current as CRL and producedAt (depending on the responder implementation) is
always as good or better.

Thus, I think there will not be much support for a mandatory nonce.

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]]
Sent: Monday, January 21, 2002 7:08 AM
To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 'Deacon, Alex';
[email-masked]

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.