RE: [dss] Gregor's comments on req draft 02 (WAS: RE: [dss] Groups- dss-requirements-1.0-draft-02.doc uploaded)

[Karel Wouters <Karel.Wouters@esat.kuleuven.ac.be>]

Nick,

I'm a little bit confused here; are you saying that if a client presents a
signature with a (signed) signing time, service will answer "valid" if the
certificate was OK at that time?

My understanding of time indications in (ordinary) signatures is that
they are purely informative.

Enabling this would open up some 'interesting' possibilities, like
back-dating a signature to a date prior to the certificate validity.

In any case, for the default level of trust, I would say:
time-stamps > client time > included time

Karel.

On Tue, 1 Apr 2003, Nick Pope wrote:

> I suggest that where there is a signing time given in a signature the
> signature should be check whether the certificate and revocation is valid at
> that time.
>
> If there is a time-stamp against the signature this may be used to confirm
> the signing time.  The client may also provide an expected signing time
> which could be checked against the (claimed) siging time within the XML
> signature.
>
> Only if there is no indication of the signing time should a time be used
> from the client.
>
> Nick
>
> > -----Original Message-----
> > From: Gregor Karlinger [mailto:gregor.karlinger@cio.gv.at]
> > Sent: 31 March 2003 22:31
> > To: 'Trevor Perrin'
> > Cc: dss@lists.oasis-open.org
> > Subject: RE: [dss] Gregor's comments on req draft 02 (WAS: RE: [dss]
> > Groups - dss-requirements-1.0-draft-02.doc uploaded)
> >
> >
> > Trevor,
> >
> > > -----Original Message-----
> > > From: Trevor Perrin [mailto:trevp@trevp.net]
> > > Sent: Monday, March 31, 2003 6:46 PM
> > > To: Gregor Karlinger
> > > Cc: dss@lists.oasis-open.org
> > > Subject: Re: [dss] Gregor's comments on req draft 02 (WAS:
> > > RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded)
> > >
> > >
> > > At 11:58 AM 3/31/2003 +0200, Gregor Karlinger wrote:
> > >
> > > > > Trevor wrote:
> > > > > Right, but when the client wants to determine
> > > verification status at
> > > > > some time in the past, does he want to know what the server
> > > > > *thought* the verification status was then, or what the server
> > > > > *currently
> > > > > thinks* the
> > > > > verification status was then.  I'm pretty sure it's the
> > > latter, just
> > > > > wanted to check.
> > > >
> > > >No. The service should verify the signature based on revocation info
> > > >for the date requested by the client. What would be the
> > > sense of pro-
> > > >viding a date in the past, if the service verified based on current
> > > >revocation info?
> > >
> > > Should the service verify based on the information it
> > > currently has about
> > > that date in the past, or should it verify based on the data
> > > it had then?
> > >
> > > That is, is the service trying to give it's best answer about
> > > whether the
> > > signature was valid on that date, or is it trying to simulate
> > > how it would
> > > have responded on that date?
> >
> > Now I think I've got it. Of course, the service should use the
> > information at the time of the request. Examples where the know-
> > ledge of the service could have changed:
> >
> > * A certificate was "on hold" at the validation date, but has been
> >   set to status "valid" again later. In this case the service should
> >   report the cert as valid.
> >
> > * The latest CRL has not been available at the validation time. The
> >   next available CRL after the validation time contains the signer
> >   certificate as "revoked". In this case the service should report
> >   the cert as "revoked".
> >
> > /Gregor
> >
> >
> >
>
>