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.
This is a really terrible idea, I'm afraid. We currently have a clean and
simple relationship between the MIME message structure and the message digest
-- the digest is computed over the first part of a multipart structure and
that's that. No information outside of that structure is required or used. It
is even possible to use the same digest information to produce multiple
signatures.
Making the message digest depend on anything that's outside of the signed MIME
object, e.g. a timestamp that's part of the signature information, breaks this
nice relationship. It complicates implementations considerably and introduces
significant dependencies between generic security multipart processing and
specific processing of a particular security scheme. For example, in my
implementation I compute whatever digest is called for and then pass it to an
external agent to produce the actual signature. I can no longer do this if
there's additional information the digest has to cover that's part of the
signature process itself. I'll have to pass the incomplete computation state of
the digest algorithm over to the security service, which is doable but very
ugly. (Note that I'm assuming the timestamp is included at the end of the
digest. Putting it anywhere else breaks single pass processing and is therefore
an absolute showstopper.)
There are ways to work around these problems, of course. The simplest way would
be to compute a separate digest for the combination of the timestamp and the
original digest and sign it along with the original digest. But now the basic
signature mechanism is much more complex.
There are also serious presentational issues here. I now have a new piece of
information that enters into and comes out of the signature process. I guess I
don't have a problem coming up with the information, although there will
inevitably be demands for "post-dating" facilities. But I quite frankly don't
know what I'm supposed to do with what comes out -- it isn't part of the MIME
structure, and while I can arbitrarily stuff it into the MIME structure the
semantics start to get pretty confusing. And if there's one thing that's
become clear in all this discussion, is that semantics are crucial and we
have great difficulty agreeing to much beyond the simplest semantics possible.
Now, I could tolerate all of this if the resulting service was significantly
improved. However, I see absolutely no benefit to be had from this entire
proposal. In particular, we can already do everything this proposal offers with
existing MIME and MOSS services.
Specifically, we can create a composite object that includes both the original
document AND a timestamp AND sign the whole thing. This can be done with
existing MIME services, as Harald suggested, i.e. message/rfc822. The semantics
of using a signed message structure to timestamp the signature are not quite
the same as associating the timestamp with the signature itself, but since this
isn't a trusted third party service I fail to see that the difference is
in any way significant.
Note that this also solves the presentation problem, since presentation of
message objects is something we know how to do. However, if message/rfc822 is
for some reason unacceptable, there's nothing to prevent the definition of an
additional composite object expressly for the purpose of dating a signed
object. I think its entirely unecessary, but anyone can define such a thing any
time they feel like it -- all it takes is a two page RFC at most. For that
matter, you could define a new content- header to do it if you wanted a really
lightweight mechanism. (The FTBP proposal already provides such a header, as a
matter of fact.)
The real problem this points out seems to be a lack of willingness to actually
use existing MIME facilities the security multiparts scheme provides access to.
I've spent a lot of time trying to point out how these things can be used to
advantage, but apparently not enough. There's more to using MIME facilities
than the desire for compatibility, you know -- MIME actually offers a lot of
functionality that PEM needs.
In any case, everyone needs to remember that signatures are no longer limited
to atomic objects (documents) -- they can be applied to complex composite
structures and there is no problem adding to the repetoire of building blocks
we use to build such structures.
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.
The message/rfc822 object is a completely natural fit here, both in terms of
the paradigm it offers as well as the actual service it supports.
You start with a document. It could have been written a day ago or a week ago
or 10 years ago -- it doesn't matter. You wish to sign and send this document
to someone and you want to include the date of this action, but you don't want
to mess up the document itself. How do you do it?
Well, in the wet signature world what you is enclose it in something else, date
the enclosure, sign it, and send it.
Its exactly the same with MOSS. You take the document, put it in an enclosure
(message), date it, sign it, and send it. The last action creates an outer
message wrapper, of course.
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.
This would be better off being built along the lines of a third party time
stamping service. In particular, if there's actually some guarantee that the
timestamp was produced by a neutral third party, be it a smart card or
whatever, there needs to be an absolutely unambiguous indication of this in the
resulting object. Production of an object which just as easily could have
contained a timestamp set to whatever the originator wanted is NOT acceptable,
as it completely eliminates all the benefits of using the smart card and its
integral and reliable time stamp.
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!
I object, in the strongest possible terms, to this. I have no problem with
adding additional useful functionality. I have seen no real indication that
anyone else involved in this work does either. I have gone on record, over and
over over again, to try to support attempts by others to build enhanced
services in this area. I also have changed my code, not once, not twice, but
many times, to accomodate this group's ever-changing tastes on various issues,
even with I disagreed, absolutely and completely, with the group's decision.
I note in passing that its been over a month now and we have yet to see even
the start of documents describing any of the various recently discussed
security enhancements, this despite vociferous assurances from various
proponents that such work could be completed in a timely fashion. So much for
timely handling of additional work items -- this group hasn't changed at all as
far as I can tell.
However, what you are asking for now is that we seriously compromise the design
of both MOSS AND the security multiparts scheme in order to incorporate nothing
more than a variant of a service we already have. This is quite different from
opposing changes because they would compromise existing code, and as such use
of this characterization is disingenuous at best.
There is never enough time to do it right, but there is always enough
time (for someone else) to do it over!
There also appears to be enough time to do it wrong, because as far as I can
see that's exactly what you are now proposing.
Ned