RE: RFC 2560 - OCSP - Clarification
2000-08-31 23:27:23 GMT
Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit).
Is this not an ability that we should formalize and add to appropriate protocols like OCSP?
From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer <at> iaik.at]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; MMyers <at> verisign.com; ietf-pkix <at> imc.org
Subject: RE: RFC 2560 - OCSP - Clarification
> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester <at> EdelWeb.fr]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: MMyers <at> verisign.com; ietf-pkix <at> imc.org; Karl.Scheibelhofer <at> iaik.at
> Subject: RE: RFC 2560 - OCSP - Clarification
> > 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.
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.
> > the answers could be:
> > 1) the state of certificate XYZ was A (e.g. valid, suspended,
> > 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
> > by now OCSP assumes that a certificate can never become valid
> again once it
> > became invalid.
> If a certificate was 'invalid' (suspended) and if it becomes
> valid later, then
> 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
> 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.
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.
> 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.
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.
> 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.
i also do not consider a CA key compromise here.
> > 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.
yes i know about this requirement for supporting CRLs. but this is a
for me as a developer of a signature/verification terminal software my
stated question is the one that i need an answer for.
> 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.
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.
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer <at> iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540