pem-dev
[Top] [All Lists]

Re: Nonrepudiation and CA liabilities

1995-10-17 11:30:00
This is exactly what we *don't* need.  Another government bureaucracy to
control CA's and all attendant technologies. :-(

You are jumping to a conclusion. I claim that it would be in the public 
interest to have CAs that are intended to be highly reputable be subject 
to SOME form of auditing and oversight. I don't care whether this is 
established by legislation or regulation, a la the Utah Digital Signature 
Act, by some form of professional accreditation organization, or by 
organizzations like the big eight accounting firms certifying that they 
have audited the operations of the CA and found that they conform to the 
generally accepted guideliens for blah, blah. the qeustion of which 
organization should be assigned the oversight responisbility is an entire 
different issue.

In exchange for this oversight and/or regulation, however, I believe that 
the CAs are entitled to a form of no-fault protection against errors in 
identification. Our society has elected not to establish the sort of 
strong identification document system that some other countries use, and 
for a number of good reasons. but having made that decision, we should not 
hold a CA responsible for acting like a private investigator and going out 
to determine whoi this person "really" is, where they reside, etc.

If the CA accepts identification information from someone in good faith 
and has been reasonably diligent about checking them, they should not be 
subject to suit if someone claims a false identity by us of a forged or 
stolen dirver's license, for example. Yet at present, they could be, and 
the current Utah law requires very substantial capital be tied up to make 
sure that the CA has adequately deep pockets to pay off such suits. I 
believe this to be inherently unfair, and it raises the bar far too high. 
As a result, organizations such as Visa are motivated to use nonstandard 
certificate formats as a means of trying to avoid any liability if one of 
their "crednetials" is used for anything other than the intended purpose.

Risk should be shared amongst those want to be in the market.  I.e Banks,
credit card consortiums and other financial institutions.  Managing CA
risk for financial transactions is not significantly different than for 
mail order credit card transactions.  Why does LL Bean et. al. ship goods 
against unverified credit cards?  Simple.  The risk of credit loss is 
acceptable to them in return for the increased sales volume and therefore
profitability.  Why does the customer, you and me, give out our credit 
card numbers to them? Simple. The bank is limiting our potential losses.
Why does the bank do this? Simple.  It makes them money. 

No, this is not the same thing at all. Once a CA issues a certificate, 
they have absolutely no control over how many times the user (or someone 
who has stolen the user's private key) actually signs something. If an 
accidental error were made in the identification of the subject, the CA 
could potentially be held liable for every single instance of a digital 
signature, voer which the CA has no control whatsoever.

Without appropriate controls, the liability is potentially enormous, and 
certainly disproportionate to the cost of any reasonably priced 
certificate.

The same banking regulations we have now regarding capital base etc. are 
sufficient to use in the case of cyberbanking.  We *dont* need another
government agency making these decisions for us.

Regards:
-arc
Arley Carter
Tradewinds Technologies, Inc.
email: ac(_at_)hawk(_dot_)twinds(_dot_)com
www: http://www.twinds.com

I wasn't talking about banking exclusively. In fact, the primary issue I 
have been trying to address is to figure out how the banking/credit card 
people can coexist with and support a public key infrastructure that is 
used for other purposes as well, so that every industry doesn't feel the 
need to go off and invents their own certificate type, etc.


Bob

Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting


<Prev in Thread] Current Thread [Next in Thread>