From: John Dlugosz
The normal interpretation of signing something is to agree with or assert
its content. If that's the only kind we have, we can do this:
I sign my document. Then to prove I did so at a specific time, send the
signature (which may include the data or be detached, it matters not) to
the notary.
The notary produces a =new= document, which states "I afferm that the blob
sent to me (length nn, SHA1=xxxxxxx) was done so at whatever time." and
signs (afferms to) that.
A notary sig packet would do the same thing, but could be added to the file
containing the signature being signed. I beleive that is what the current
discussion has agreed on.
However, the above allows for another feature. The document produced by
the notary can contain other information too, to implement things from
section 4.1 of Applied Cryptography. For example, it can contain a serial
number, so someone who doesn't trust Trent's clock can find other documents
and know what order they were signed in (hmm, why would you trust Trent's
counter but not his clock?), lists of other "before" and "after" customers,
or other verification information that can be used to validate the
timestamp in other ways, without the need for a trusted notary to have
produced the timestamp signature.