Subject: Re: Certificate Validity Problem

From: "Ersin Gulacti" <[email-masked]>
Date: Sun, 18 Dec 2005 11:39:57 +0200 (EET)

Thanks to everybody who sent comments about my question. I have read the
answers and related RFC's and it seems that SCVP is the only solution to
learn the status of a certificate at a certain time in the past. However I
find SCVP very complicated and we need only a limited part of the SCVP
functionality.

We would like to implement a new and simpler protocol to solve our
problem. This protocol may be called "Certificate History Retrieval
Protocol". What is the procedure to propose this as a new RFC?

Thanks.

Ersin

>
> Hello,
>
> We are operating a Certificate Authority (which uses our own CA software)
> and we have a process to set certificate status to on-hold. Owners of
> certificates can put their certificates on-hold and they can return them
> to the valid status.
>
> When somebody tries to verify the validity of signature he can only check
> the most recent status of the certificate. He can use the most fresh CRL
> or execute an OCSP query. Both of these techniques lack an important
> functionality, you cannot query the status of a certificate at a certain
> time in the past. Maybe at the time of signing the certificate used was
> on-hold.
>
> Is there a method or another technique to solve this problem?
>
> Thanks.
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Dec 2005 09:57:43 -0500

>Protocol". What is the procedure to propose this as a new RFC?

The PKIX WG is not likely to accept a new work item of the sort 
described above.  We are trying to wind down the WG, as per the 
direction of the IESG. You could choose to submit such a protocol to 
another WG, maybe LTANS, or make it an individual submission.

Your suggested protocol does not propose new functionality; it offers 
less functionality, and hence, would be nominally simpler. This is an 
understandable motivation, but it needs to be weighed against the 
costs of creating yet another standard, a standard that would offer a 
subset of the functionality of a protocol already developed by an 
extant IETF WG.

Generally, the IETF tries to avoid duplication in standards, which 
argues against this approach, whether pussued in another WG or via an 
individual submission.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Tue, 20 Dec 2005 08:54:17 -0500

Steve:

        I don't see why a critical OCSP SingleRequestExtension could not 
be defined to do this.  It could be called "StatusEffectiveTime", with 
syntax GeneralizedTime.  Why would another protocol be needed when a 
single extension might do the trick?
        I realize that RFC 2560 section 4.1.2 deprecates the use of 
critical extensions, but this is a clear case for one.  Using a 
non-critical extension would not work, since the requestor is not 
interested in the current status.  Support for this extension in a 
responder would be OPTIONAL.
        A standard current OCSP responder would be unlikely, as a 
functional matter, to be able to resolve these queries from its database.

Tom Gindin

Stephen Kent <[email-masked]>
Sent by: [email-masked]
12/19/2005 09:57 AM
 
        To:     "Ersin Gulacti" <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: Certificate Validity Problem

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Dec 2005 10:05:20 -0500

>functional matter, to be able to resolve these queries from its database.

Tom,

The change to the message format might be simple, as you suggest. 
However, the change at the server might be very extensive, and there 
is the question of whether the description of the requested 
functionality has really been posed properly.

We have seen a move toward fast-response OCSP servers that use 
pre-signed responses, which is incompatible with this sort of change 
in functionality. So, for some class of OCSP servers, this extension 
would not be supportable. I think we agree on that, given your 
closing sentence above.

Also, based on some of the message exchanged on this topic, it seems 
that some folks are trying to use OCSP as a cert status protocol, vs. 
a revocation status protocol. PKIX has declined to expand the scope 
of OCSP for this purpose. Some messages talk in terms of querying a 
CA for status data. That's worrisome, since the PKI model under which 
we operate makes the role of directories and OCSP servers distinct 
from CAs.  A CA may choose to operate a directory server or an OCSP 
server, but the CA is not the server, per se. This sort of confusion 
causes me to question the generality of suggestions like this.

To determine if a cert was valid, for a specific purpose, at a prior 
point in time, an RP needs to construct a cert path and verify the 
revocation status of each cert in the path, all relative to a given 
validation policy, as per SCVP. For expired EE certs, there is the 
possibility that one of more of the CA certs also have expired. So, 
what do we assume the RP has and has not saved from the transaction 
in question? If the RP saved the certs for the path, why did he not 
also save the CRLs or OCSP responses too? If he saved nothing but the 
EE cert, then what mechanism do we envision for him to acquire the 
expired CA certs in the path?

The use of the "certificate on hold" reason code seems to be the one 
case that causes the greatest potential problem for an RP who fails 
to collect timely revocation status data. I view this as another 
example of why this feature ought to be deprecated :-).

Steve

---

From: "santosh chokhani" <[email-masked]>
Date: Wed, 21 Dec 2005 09:31:47 -0500

If the cryptanalysis or compromise of expired keys is not a concern, one
could do cumulative CRL using an X.509 extension (3280 does not have this)
stating that the CRL contains expired certificates.

Also, there would be a need to change in 3280 so that base CRLs (vice delta)
can have "remove from hold" reason code.  Once you have these, you can use
revocation date in CRL entries to determine the revocation status at various
time.

(Good luck in terms of non-repudiation).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, December 20, 2005 10:05 AM
To: Tom Gindin
Cc: Ersin Gulacti; [email-masked]
Subject: Re: Certificate Validity Problem

Tom,

Steve

---

From: Michael Ströder <[email-masked]>
Date: Wed, 21 Dec 2005 16:30:28 +0100

Stephen Kent wrote:
> case that causes the greatest potential problem for an RP who fails to
> collect timely revocation status data. I view this as another example of
> why this feature ought to be deprecated :-).

Yes. It really opens a can of worms.

Ciao, Michael.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 22 Dec 2005 12:45:42 -0800

santosh chokhani wrote:
...
> revocation date in CRL entries to determine the revocation status at various

Some practices are suggested in my ID, "Certificate Revocation Revisited"
<http://www.faqs.org/ftp/pub/internet-drafts/draft-gerck-pkix-revocation-00.txt>
currently expired, allowing a relying party to determine the revocation status
of a certificate with higher reliability in less time -- notwithstanding the
discussed problems, including:

"Some mechanisms may not include direct evidence of the issuer CA's
assertion of a certificate's revocation status or conditions, at a
particular time. "

The ID also includes the considerations that apply to determinations of status
"change" processes, including certificateHold and removefromCRL.

Comments on the ID are welcome, as I am preparing an updated version (now
that some reference RFCs have been updated by the WG).

Cheers,
Ed Gerck