Re: Client Certificate UI for Chrome? [OT anonymous-transaction bull***t]

2009-08-21 Thread Ray Dillinger
[Moderator's note: this is getting a bit off topic, and I'd prefer to
limit followups. --Perry]

On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote:
 Ray Dillinger wrote:

  If there is not an existing relationship (first time someone 
  uses an e-tailer) then there has to be a key depository that 
  both can authenticate to, with a token authorizing their 
  authentication to authenticate them to the other, which then 
  vouches to each for the identity of the other.  
 
 Actually not.
 
 What the seller wants to know is that the buyer's money is good, not 
 what the true name of the buyer is - a service provided by Visa, or 
 Web-money, or some such.

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.  

In any transaction involving physical goods, the seller also wants 
to know to whom to ship the product.  Since the laws in most nations 
do not require the recipient of an erroneous shipment to return 
the goods and *do* require the seller to give back the buyer's money
if the shipment doesn't go where the buyer wants it, sellers really 
care that the correct recipient will receive the package and really 
need some way to contact the buyer in case there's a mistake about 
the recipient address or identity.  Otherwise you'd get people 
playing silly buggers with the shipping address to get out of paying 
for million-dollar equipment.

The law usually requires that the recipient of defective goods 
or services has the ability to return those goods for a refund 
or obtain a refund in the event of seller nonperformance of 
services or nonshipment of goods.  Since such returns can be 
used to launder money from illegal enterprises, laws usually 
restrict anonymous returns. Therefore the seller needs the 
buyer's (or client's) identity in order to comply with the law.

In information-based transactions involving IP that's subject 
to copyright or trade secret protection (which is effectively 
all of them since other IP can be had for free) the seller also 
wants to know who is the licensee that's bound by the terms 
of the license and who now poses a risk of copyright breakage.  
In both cases this is a liability taken on by the buyer, and 
not something that his money being good for just the 
transaction price can ameliorate.

In financial transactions The seller also wants to know that s/he 
can comply with, eg, know your customer laws and avoid liability
for gross negligence in, eg, money laundering cases.  

In many transactions the seller wants the buyer's identity and a 
liability waiver signed by the buyer so as to keep track of or 
avoid liability for what the customer is going to do with his/her
products.  

Most sellers want the ability to offer the buyer credit terms,
especially when large sums are involved.  And even where money 
is supposedly firm (like the money Bernie Madoff's clients had 
in their accounts) it is subject to catastrophic vanishment in
extraordinary circumstances.  The seller needs to know whom to 
sue or at least whose name to put on the forms for their insurance 
claim if contrary to expectations the buyer's money turns out not 
to be good.

If the cert authority does not provide the identity of the buyer 
but asserts that the buyer's money is good, and this turns out not 
to be true (as in the case of Madoff's clients), then in most 
legal systems the cert authority is either liable, or can expect 
to be sued in a very expensive empirical test of liability.  So 
the cert authority doesn't want to be in the business of vouching 
for the ability of anonymous people to pay.  

The only way for the money to be truly firm for these purposes 
is that the cert authority has it in escrow.  This makes the 
cert authority a financial institution and therefore subject to 
know your customer mandatory reporting, data retention laws,
subpeonas, and so on.  Also, it introduces a needless delay 
and complication to the transaction that legitimate buyers and 
sellers would mostly rather not have. 

Also, in any large transaction the seller or cert authority or both 
must retain buyer identity information in order to be able to 
comply with subpeonas, inquests, or equivalent writs, for 
periods ranging from zero in a few undeveloped african nations to 
five years in much of the rest of the world. 

In most of the nations on earth, there is such a thing as sales 
tax or use tax on goods or services, and any transaction involving
more than a tiny sum must be reported (with the names of buyer and
seller) to 

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

2009-08-21 Thread 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 majord...@metzdowd.com