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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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 !

> Just because a retrospective check is available does not mean that
> 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
> 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.

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

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