Karel,
Yes, you are right, the signing time is only "claimed". There needs to be
some way of confirming the signing time before this can be used for
validation. This can be done by the validation client providing the signing
time.
I take back the last statement. The signing time can only be used if there
is some mechanism to confirm this.
Nick
-----Original Message-----
From: Karel Wouters [mailto:Kare...@esat.kuleuven.ac.be]
Sent: 01 April 2003 11:48
To: Nick Pope
Cc: ds...@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)
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.
-----Original Message-----
From: Gregor Karlinger [mailto:greg...@cio.gv.at]
Sent: 31 March 2003 22:31
To: 'Trevor Perrin'
Cc: ds...@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:tre...@trevp.net]
Sent: Monday, March 31, 2003 6:46 PM
To: Gregor Karlinger
Cc: ds...@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
63 messages in org.oasis-open.lists.dssRE: [dss] Gregor's comments on req dr...
.bin