Subject: OCSP concept question

From: "Haaino Beljaars" <[email-masked]>
Date: Sun, 4 Aug 2002 15:48:05 +0200

Hi,

Hopefully somebody can help me with the follwoing questions and remarks:

I send a signed message to person A, person A checks the status of my certificate on time T by an OCSP request, and the status of my certificate is 'good' according to the OCSP response. At time T+1 my certificate is revoked. Person A checks my message again at time T+2.

Question: what does the OCSP responder give back as status at T+2 ?

* If the OCSP responder gives back 'revoked' at time T+2, then that is correct at that moment in time, but it is wrong when you look at the time(T) when the message was signed, because the message was signed when the certificate status was still good.

* If the OCSP responder gives back 'good': this indicates that an OCSP has as a 'history' function. As far as I can read this is not the case in the OCSP RFC.

If person A check the message against a CRL it would indicate at time T+2 that the certificate was good at the moment of signing, this is because a CRL contains time and date when a certificate was revoked, but an OCSP response does not contian that information.

According to this 'analysis' I get different answers concerning the status of a certificate when I concult a CRL or OCSP?

Why doesn't an OCSP response contain date and time when a certificate was revoked? 

And why doesn't an OCSP response contain a signed time? How can I check that the time the OCSP responder gives back is correct?

Best regards,
Haaino

---

From: [email-masked]
Date: Tue, 6 Aug 2002 17:49:58 +0200

Howdy,

I'm definitely not an expert, however, I've had thoughts about this in the past. Disregarding 
internet-drafts  here is what I think.

As far as I realize, OCSP is a mechanism to check validity for a set of certificates in real time, 
i.e.  to answer the question(s), "Is this set of certificates valid NOW, HOW long, and if not 
since WHEN, and possibly WHY?"  CRLs are used to determine whether a certificate was 
valid at a particular time in the past, and when can we expect an update on its validity?

(insert ideal certificate usage here)

The previous paragraph says little, but means a lot when we have to interprete what it says.  
Endless hours of discussion could arise from the paragraph, yet no conclusions will be 
reached, since the RFCs (2459 and 2560) do not dictate.

As for conclusions,  IMO, the OCSP client should 'save' each ocsp response it receives, as 
this is the 'proof' that the cert was valid when it was used.  By save I mean the ocsp response 
should be persistent.  Naturally, who knows what a lawyer would make of such a packet, still, 
it is the best we can do.

Please correct me!

-rob
[email-masked]

---

From: "Olle Mulmo" <[email-masked]>
Date: Wed, 7 Aug 2002 11:26:53 +0200

There are weird cases as well...

Consider a scenario where a certificate is revoked with reason "onHold" for
a period of time, and later it gets reinstated. If both these operations
happen within a single CRL interval, you will never find out that this event
occured if you rely on CRLs. OTOH, using OCSP you would find out about it.

How should a verifier act in this case? Refuse or accept the signature? Put
the verification step on hold until the cert is either cleared from
suspicion or revoked "for real"?

This is, as Rob points out, a topic that can be discussed for hours. And I
don't think this list can provide a "correct" answer.

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: den 6 augusti 2002 17:50
To: Haaino Beljaars
Cc: [email-masked]
Subject: Re: OCSP concept question

Howdy,

I'm definitely not an expert, however, I've had thoughts about this in the
past. Disregarding
internet-drafts  here is what I think.

As far as I realize, OCSP is a mechanism to check validity for a set of
certificates in real time,
i.e.  to answer the question(s), "Is this set of certificates valid NOW, HOW
long, and if not
since WHEN, and possibly WHY?"  CRLs are used to determine whether a
certificate was
valid at a particular time in the past, and when can we expect an update on
its validity?

The previous paragraph says little, but means a lot when we have to
interprete what it says.
Endless hours of discussion could arise from the paragraph, yet no
conclusions will be
reached, since the RFCs (2459 and 2560) do not dictate.

As for conclusions,  IMO, the OCSP client should 'save' each ocsp response
it receives, as
this is the 'proof' that the cert was valid when it was used.  By save I
mean the ocsp response
should be persistent.  Naturally, who knows what a lawyer would make of such
a packet, still,
it is the best we can do.

Please correct me!

-rob
[email-masked]

On 4 Aug 2002 at 15:48, Haaino Beljaars wrote:

> I send a signed message to person A, person A checks the status of my
certificate on time T by an OCSP request, and the status of my certificate
is 'good' according to the OCSP response. At time T+1 my certificate is
revoked. Person A checks my message again at time T+2.
> * If the OCSP responder gives back 'revoked' at time T+2, then that is
correct at that moment in time, but it is wrong when you look at the time(T)
when the message was signed, because the message was signed when the
certificate status was still good.
>
> * If the OCSP responder gives back 'good': this indicates that an OCSP has
as a 'history' function. As far as I can read this is not the case in the
OCSP RFC.
>
> If person A check the message against a CRL it would indicate at time T+2
that the certificate was good at the moment of signing, this is because a
CRL contains time and date when a certificate was revoked, but an OCSP
response does not contian that information.
>
> According to this 'analysis' I get different answers concerning the status
of a certificate when I concult a CRL or OCSP?
> And why doesn't an OCSP response contain a signed time? How can I check
that the time the OCSP responder gives back is correct?

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 07 Aug 2002 16:17:17 +0200

> response does not contian that information.

The OCSP response does contain that information, and A can know the 
certificate was revoked after the signature date.

But it can be only the case if A can really trust the time at which the 
data has been signed, ie if the signature has been timestamped or if A 
has a private trusted record of the time it received the data.
In the general case, A would better check the signature as soon as it 
receives the data, and save the answer if it says the certificat is 
valid for later use/proof.

Thomas Beckmann wrote ;

>Having in mind, that an OCSP responder does in general nothing else but
>checking a CRL and forwarding the requested information I cannot see a
>difference between the usage of CRLs and OCSP but the neccessity of retrieve
>actual CRLs.
>  
>
There's two different way of using OCSP.

Either the OCSP responder only has access to a CRL, and in that case the 
OCSP responder is only a proxy to avoid downloading the whole CRL before 
checking.
Or the OCSP responder has direct access to the database of the CA and 
can get information that is fresher that any CRL.

In the second cas, the difference is clear.
But even in the first case, the fact that client don't have to download 
the whole CRL means that in the case of large size CA with very large 
CRL, you can afford generating them much more often, and have fresher 
data that if the client must use directly the CRL to access the information.

>suspicion or revoked "for real"?
A verifier should know it's the policy of this CA that it can put 
certificate on hold and decide what course of action that is adequate 
for him.

The motivation for revocation should indicate that the certificate is 
only "on hold" and can be used by the verifier to decide it's action.

Outside of a use where the way the verifier checks the signature is 
perfectly controled, ie certificate used only to sign transactions where 
there's a clear  agreement on that between the parties, or "intranet" 
use, it's therefore not a good idea for a CA to put certificates on hold.

> From: [email-masked]
> it receives, as this is the 'proof' that the cert was valid when it 
> was used.

It really needs to save the response to proove on what data it took it's 
decision.

It should beware of putting in a cache the revoked status of a 
certificate if it's not able to tell if it was just "on hold".