RE: [dss] Timestamping

["Dimitri Andivahis" <dimitri@surety.com>]

Trevor,

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Wednesday, March 19, 2003 11:36 PM
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
> 
> 
> At 06:21 PM 3/19/2003 -0500, Dimitri Andivahis wrote:
> 
> >Trevor,
> >
> > > -----Original Message-----
> > > From: Trevor Perrin [mailto:trevp@trevp.net]
> > [...]
> 
> 
> Are there public docs for the ISO standards?  They'd be 
> interesting to look 
> at, 

ISO makes money by selling standards documents, so their docs 
are usually NOT available to the general public for free.  
There are a few people on this TC who have access to the ISO 
time-stamping documents.  I will check with the ISO admin folks,
see if they would allow us to share.

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

I think Juan Carlos' submission had some coverage too, although not in detail.  

> But are these methods practical, 
> and worth the effort?  If so, what requirements should be added for them?
> 
> 

I believe they are practical.  A commercial implementation 
of a digital timestamping service using linking methods 
has been available on the Internet since 1995.  
A TSA practicing linking methods is not required
to sign the submitted hash, time value and other info 
within the timestamp token, and this may be an advantage 
in various situations (key management issues, long-lived 
timestamping).

Gregor's submission goes a long way towards providing support for it.  
We would need to define a protocol for timestamp-token verification,
similar to what's done in ISO 18014-1.  I am offering to contribute to any 
additional work this may require.

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

Not exactly.  A TSA using a linking method doesn't have to  
sign anything that goes in the timestamp token.  In the 
binary protocols world of ISO 18014-3, the returned timestamp token 
may be a value of type SignedData (for TSAs who link and sign) 
or DigestedData (for those who link only).  In XML, there 
are minOccurs="0" attributes for the various alternatives, 
as shown on page 18 of Gregor's submission.

Requests for timestamp tokens produced using MACs, as defined
in ISO 18014-2, could be made to fit in your XML DigSig DSS protocol.
However, verification of timestamp tokens produced using MACs  
requires that a verification protocol with the issuing TSA 
be conducted, since the TSA is the only entity in possession of  
the secret key(s).

The more general issue is, I don't think you can use the same
protocol (i.e., the same request and response objects) 
for disparate services, such as requesting a generic digital signature 
and a timestamp token issued by a TSA.  There are many requirements 
placed on the TSA generating a timestamp token that have nothing 
to do with the fact that it may be generating them 
as XML signatures over some data.  These requirements 
are reflected in the contents of the timestamp token returned,
which may or may not be a signed object.  Even when the timestamp token 
is a signed object, there's a lot more going on than saying 
it's a special case of a digital signature request.

> [...]
> 
> >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).
> 

OK, that clears up the definition of time-marking.  However, 
see top of page 7 for their argument over "timed signature" and TST.

> This makes time-stamping more consistent with other function a 
> DSS service 

I would substitute "time-stamping" to "time-marking" in the sentence above.

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

Again, I would substitute "time-mark the document" above.

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

Agreed, the notary is a TTP that checks the digital signatures, and signs over 
the data submitted and a time attribute that may be trusted.
The notary would have to follow the same requirements for trusted time 
as a TSA, even though technically it's not a TSA.  Will the same 
requirements apply to all time-mark providers?

Dimitri