Subject: [pkix] OCSP Archive Cutoff

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 13 Nov 2013 15:22:05 +0100

Now with PKIX closed. What is the future for maintenance of the RFCs?

I have a question regarding Archive Cutoff in RFC6960.

-----
"4.4.4. Archive Cutoff"
<snip>
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).
----

How is this archive cutoff date to be interpreted by an application. 
What does it actually mean?

What does "retention interval policy" mean? I am guessing that a 
retention interval policy of 7 years means that I will retain expired 
certificates in my OCSP responder for 7 years.

Say I produce an OCSP response today, for a certificate that expired 
yesterday: t1 = 2013-11-13 (seconds left our for simplicity)

Assuming that 7 years means that I will keep the the expired cert in my 
responder for 7 years:
ArchiveCutoff = (t1-7 years) = 2006-11-13

What is the meaning of 2006 here? For me it does not make much sense. 
How does this "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."?

Cheers,
Tomas

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 14 Nov 2013 15:14:58 +0100

Tomas,

> Say I produce an OCSP response today, for a certificate that expired yesterday: t1 = 2013-11-13 (seconds left our for
> simplicity)

t1 is not the date when a certificate expired but the date when the OCSP response was signed (producedAt).

   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.

> 
> Assuming that 7 years means that I will keep the the expired cert in my responder for 7 years:
> What is the meaning of 2006 here? For me it does not make much sense. How does this "contribute to a proof that a

If t1 is the date when the OCSP response was signed, archiveCutoff denotes the date until which revocation information
is available. In your example, a response signed (and sent) at 2013-11-13 indicating the status "good" for a certificate
that expired before 2006-11-13 is not reliable, because the information base of the OCSP responder does not
(necessarily) include revocation information of that certificate.

Johannes

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 14 Nov 2013 17:38:43 +0100

> (necessarily) include revocation information of that certificate.

Ah, now that makes finally sense to me. The spec could clearly benefot 
from a description of this simple kind: "for a certificate that expired 
before 2006-11-13 is not reliable"

Is Archive Cutoff widely used?

---

From: Sean Turner <[email-masked]>
Date: Fri, 29 Nov 2013 22:38:07 -0500

> Now with PKIX closed. What is the future for maintenance of the RFCs?

PKIX is closed but the list won’t be and the RFCs that were produced by PKIX can be discussed here.  Submitted errata will also be cced to this list, but the errata themselves are approved by the ADs (Stephen Farrell and myself for now).

If an RFC needs updating it can always be AD-sponsored and, like any other idea, if there’s enough interest a BOF could be held to determine whether a WG addressing that idea should be started.

spt