RE: OCSP concept question

["Olle Mulmo" <mulmo@xxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of rpaar@xxxxxxxxx
Sent: den 6 augusti 2002 17:50
To: Haaino Beljaars
Cc: ietf-pkix@xxxxxxx
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?

(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
rpaar@xxxxxxxxx


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

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