RE: [dss] Timestamping

[Trevor Perrin <trevp@trevp.net>]

At 06:21 PM 3/19/2003 -0500, Dimitri Andivahis wrote:

>Trevor,
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
[...]
> > A time-stamped signature contains, as an unsigned attribute, a timestamp
> > "token", which somehow binds the time and a hash of the time-stamped
> > signature's signatureValue, and is created and signed by a 3rd party TSA
> > (Time Stamp Authority).
> >
>
>One comment on the last sentence above: 3rd party TSAs may be using
>techniques other than digital signatures to bind the time and the hash
>and generate the timestamp token.
>
>For example, the TSAs defined for the binary protocols universe
>in the ISO 18014-1,2,3 timestamping standards use digital signatures,
>MACs or linking methods.  If you are not familiar with them,
>the ISO standards extend the protocols and data types defined
>in RFC 3161 and are fully compatible with RFC 3161 when
>the digital signatures method is used.
>
>In the XML world now, there were timestamping input documents submitted
>to this TC that contain XML Schemas covering all methods of
>timestamping, not just the one using digital signatures.


Are there public docs for the ISO standards?  They'd be interesting to look 
at, since most of the timestamping submissions to the TC seem inspired by 
RFC 3161 (these are the ones I remember):
http://lists.oasis-open.org/archives/dss/200211/msg00003.html - Entrust
http://lists.oasis-open.org/archives/dss/200212/msg00004.html - Juan Carlos 
Cruellas
http://lists.oasis-open.org/archives/dss/200212/msg00012.html - EML
http://lists.oasis-open.org/archives/dss/200301/msg00001.html - Gregor 
Karlinger

As for linking methods, only Gregor's submission discusses supporting them 
in detail (though it does a good job).  But are these methods practical, 
and worth the effort?  If so, what requirements should be added for them?


> > More generally, a timestamp token may be used to timestamp other things
> > than a signatureValue.
> >
> > Now, whatever format the timestamp token takes, a timestamp protocol just
> > requires the client send a hash and receive back a token.  This shouldn't
> > be any different from the DSS protocol used in the "client-side hashing"
> > and "receiving a detached signature" case.  Thus, time-stamping
> > should just
> > be a use-case of the DSS protocol, not a separate protocol.
> >
>
>I don't think the timestamping protocol should be confused with the
>DSS protocol.  The semantics of the two processes, requesting
>a digital signature from a server vs. requesting a timestamp token from a TSA,
>are totally different.  Let alone, this is a non-starter
>if the TSA generates timestamp tokens using a linking method or a MAC.
>I think almost all XML Schemas for timestamping that were submitted
>to this TC capture the complexity of the timestamp request/response
>process and account for the need for a separate timestamping protocol.

Could you elaborate?  Aside from linking, the above protocols all just send 
a hash, and receive back a signature on the hash and time.  This doesn't 
seem any different than sending a hash and receiving back a signature on 
the hash and any other signed attribute (such as requestor identity, 
signature policy, etc..).

[...]

>My opinion is that we should have a separate timestamping protocol
>for communicating with TSAs, for the reasons I described earlier.
>In the interest of avoiding confusion with other timestamping standards
>in the non-XML universe, I would also propose keeping timestamp tokens
>separate from time-marks, if they are indeed different objects.
>I'm a bit unclear on the issue of time-marking in general.  I've seen a
>short definition in ETSI 102023, but there was little detail.
>
>Could any cryptographic binding between a submitted hash and
>a time value qualify as a "time-mark", as long as the time-mark
>server archives "something" for each request and maintains a secure
>audit trail, against which each "time-mark" issued may be validated?
>If so, any of the TSAs defined in other timestamping standards
>could be extended to do a bit of archiving and offer time-marking
>services (time mark == timestamp token).

I was hoping a time mark was just when a signer adds a signed attribute 
containing the time.

Maybe better terms come from Juan Carlos' submission, which says (in 3.2) 
that adding such an attribute creates a "timed signature", but not a 
"signed timestamp".  I was thinking maybe a "timed signature" is a better 
way of doing a timestamp, because it keeps separate the data the signer is 
referring to (the <SignedInfo>) and what the signer is asserting about it 
(the signed attributes).

This makes time-stamping more consistent with other function a DSS service 
might provide (like signing contracts, or identifying requestors), and this 
consistency would let a DSS service make multiple assertions about a 
document in a single signature.  For example, a notary might want to both
  - attest to the identify of the requestor
  - attest to the time of the request (i.e. timestamp the document)

If both <RequestTime> and <RequestorIdentity> could be attached as signed 
attributes, then the notary could both timestamp the document and identify 
the requestor within a single ds:Signature.


>Are there interesting cases of non-TSAs that offer some type
>of time-marking service?  If so, what precludes them from being full-blown 
>TSAs?

Maybe the notary service above?  I'd say such a service is a "TSA" if TSA 
just means someone trusted to be authoritative for time by some relying 
party.  Or maybe you wouldn't consider it a TSA, since it doesn't provide 
timestamping as an individual service, only in conjunction with 
authentication and requestor identification.  I dunno.

Trevor