On 08/20/09 00:11, Ray Dillinger wrote:
No. This juvenile fantasy is complete and utter nonsense, and I've heard people repeating it to each other far too often. If you repeat it to each other too often you run the risk of starting to believe it, and it will only get you in trouble. This is a world that has not just cryptographic protocols but also laws and rules and a society into which those protocols must fit. That stuff doesn't all go away just because some fantasy-world conception of the future of commerce as unlinkable anonymous transactions says it should.
most of the financial industry digital certificate specifications were "relying party only" digital certificates ... effectively only containing an account number ... because of privacy (both in us and europe) and liability issues. some of this was also about the time that EU-DPD made statements that electronic retail transactions should be w/o names (i.e. remove person names from payment cards ... also a form of "relying party only" instrument). this somewhat side-stepped whether it was linkable or not ... since it then was back at the financial institution whether the account number was linked to a person or anonymous ... but did meet privacy requirements for retail payments .... depending on gov. & financial institution with regard to any possible "know your customer" mandates ... a court order to the financial institution had the potential of revealing any linkage There were a couple issues: 1) even as a relying-party-only digital certificate ... the digital certificate gorp resulted on the order of 100 times payload bloat for typical payment transaction payload size. there were two approaches a) strip the digital certificate off the payment transaction as early as possible to minimize the onerous payload penalty; b) financial standards looked at doing compressed relying-party-only digital certificates ... possibly getting the payload bloat down to only a factor of ten times (instead of one hundred times). 2) it was trivial to show that the issuing financial institution already had a superset of information carried in the relying-party-only digital certificate ... so it was redundant and superfluous to repeatedly send such a digital certificate back to the issuing financial institution appended to every payment transactions (completely redundant and superfluous was separate issue from representing factor of 100 times payload bloat). so there were two possible solutions to the enormous payload bloat a) just digital sign the transaction and not bother to append the redundant and superfluous relying party only certificate b) the standards work on compression included eliminating fields that the issuing financial institution already possessed ... since it was possible to demonstrate that the issuing financial institution had a superset of all information in a relying-party-only digital certificate ... it was possible to compress the size of the digital certificate to zero bytes. then it was possible to mandate that zero byte digital certificates be appended to every payment transaction (also addressing the enormous payload bloat problem). the x9.59 financial transaction standard ... some refs http://www.garlic.com/~lynn/x959.html#x959 just specified requirement for every payment transaction to be authenticated ... and didn't really care whether there was no digital certificate appended ... or whether it was mandated that zero-byte digital certificates were appended. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com