Subject: OCSP in Chicago

From: Ambarish Malpani <[email-masked]>
Date: Tue, 08 Sep 1998 15:02:30 -0700

Hi All,

For the benefit of those who were not in Chicago, it was resolved
that the symbol for notRevoked be changed to good. We have put
in the following explanation of the good state:

The "good" state indicates a positive response to the status inquiry. 
At a minimum, this positive response indicates that the certificate is
not revoked, but does not necessarily mean that the certificate was ever
issued or that the producedAt time is within the certificate's validity
interval. Response extensions may be used to convey additional
information on assertions made by the responder regarding the status of
the certificate such as positive statement about issuance, validity,
etc.).

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

---

From: Ed Posnak <[email-masked]>
Date: Tue, 08 Sep 1998 18:27:51 -0700

Does the following still apply to a "Good" status?

[from version 05] "... it is quite possible that an OCSP responder
returns the notRevoked state if a certificate was revoked, but has since
expired (equivalent to a serial number being dropped from the CRL). "

If so, perhaps the above sentence shouldn't have been dropped from the
description?

ejp

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 08 Sep 1998 22:17:20 -0700

Hi Ed,
    Please take a look at section 4.4.4 (Archive Cutoff). See if
that addresses your concerns.

4.4.4 Archive Cutoff

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.

OCSP servers that provide support for such historical reference SHOULD 
include an archive cutoff date extension in responses.  If included, 
this value SHALL be provided as an OCSP singleResponse extension  
identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime:

id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

archiveCutoff ::= GeneralizedTime

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

Regards,
Ambarish