RE: [dss] wd-42 errors - <dss:VerificationTime>

["Nick Pope" <nickpope@secstan.com>]

Following from the issue raised by Ed on <dss:VerificationTime> and its
relationship with claimed SigningTime and Signature timestamp.
> > 39) line 1656: "instead of the current time" implies that the DSS
> > implementation always uses the current time by default. What if
> > "SigningTime" is present in the signature ? This optional input
> > element needs to be re-written to reflect questions fielded from the
> > public review.

 &

> > 40) line 1747: a note should be made that qualifies the 3rd party's
> > ability to attest to the SigningTime (i.e. only content Timestamps
> > applied before signature creation should result in the
> > ThirdPartyTimestamp boolean being turned on, since a signature
> > Timestamp may be applied months after
> > SigningTime.)

And related public comments from inma@dif.um.es on 21 April:

I propose that:

a) If verification time is not present then it is up to the server to select
the time at which the signature is to be verified based on local policy and
any claimed signing time / timestamps provided with the signature.  If this
is not current time then the server should provide the signing time in the
signing time output.

b) To cover the scenario that the client explicetly wants to use the current
time or to use what is assumed to be the signing time additional indicators
need to be added to: <verification time> to indicate: current time, signing
time.

c) The <SigningTime> schema should be extended:
- to allow of indication that signing time is unknown.
- to clarify a claimed time may be confirmed by a valid signature timestamp
(reference should be made to 4.3.2) provided that the two values are within
a window set by the servers policy.
- in the case of claimed time is confirmed by signature timestamp the server
should indicate the time difference (so that the client, if it wishes, can
reject the signature of they are too far apart.)

Nick