Subject: RE: RFC 2560 - OCSP - Clarification

From: Peter Sylvester <[email-masked]>
Date: Thu, 31 Aug 2000 14:26:42 +0200 (MET DST)

> 
> the current status of a certificate is very often not so important. when i
> verify a signature that was created using a specific certificate, i want to
> know, if the certificate was vaild, when the signature was created. to
> detemine the time the signature was created, one would ideally use
> timestamps. using timestamps, it is possible to determine the signature
> creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of
> two timestamp (taking time base errors into consideration).
> what i would like to see in OCSP is a request with the following meaning:
> "what was the state of certificate XYZ in the time interval [t1,t2]?"

I do not think that you really want to ask this question, see below.
 
> 
> the answers could be:
> 1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...)
> throughout the time intervall [t1,t2]
> 3) certificate XYZ changed its state from state A (e.g. valid) to state B
> (e.g. suspended) at tx, where t1 <= tx <= t2
> 
> if i get the first answer with 'valid', i can definitely say: "the signature
> it was used for is valid".
> moreover, this request-response supports any history model for certificate.
> by now OCSP assumes that a certificate can never become valid again once it
> became invalid.
Hm, 

If a certificate was 'invalid' (suspended) and if it becomes valid later, then
why would you want to get a 'suspended' status? 

If it becomes definetely revoked, you get a bad answer, 
if the the current status is still 'pending', you get that. 
And for those cases you get a date, so you can compare.

It is assumed that either by using a cut-off date or by external knowledge
you know that for which time frame you get an answer. 

If you want to have more detailed information about the history, you can
also require that the signer, a cosigner, a notary, or whoever you want,
produce an OCSP response near the moment of the signature and add
this to the document, or you other protocols to enable validity checking
of the document. 

I am not talking about the effects of a CA key compromise that might allow
you to create 'good' responses for a non-existing cert, and then you estimate
to be able to fake one in the future.  
 
> of course, implementing this based on CRLs will be hard, but if the server
> has access to the history of the certificates, it should not be a big deal.
> 
> what do you and others think of this requirement for future OCSP
Some general thoughts:

So far, OCSP without extensions has been made in such a way that you can
create a conforming implementation if you have a repository of CRLs.

As far as I remember all requests to give different answers are handled by
the magic 'do it by an extension'. OCSP adds an archive-cut off extension
for example, this seems to me a simple thing to support, knowing the
the history of the CRLs that you have isn't that difficult. 

PS

---

From: "Karl Scheibelhofer" <[email-masked]>
Date: Thu, 31 Aug 2000 15:26:11 +0200

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: RFC 2560 - OCSP - Clarification
>
>
> >

i do not simply want, in fact i must(!) have a answer to this question to
decide whether the signature is valid. for me a certificate status service
it is the most obvious place to get the answer for this question.

> why would you want to get a 'suspended' status?

simply to temporarily take away the rigths that a valid certificate brings
with for a entity. consider a employee gets suspended for any reason, the
company may not want to revoke the certificate before the reason for this
suspension have been verified. and if the company finds out that the reason
is unjustified, it may want to make the certificate valid again. during the
period the employee is suspended, the company may not want him do any
business.

> you know that for which time frame you get an answer.

collecting facts from serveral sources to get an answer is what i want to
avoid. i would like to have a single point where is get a definitive answer
to the question stated above. by now i have to do serveral parts of this
processing at the client side. i think the server side would be the better
place for this.

> this to the document, or you other protocols to enable validity checking

if you sign a lot of documents and always attach all necessary verification
data, you produce a lot of redundant information. this can be avoided and i
think this should be avoided.
nevertheless it works.

> to be able to fake one in the future.

i also do not consider a CA key compromise here.

> create a conforming implementation if you have a repository of CRLs.

yes i know about this requirement for supporting CRLs. but this is a
implementation issue.
for me as a developer of a signature/verification terminal software my
stated question is the one that i need an answer for.

> the history of the CRLs that you have isn't that difficult.

just getting my idea in there in any non-standard extension is not a very
disirable solution. because if i am the only one supporting it, it is not
better than any ad-hoc protocol.
i posted my idea here to hear the opinion of other people that use OCSP.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540