Subject: Post-facto queries [Was: RE: DPD & DPV requirements]

From: "Linn, John" <[email-masked]>
Date: Sat, 20 Jan 2001 04:59:49 -0500

Considering one point arising within this thread: 

><snip>
>
>[Steve]
>
>There was some sentiment for having the "was it valid then" function as
>provided in SCVP, but if there is not continued support we could delete it.
>I want to get more feedback on this issue.
>
>[Denis]
>
>So, let us wait and see ...
>
>I'm not seeing any support for retrospective queries, so I think we'll drop
it.

I think it'd be useful to be able to support post-facto queries in the DPV
framework.  If a query specified a non-current time, a server could (if it
had the requisite info to determine then-current status) return the
appropriate status indication or else, without prejudice, indicate "unable
to determine status for requested time".  I can see value for DPV, and valid
requirements to make post-facto status determinations, and would rather
include such a hook than incur a need to define another generation of
certificate validation protocol in order to represent their conjunction. 

--jl

---

From: "Tom Gindin" <[email-masked]>
Date: Mon, 22 Jan 2001 18:35:54 -0500

As long as it is understood that a non-repudiation service (whether
technical or a stronger variant) should not rely primarily on post-facto
validation queries, supporting them is IMO not harmful.  Denis is quite
right to worry about the effects of excessive reliance on them.

          Tom Gindin

Russ Housley <[email-masked]> on 01/22/2001 01:36:25 PM

To:   Denis Pinkas <[email-masked]>
cc:   PKIX-List <[email-masked]>
Subject:  Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Denis:

I agree with 1, 2a, and 2b. I cannot accept 2c.

Just because a retrospective check is available does not mean that
current-time checking will stop.  Retrospective checking has always been
viewed as a concern, especially in a dispute.  This allows us to allocate
the data archive necessary to perform such checking to a server rather than
every client.

Russ

At 05:37 PM 1/22/2001 +0100, Denis Pinkas wrote:
>Russ,
>
> > I think this is a very good idea.  I strongly encourage us to do it.
>
>Wait a second. :-)
>
>It would be nice to get such a service ... but we have to think about the
>consequences.
>
>1) If such service would exist, then it should be clear that it should
only
>be optional.
>2) The functions of a CA should not be changed because of the existence of
>this functionality.
>
>What are the implications ?
>
>a) Such a service would not work as soon as revocation status would be
>obtained through OCSP responses. There is a move to get the revocation
>status of the leaf certificate using OCSP. Such service would thus be
>unusable in that case.
>
>b) Such a service would work if CRLs and delta CRls were all captured by a
>TTP *different* from the CA. The size of the storage might become quite
>important.
>
>c) Such a service would degrade the security. Let me explain. If people
can
>say: "We will check later, since we have a server always giving us the
right
>answer", then will rely on it and will not ask for the certificatio path
and
>revocation information at the time of initial verification. What can
happen
>between initial verification and a later verification ? The answer is: a
key
>compromise of a CA issuing key.
>
>Today by time-stamping the whole certification path and revocation
>information (i.e. the evidence) you can protect against that threat.
>
>If you would like to get the same protection the server would need to
obtain
>a time-stamp on every individual CRL and delta CRL and we would be
>encouraging structures like individual time-stamped CRLs and individual
>time-stamped delta-CRLs.
>
>In other words, supporting this service would imply supporting
time-stamping
>by the server. We wanted to avoid the support of time stamping by a DPV
>server and leave it to the discretion of the client.
>
>I believe that we should think more about the consequences before
supporting
>this service.
>
>Regards,
>
>Denis
>
>
> > Russ
> >
> > At 04:59 AM 1/20/2001 -0500, Linn, John wrote:

---

From: "Covey, Carlin" <[email-masked]>
Date: Tue, 23 Jan 2001 10:38:12 -0800

Thanks Tom,  that helped a lot.  

If the CA's signing key is compromised, then its signature over 
CRL's is certainly suspect, modulo the timestamping you described
(or some other countersignature mechanism).

But if the CA's signing key is compromised then its signature over 
certificates is also suspect.  The bad guy in possession of the CA's 
signing key could issue himself a back-dated certificate and sign any 
back-dated document he wished.  The fact that the CRL is timestamped,
and the CRL-plus-timestamp is again timestamped won't prevent this.
It seems to me that the document in question needs to be timestamped
at the time that it is signed by the originator.  Timestamping the
CRL's helps some, but not enough.

Regards,

Carlin

-------------------------------------
- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:56 AM
To: Denis Pinkas
Cc: Russ Housley; PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

     Denis:

     Is your primary objection to post-facto queries that they pose a
temptation to NR relying parties to avoid archiving contemporary
verification information?  If we look at the actual verifications performed
in NR, I think that you and I are in agreement that to have the RP keep the
(signed) revocation data supporting his initial determination is more
robust than to have the RP rely on the subsequent verifier acquiring the
revocation data through a post-facto query.  IMO this is not a reason why
post-facto queries would be useless in all cases, however - an auditor
attempting to find whether a strong login had occurred before a revocation
or after it (in a case where CRL publication is typically delayed) would
find them useful.
     These queries have their place when there is no better alternative,
but I think NR RP's are better off not relying on them.  If such an RP (or
the escrow holder for 2-way NR in my draft) maintains contemporary
revocation information, it cannot be affected by the CA ceasing operations
or failing to maintain archives.

          Tom Gindin

Denis Pinkas <[email-masked]> on 01/23/2001 12:04:14 PM

To:   Russ Housley <[email-masked]>
cc:   PKIX-List <[email-masked]>
Subject:  Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
>
> I do not understand your point.
>
> Russ
>
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs?  It can keep
> >track using its own clock as long as it has a trusted time source.  The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 23 Jan 2001 14:18:12 -0500

The example I was giving works in two cases: first if the CA has
separate CRL and certificate signing keys, second if the original signature
package (including the certificate) is time-stamped at time of origination
and pyramided in the same way as the CRL I described.

          Tom Gindin

"Covey, Carlin" <[email-masked]> on 01/23/2001 01:27:16 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:
Subject:  RE: Post-facto queries [Was: RE: DPD & DPV requirements]

Regards,

Carlin

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 11:04 AM
To: Covey, Carlin
Cc: [email-masked]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]

     A back-dated time stamp is indeed worthless.  If I remember Denis'
presentation at IETF 46 correctly, the main point of pyramiding time stamps
is to demonstrate that the message had the proper form at the proper time.
For example, suppose the following sequence of events, with the left column
indicating the relative month:

0:   CRL issued with key CA1.
18:  CRL time-stamped with key T0.
30:  CA1 compromised.
36:  Object from month 18 time-stamped with key T1.
45:  T0 compromised.
48:  Arbitrator asked to determine validity of CRL.

     As long as the times of the compromises are clearly known to be after
the time-stamp by the next TSA in the pyramid, the CRL inside the object
from month 36 is still verifiable at month 48, even though its own key and
the first time-stamp's key are compromised.

          Tom Gindin

"Covey, Carlin" <[email-masked]> on 01/23/2001 12:22:57 PM

To:   PKIX-List <[email-masked]>
cc:
Subject:  RE: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ, I think Denis is saying that if the client trusts the DPV
server's good/bad response, why wouldn't it also trust the timestamp
that the DPV server put on the response (obviating the need for a
third-party timestamp).  Denis, did I get that right?

I suppose the client might believe that the DPV server was honest,
but not a very good timekeeper.  Seems a stretch though....

I have a question on an earlier email in this thread. Perhaps I
misinterpreted something.  I'm puzzled why we would want timestamps
on individual CRLs in the case of post-facto validation of a certificate.
The CRL contains information that indicates its validity period.
Presumably if a timestamp were placed over the CRL later, the timestamp
would indicate the current time, not the validity time of the CRL.
(A timestamping server that back-dates timestamps doesn't seem very
trustworthy.)  Why would I care whether the CRL for a certain week three
months ago now had today's timestamp on it?  (I'm sure I must have missed
something in the discussion.)

Regards,

Carlin

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:04 AM
To: Russ Housley
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Russ,

Denis

answer
current-time
the
answer

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 23 Jan 2001 20:19:57 +0100 (MET)

> Not exactly. See above.

If all relying parties agree that the time that is used by the
DPV servers is a good one, then this a good one. It seems part
of a policy to decide whether a DPV response can just use some
'local time' or an external time stamp. 

This is an organisational issue.

A DPV server should not be restricted to use an external time
stamp. Well, the asn1 format can still be the same, the
time stamp is just signed with a different key/cert, but
having TWO signatures seems some overhead to me.