Bob,
You raise many, many interesting issues, most of which will take time to
evolve. One detail caught my eye:
At 2:13 AM 2/11/95, Jueneman(_at_)gte(_dot_)com wrote:
What happens if Mr. Z somehow obtains a copy of that signed transaction, and
submits it to the originator's bank as often as he pleases. My books are
still
packed after yet another office move, but unless my memory fails me, THERE IS
NOTHING PROVIDED IN PEM THAT WOULD PROVIDE EITHER A DATE/TIME
STAMP OR A TRANSACTION NUMBER TO SUCH A TRANSACTION.
It's been well understood within the PEM community that there is no
mechanism defined within the PEM protocol to distinguish two separate
signings of the same content. I believe it is also agreed that this is not
an inherent problem. It simply means that feature has not been included in
the PEM protocol and if there is a need for this service, it belongs in the
next layer up.
I agree, although in retrospect I wish we had taken a different position.
The "correct" position for a time/date function for digital signatures could
certainly be debated, and admittedly the problem can be solved at higher
layers. My only question is whether the application developers and/or users
will remember to do so if the need arises, or whether a more all-encompassing
solution would be better.
In the CyberCash payment protocols under development, we obviously have
exactly the requirement you suggest, and for that reason we do, in fact,
include a transaction identifier, and we do require that the recipient
check for duplicates and treat duplicates as retransmissions as oppposed to
new events. This makes sense in the restricted context of a payment
protocol. However, in the more general arena of protected mail for all
purposes, it is not so obvious that the cost and difficulty of implementing
this feature is worth it.
In an electronic payment system the need is obvious, but the inclusion of
proprietary versions of transaction identifiers may tend to limit
interoperability unnecessarily.
What I had just realized, however, was that the deficiency extends beyond
electronic cash, and includes virtually all forms of commercial paper. This
includes warehouse receipts, bills of lading, mortgages, stocks and bonds, and
probably many more that I'm ignoring.
The legal implications arise from the fact that it has generally been stated
that a digitally signed document is a 'writing" in the sense of the Statute of
Frauds, and should therefore be more than satisfactory from that point of view.
I'm not an attorney, but it occured to me that there is more to a "writing"
than its permanance and perhaps solemnity -- there is also the aspect of
tangibility, and the presumed difficulty of copying or cloning the document.
Merely putting a date/time or sequence number in the digital signature block
would not solve the problem by itself, however. It appears that it will be
necessary to have some kind of an on-line registry for the recodation of such
signatures, sort of like the way that mortgages and other liens are recorded on
property.
The particular problem would appear to be that once a digitally signed
warehouse receipt for 100 bales of cotton has been issued, the recipient would
be able to take that receipt to multiple banks and borrow against it, or to
perhaps sell it to multiple people. Unlike the typical banking environment
scenario, commercial paper is not necessarily processed a closed loop. Once the
receipt, etc., is generated it is handled by multiple recipients in due course
until one of the purchasers finally demands the possession of the article
itself.
Whether PEM is or is not intended to be used in this environment could also be
debated, but if PEM is not suited for such applications, its potential market
will be somewhat smaller than might otherwise be the case. One could even argue
that in that case the relatively low assurance provided by PGP would suffice,
and that we should build another protocol more suited for electronic commerce,
irrespective of electronic "mail." (This is heresy, I know. :-)
Maybe some really bright cryptographer can find a solution to this problem that
doesn't require the equivalent of a latin notaire. But I'd point out that it
isn't sufficient to merely detect the existance of a duplicate -- it is
necessary to have some way of resolving whose clone of a receipt is the "real"
one. So far, I think it is impossible without some kind of a closed loop
reference system.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820