Subject: RE: OCSP support for historical reference to certificate suspension

From: "Karl Scheibelhofer" <[email-masked]>
Date: Fri, 1 Sep 2000 08:44:39 +0200

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 8:34 PM
> To: [email-masked]
> Subject: OCSP support for historical reference to certificate suspension
>
>
> 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.

normally, it will not be possible to determine the signature creation time
exactly. the best i can reliable determine is, that the signature was
created in a time intervall (between two time stamps). so if you plan to
include a time field, i think it would be nice to consider taking an
interval. you can make the second value optional.

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

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 5 Sep 2000 17:11:56 +0200 (MET DST)

> 
> Hi,
> 
> In my case, the signing time is part of the signed data.  We may
> like to re-verify old data from our archives at any time.  Thus,
ok, you MAY LIKE. :-)

> we would also like a "VALID AT" type of option.  I agree that an interval
> could be problematic, if a cert was suspended for a period between
> the endpoints, how would you discover that.  Just checking the endpoints
> would not reveal the suspension.  I would say, if the app is uncertain
> of the signing time, let it make as many "VALID AT" queries as it likes
> to make it happy.

The question is when and why do you want to discover whether a cert
had been suspended become VALID later again. If you need this in order
to make audit trails of a verifying application that does authentication,
just let them log the ocsp response.

If you have an application that does anything serious with long term
documents, AND if you want detect the suspended case, let the originator
add appropriate information, or never make suspended certs valid again,
etc.   

Which date are you asking for, remember, the 'now' date is the one of
the OCSP server, and the answer of 'now' does not say whether
the cert is valid/invalid at 'now', but only that in case of 'good',
the server doesn't know anything negative at that moment. It
may happen that it receives a CRL a minute later, that has a
revoked cert with a revocation date 2 minutes ago, a new request
would now tell that. Since the two OCSP requests should inconsistent
information which of the two answer would you see for a validAt
send at the 'now' of the first response.