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

Hi Nick,

Moving forward, this is good. Comments inter-mixed below.

Ed

----- Original Message ----
From: Nick Pope <nickpope@secstan.com>
To: OASIS DSS TC <dss@lists.oasis-open.org>
Sent: Friday, May 12, 2006 10:26:28 AM
Subject: RE: [dss] wd-42 errors - <dss:VerificationTime>

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.

<ed>

You need to cover the scenario when the incoming signature has neither a SigningTime attribute nor a Timestamp of any kind. I would say the server would have to return "SigningTime not present in signature". In fact this is the scenario which represents the initial motive behind having a VerificationTime optional input. The caller wants to know if the signature (absent of any claimed SigningTime) is/was valid at this particular point in time. Under the scenario where no signing time of any sort exists and if the request does NOT contain a dss:VerificationTime, then the DSS implementation has only 2 choices 1) use current time, or 2) reject request. Take your pick. This I believe needs to be made clear in the spec, and again for inter-operability reasons the core should describe default processing. Again and as always, this can be qualified/overriden/constrainted by the profiles.

</ed>
[Nick Pope]

I agree I had included in (c) below in Signing Time "unknown" to cover just such a situation.

<ed>Text is unclear and non-specific</ed>

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.

<ed>

Forgive me, but I do not know what this is saying. If you are saying something like "the VerificationTime element should have additional REQUEST-side qualifiers something like ...

- use the SigningTime if present to verify this signature

- use the current time if no signing time of any sort exists

- use the TimeStampTime in any 3rd party content TimeStampToken included as a SIGNED ATTRIBUTE that might be present

[Nick Pope]

This close to what I was thinking - qualifiers (attibutes) of <VerificationTime> to indicate:

- use Signing Timg (whether or not backed up by a timestamp)

- user Current time

If the qualifier isn't present use the time indicated in the <VerificationTime> element.

<ed>Too simple. You must cover at least the scenarios mentioned in this response.</ed>

... then I am all for it !!! In fact these qualifiers themselves could be subject to extensibility in the spec. This is infinitely better that hard-defining rules in the specification has to how to handle and report on VerificationTime and also supports your "local policy applies" suggestion. Implementations simply extend the above list and inter-operability is preserved since implementations can simply return "Not Supported" if they encounter something they can't handle. Lowest common denominator.

N.B. Again please note that I totally discount SIGNATURE timestamps as a legitimate source of SigningTime since they attest and represent the time before which they know the signature existed and not when it was created. We are discussing the original SigningTime here, not the signature-timestamped-at time. I would suggest all references to signature timestamp as it applies to this discource (i.e. ReturnSigningTime) be dropped, or left to policy qualifiers (see below)

Forgive the diatribe but I believe the ultimate time-respecting signature tool would ...

- pass the DATA/CONTENT to be signed to a trusted 3rd party timestamping service (e.g. TSA)

- include that data and the resultant content timestamp in the scope of the new signature as Signed Attributes/Properties

- produce the signature

- send the signature to be verified to a DSS or equivalent service and include an AddTimestamp option to get a signature timestamp as well

Then you would have:

- a reference to the time before which you know the data existed

- a claimed signing time which would have to be after the 1st time

- a time before which the data, the content timestamp, and the signature existed and was verified, and lastly

- a timestamp optionally attesting to this verification and its results

P.S. If a non-DSS implementation created the signature e.g. OpenOffice, Microsoft Office, or some software vendors signing tool, then a SigningTime attribute may be present and might simply reflect the system time taken from the desktop PC it runs on. In this case the SigningTime is simply self-declared.

</ed>
[Nick Pope]

I suggest exactly how the signing time is established should be a matter for the server policy.

<ed> OK. Agreed but what is default processing ? If you don't specify this you don't have a core.</ed>

c) The <SigningTime> schema should be extended: <ed>perhaps on the request side not on the response side</ed>
- 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.

<ed>

That is fine and I agree you absolutely need to confirm the "window set by policy" as you mentioned. But today's TSA's provide a timestamp or a time mark applied to a digital signature value which ONLY attests to the facat that the digital signature was created before the date included in the time-stamp or time mark. This is enormously helpful when assessing whether this time is within the certificate validity period, but does NOTHING in attesting to the claimed SigningTime nor the data existed before time.

</ed>

I disagree - if the policy is that the data has to be time-stamped within a limited time (e.g. before sending or on first receipt) .

<ed>Don't know how practical this will be, with the fundamental notion of successful verification entirely up to server policy</ed>

- in the case of claimed time is confirmed by signature timestamp <ed>No, way too specific to the arbitrary policy of the DSS provider </ed> the server should indicate the time difference (so that the client, if it wishes, can
reject the signature of they are too far apart.)

<ed>

I contend we should extend the VerificationTime to allow callers to qualify what they want checked on the Request side of things. This is how we stay clear of the policy quagmire and maintain flexibility and extensibility.

</ed>
[Nick Pope]

I suggest that we give the flexibility allow clients to indicate their requirements if they are aware of the issues. Otherwise let the server decide.

<ed>Fine, but define the terms more than they are presently ... which is minimally qualified and unclear at best</ed>

Nick

<ed>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

dss message