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]

Reply via email to