Client Certificate UI for Chrome? -- OT anonymous-transaction

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com