RE: [dss] Timestamping

[Trevor Perrin <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.

It would be great if they were willing to make this a submission.


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

It defines an XML format for linked timestamps.  But what are the protocol 
requirements for a linked timestamp service, above and beyond those 
required for a "simple" timestamp service (i.e. one that just signs the 
hash and time)?

For example, suppose the aggregation round lasts longer than the client is 
willing to wait to get his timestamp.  Does the client get a ticket or 
something, and come back later to retrieve the finished product?  Doesn't 
the service need to broadcast the aggregation round values, in such a way 
that 3rd parties will archive them and they won't be tampered with?  Does 
that require another data format and protocol?  And won't a verifying party 
need a protocol to retrieve these round values from the 3rd parties?

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

Agreed, linking is more complicated.  But a "simple" timestamp, which is 
just a ds:Signature over the time and hash, could be easily accomodated in 
a DSS protocol, I think.

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

There will be a DSS verification protocol as well as signing, which should 
take care of that.


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

Requirements placed on the type or contents of the token produced 
(public-key signature, MAC, simple or linked timestamp), might only affect 
the payload of the response message, but not the request message.

For example, there's a lot of complexities around how the client submits 
the data he wants signed or timestamped.  In XML, the client could 
transform these data himself or not, hash them himself or not, send a whole 
document even when he only wants parts of it signed, or only send those 
parts, etc..

This part of the protocol might be exactly the same for a digital signature 
service, a "simple" timestamping service, or a "linked" timestamping 
service.  So maybe this indicates that the core DSS protocol should be a 
generic "submit document, receive cryptographic token based on document" 
protocol, instead of just a "digital signatures" protocol, since much of 
the protocol details will be about document submission, but be indifferent 
to what type of token is actually produced.


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

I don't think those differences are major, as they claim.  The TSA may only 
have access to the hash, but it can still produce a DSIG, that's just a 
protocol detail.  The example is simplistic, but it didn't have to be, you 
can put the same contents from an RFC 3161 TSTInfo into the signed 
timestamp attribute (though you would omit the messageImprint).


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

That's my point though: a time-mark can serve just fine as a simple 
timestamp, if it's produced by a party trusted as a TSA.


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

I know what you describe is a common crypto definition of a notary 
service.  I was thinking more like John Messing's eNotarization use case 
though, where the document is not signed by the end-user, but rather the 
end-user submits the document to the notary service and authenticates 
himself to it somehow, and the notary service then signs the document with 
its private key, while attaching the name of the end-user and the time as 
signed attributes.

If the relying party trusts the notary to be authoritative for time, and 
the notary service adds some policy identifer to indicate that he means for 
this to be a time-stamp, then I'd call it one.  And this way of 
timestamping is convenient, cause the notary can both assert the 
requestor's identity and assert the timestamp within a single ds:Signature.

But I don't think every time-mark would have to be a time-stamp, if you 
just want to toss in <SigningTime> for informative purposes, but don't 
expect anyone to take it seriously, then it wouldn't be a timestamp..

Trevor