Mark>If we're going to parallel the real, non-digital world, time
stamps
and signatures are not atomic in the general case. Documents often
contain dates and other serializing information. They are part and
parcel of the document being signed, not the signature. How they
appear in the document depends upon the document. Often dates are
placed next to signatures to indicate, ostensibly, when the signature
was applied, but not always.
I'd like to clarify my suggestion. I did not mean that we should attach
a time stamp to the dcument itself, as that might convey a different
semantic. What I was suggesting was that the signature itself be time
stamped, and that the timestamp be included as part of the message
digest. That way, even if I sign exactly the same document twice, I
would get a different result.
One of the problems I am trying to address is the intangible nature of
a signed electronic document. That is an inherently different case than
a paper document with a wet signature -- the forensics are completely
different.
Part of the problem concerns nonrepudiation. In many cases it would be
nice to have a certain level of comfort that a document was signed
within the expiry period fo the certificate, without having to go
through the entire trusted third party notarization process. It maight
not constitute incontrovertable proof, but if the the user's own time
stamp indicates it was within the validity interval then it probably
was valid.
However, a time stamp on a document, even if somewhat inaccurate,
places a document in a sequence, and it is unlikely that the time
would be wrong by more than an hour -- almost certainly not a day.
But
if I receive a document that is dated in the future, or is
significantly stale, as a recipient I would certainly have cause to
wonder, and perhaps check a little further.
Somewhat inaccurate? More like arbitrarily inaccurate. You are making
the assumption that you are examining these signed messages is near
real time. In that case, yes, you could look at the wall clock and
the message and compare. But that doesn't speak to real world
applications where documents are, more often than not, not examined in
real time.
True enough, but I also have other indicia, such as the time stamps
applied to the e-mail message, etc. Not perfect, but a strong clue most
of the time.
In your previous message you asked about assurance. Time stamps,
certificate expiration dates, certificate revocation mechanisms, and
the option of high-quality identification policies and binding of the
name/identity to a public key are the primary differentiators between
a system that was supposed to provide the option of high assurance
(PEM) and a system like PGP (which already includes a time stamp, as
does PKCS if my memory serves me correctly).
Mark>People must understand the doument, not just how to verify the
signature. In that context, they must understand what it means to
have dates in a signed document or not. We can't standardize- or
program-away the requirement that people think about what they read.
Would that we could.
That's certainly true. The date in the document might be the date it
was originally composed, the date of last revision, etc., etc. We don't
know. But the date applied to a signature is unambiguous as to its
semantic meaning, disregarding the question of accuracy.
One of the reasons why I would like to have this included within the
signature itself is that I foresee most of the security-critical parts
of the signature process, including the message digest calculation and
the actual signature, as taking place on a smart card. There is no
reason why such a card couldn't also include an accurate clock,
removing any possibility of the user manipulating the time.
Mark>An automatic time stamp that may be arbitrarily inacurate could
cause problems. Besides, PEM signatures can be used on a broad range
of message types, and for many time/date stamps and serialization are
explicitly included, implicitly included, or unnecessary.
I understand all of the arguments about the date/time not being of
guaranteed accuracy, but I fail to conclude from that why no date/time
at all would be a better solution. Add a date-time stamp within the
signature would be a very low cost, with potential gain for a number of
kinds of transactions.
Mark>No, we can and should do. Once MOSS has spread, we can build upon
it. We should stop trying to put everything up to and including the
kitchen sink in MOSS. Think how much harder it would have been to
learn to sign your name if you also had to include the date and time
without lifting your pen!
My frustration level with this process is increasing monotonically,
because even though this is the second iteration of trying to build a
reasonably universal public key infrastructure, the vendors appear to
have a vested interest in their current capabilities and code and don't
want to change a single line. Again and again we hear that it is too
late, that we have to get the product out the door, that we can't
include everything, etc., etc., but that's exactly what was said three
years ago, and so far we haven't even seen the final draft of the
proposed standard!
There is never enough time to do it right, but there is always enough
time (for someone else) to do it over!
Bob