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

From: Russ Housley <[email-masked]>
Date: Mon, 22 Jan 2001 10:44:54 -0500

I think this is a very good idea.  I strongly encourage us to do it.

Russ

At 04:59 AM 1/20/2001 -0500, Linn, John wrote:
>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: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 17:37:39 +0100

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Jan 2001 13:36:25 -0500

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

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 09:37:58 +0100

Russ,

> Denis:
> 
> I agree with 1, 2a, and 2b. 

Fine. 

> I cannot accept 2c.

I said: " I believe that we should think more about the consequences before
supporting this service." I still think it !

> current-time checking will stop.  

Fine. But if current-time checking is done, there is no need any more for a
retrospective check. So what would be the additional value of a
retrospective check if current-time checking is done ?

> Retrospective checking has always been

Let me rephrase the issue in a different way. We have two options:

a) either support time stamping of every individual CRL in the server (I
wanted to avoid this), or
b) support no time stamping in the server.

In case (a), the service would work in any case, provided that the chosen
TSA is "acceptable" to the relying party.
In case (b), the service would not work any more in case of a CA key
compromise.  

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. 

Which case do we want to support ?

Once again, I believe that we should think more about the consequences
before rushing to support this service.

Denis

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Jan 2001 10:08:39 -0500

>retrospective check if current-time checking is done ?

This is where we disagree.  When there is a dispute, a retrospective check 
is needed to determine whether the relying party did their processing 
correctly.

>In case (b), the service would not work any more in case of a CA key

Doesn't this require the TSA to validate the subscriber signature before 
providing a time stamp?  While this policy could be implemented, I do not 
believe that all TSAs will want to implement such a policy.  If fact, I can 
think of cases where I would want time stamps for unsigned documents.

>checking, since one structure would include individual time stamps while the

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

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 16:48:32 +0100

Russ,

[Russ]

[Denis]

[Russ]

[Denis * new answer]

We certainly disagree here, since when there is a dispute, a retrospective
check is NOT needed. A proof obtained at current-time checking that has been
time-stamped at that time is sufficient.  

Next topic:

[Russ]

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.

[Denis]

[Russ]

[Denis * new answer]

No. You certainly read the TSP document since you provide numerous comments
during the last call period. :-) However, you missed the point that there is
no such notion of "subscriber signature". Time stamp requests do not need
to be authenticated. In addition, since the only thing a TSA "sees" is an
imprint, it cannot know whether what is a signed or unsigned document. In
other words a TSA blindly signs everything.

Next topic:

[Denis]

[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
form the server (otherwise, you would not need the evidence). Hence you
would not trust either the clock from the server. 

Denis

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Jan 2001 11:55:22 -0500

Denis:

I do not understand your point.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Jan 2001 11:54:12 -0500

Denis:

I thought that you might have some novel use of time stamp policy.  I am 
glad to see that you do not.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 18:04:14 +0100

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

> >from the server (otherwise, you would not need the evidence). Hence you