Subject: OCSP support for historical reference to certificate suspension

From: Michael Myers <[email-masked]>
Date: Thu, 31 Aug 2000 11:33:44 -0700

All,

This is the same dialog I had Denis on the list regarding a requirement for
historical references.  That ultimately led to the Archive Cutoff definition
that appears in RFC 2560.    

The text reads:

   "An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. The date obtained by subtracting this
   retention interval value from the producedAt time in a response is
   defined as the certificate's "archive cutoff" date.

   OCSP-enabled applications would use an OCSP archive cutoff date to
   contribute to a proof that a digital signature was (or was not)
   reliable on the date it was produced even if the certificate needed
   to validate the signature has long since expired.

   . . . 

   To illustrate, if a server is operated with a 7-year retention
   interval policy and status was produced at time t1 then the value for
   ArchiveCutoff in the response would be (t1 - 7 years)."

That is, the historical accuracy of a validation of an expired certificate
related to given digital signature is only reliable up to the archive cutoff
date.  This date is arbitrary.  It could be seven years, thirty years or
whatever local digital signature rules require.  

What is needed, and what Denis originally advocated for, was syntax in the
request that enabled specification of a date field whose semantics were "was
the cert valid at this date?"  However, it is unwise to predicate OCSP
historical references on the presumption of CRL-based suspension mechanisms
given the lack of Internet-scale support of this mechanism.  A
database-centric approach is much more practical.

Given the current work underway regarding 2560bis, I propose to include in
the 2560bis work effort an optional "ValidAt" (or some such) field in the
request syntax to accomodate this requirement.

Comments, anyone?

Mike

> -----Original Message-----
> From: Simon Tardell [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 7:36 AM
> To: 'Ambarish Malpani'
> Cc: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
> [email-masked]
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> 
> Collect me if I'm long, but archive cutoff only indicates whether the
> revocation status of a certificate is "garbage collected" after the
> expiration of the said certificate (or rather, guarantees 
> that it won't be
> until some other point in time). The responder will still 
> only tell you
> about the current status of the certificate. I.e. if the 
> certificate was put
> on hold and subsequently removed from CRL and is still not 
> expired, you will
> not be told.
> 
> Karl wants to wind back time and tell the responder: Use only the
> information you had at this historical point in time, and 
> answer from that.
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> [email-masked], http://www.iD2tech.com
> Securing the Internet economy
> 
> 
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[email-masked]]
> > Sent: den 31 augusti 2000 16:18
> > To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
> > [email-masked]
> > Subject: RE: RFC 2560 - OCSP - Clarification
> > 
> > 
> > 
> > Hi Karl,
> >      The Archive-Cutoff extension is one that is defined in the
> > OCSP spec - it would not be a non-standard extension just made up
> > by you.
> > 
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
> http://www.valicert.com
> > Mountain View, CA 94043
> > 
> > 
> > > -----Original Message-----
> > > From: Karl Scheibelhofer [mailto:[email-masked]]
> > > Sent: Thursday, August 31, 2000 6:26 AM
> > > To: Peter Sylvester; [email-masked]; [email-masked]
> > > Subject: RE: RFC 2560 - OCSP - Clarification
> > > 
> > > 
> > > 
> > > 
> > > > -----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
> > > >
> > > >
> > > > >
> > > > > 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,
> > > > 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?
> > > 
> > > 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.
> > > 
> > > > 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
> > > 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.
> > > 
> > > > 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.
> > > 
> > > 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
> > > 
> > 
>