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

Ed, Nick, All,

I forward my proposal por dss:VerificationTime and dss:ReturnSigningTime.

In my opinion, the final solution should take in consideration the following design criteria

Try to validate the signature using the nearest time instant to the “real” signing time (note that the “real” signing time should be in between the SigningTime attribute (if any) and the SignatureTimestamp (if any)), given that any SigningTime that exceeds the SignatureTimestamp is, obviously, invalid).
As we have many possible combinations for determining which is the time instant to validate a signature, as determined by
- Different sources of time instants, i.e. dss:VerificationTime, several attributes inside the signature, maybe time-marks if the server support them.
- Different sources of constraints to the validation (that may affect the behaviour of the server), i.e. signature policies, server configuration, …

we should make some effort to inform the user about what’s happening behind the scenes when validating a signature, if we don’t want to have every different core-implementing server to behave differently in an incomprehensible way for the clients.

dss:VerificationTime

For me, although these definitions seem to be very obvious,

the “verification time” is the time instant when the signature is verified. This is a broader concept than the signing time.
the “signing time” is the time instant when the signature is determined to be created (as you know, we have several mechanisms to get time instants near the “real” signing time (we will discuss this later), like signature attributes and time-marks)

So, in the context of a signature verification, WE ALWAYS HAVE a “verification time”, that sometimes is a “signing time” (and that’s good) and some times is not (depending of whether the “signing time” is known or not).

I propose the following:

To create a new optional input (as it’s not accurate to try to solve every case with dss:ReturnSigningTime) to obtain the time instant when the signature is verified, like dss:ReturnVerificationTimeDetails. Its corresponding optional output (i.e. VerificationTimeDetails) should include (apart from the time instant used to verify the signature) information (qualifiers) about the nature of the time instant used for verification, with the following possibilities
- claimed SigningTime,
- signature timestamp,
- server time-mark,
- local server verification time (when no time information is present)
- user-provided time (i.e. dss:VerificationTime)
To keep dss:VerificationTime to let the users pass the desired verification time (some times is very useful, especially when no time information is present). I would add an optional boolean attribute, with default=false, in the request (like overrideTimeInformation (we will find the correct name for this), letting users even to override the information that can be present inside the signature.

dss:ReturnSigningTime

I concur with Ed, the ReturnSigningTime should work only when we have information about the “signing time” (i.o.c. we should have a “signing time not found”). I also think that the signature timestamp cannot be accepted as a “signing time” (it’s an upper bound for it), BUT is very useful to qualify the signing time (i.e. to set the maximum acceptable error for the claimed signing time, i.e. via signature policy (signature timestamp delay)). So I would never return the signature timestamp time in the response, and use the ThirdPartyTimestamp attribute of the dss:SigningTime to signal when a timestamp is used to qualify the signing time (that is, when we have both signing time information (i.e. SigningTime attribute) and third-party signature time information (i.e. timestamp / timemark)).

I would refactor the ThirdPartyTimestamp attribute to ThirdPartyTimeInformation to cover the time-mark case, changing it from boolean to string and enumerating the possible cases (timestamp, timemark, none).

What do you think?

Kind regards,

Carlos

Carlos González-Cadenas
Chief Security Officer

Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
gonzalezcarlos@netfocus.es
www.netfocus.es

De: ed.shallow@rogers.com [mailto:ed.shallow@rogers.com]
Enviado el: viernes, 12 de mayo de 2006 19:10
Para: Nick Pope
CC: DSS TC List
Asunto: 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>

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

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

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>

- 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

<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