re:
http://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there
a market
slightly related discussion of x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959
supporting hash of invoice in any dispute resolution ... thread from a couple
weeks ago
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial
services
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial
services
where the x9.59 transaction is digital signed (and presumably logged/archived
as part
of various financial regulations).
In dispute, both parties can produce their version of any invoice (bill of
materials, etc)
and differences can be resolved by the hash included in the signed payment
transaction.
In the mid-90s, the x9a10 financial standard working group had been given the
requirement
to preserve the integrity of the financial infrastructure for ALL retail
payments. It
faced a couple issues
1) It was starting to dawn that x.509 identity certificates from the early 90s, frequently
overloaded with personal information represented significant privacy and liability issues.
As a result there was move to digital certificates that contained some sort of
indirect
(and/or obfuscated) lookup value ... and were frequently referred to as
relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivial to show that in any situation where the indirection had
to be
used for some sort of lookup ... that the public key could be obtained in the
same
operation ... making the digital certificate redundant and superfluous
2) Some of the other digital signed work for financial transactions in the
period ...
the appending of a digital certificate to such a transaction was resulting in
two orders magnitude payload and processing bloat (for something that was
redundant
and superfluous)
http://www.garlic.com/~lynn/subpubkey.html#bloat
3) The appending of the digital certificate is basically a paradigm operation
that
supports distribution of trusted information for offline operation (the electronic
analog of physical credential, certificate, license, and/or letters of credit/introduction
from sailing ship days and earlier). At the time we were working on x9.59 ... there
were several claiming that the appending of digital certificates (to financial
transactions)
was needed to bring financial processing into the "modern age". Our reply was
that moving
from a fundamentally online infrastructure to an offline paradigm actually
represented
a regression of several decades. It was somewhat after that you started to see
work
on the rube goldberg OCSP standard.
....
In some respect ... trusted time-stamping is attempting to take the online
financial
transaction model where there are frequently strict regulations about
archiving/auditing
and extend it to other types of operations. In the x9.59 financial standard
scenario ...
the financial archiving/auditing infrastructure was extended to cover invoice,
bill-of-materials,
etc ... but simply adding their hash to the digital signed financial transaction
(and at the same time avoiding the enormous payload and processing bloat seen
in various
other strategies).
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
