[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OCSP concept question


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

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.

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.

Olle Mulmo a dit :

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

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

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.

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