pem-dev
[Top] [All Lists]

Nonrepudiation and CA liabilities

1995-10-16 13:18:00
This is my belief. VISA have made it clear that they do not wish other people 
to >be using their credentials for their own purposes.

Problem is that providing non-repudiation only to particular parties is a non 
trivial problem.

              Phill


Phill, I think you have hit the nail precisely on the head. Visa is almost 
surely not opposed to having the benefits of norepudiation for their own 
purposes -- after all, it gives them one more lever to use to combat fraud, 
improve profitability, go after users who claim they never authorized a 
transaction, etc.

The problem from the very beginning is that being a CA means making 
representations about someone, and then binding a public key to those 
representations. To the extent that the CA issuing the Visa credentials is 
named or otherwise identified, then if some relying party suffers harm from an 
error of identification by the CA, the CA is potentially liable for damages.

In the credit card world, these damages are sharply limited, because the only 
relying party is the acquirer, and there is already in existance a mechanism, 
for sharing both the profit and the liability for any fraud between the 
acquiring bank, the payment association, and the issuing bank.

In particular, the transaction fee that is charged to the merchant and then 
spread among the other players is a flat percentage of the amount of the 
trasnactions, so in general the risk is strictly proportional to the reward.

For the general-purpose CA this is not true. Firsr of all, there is no 
mechanism that involves the CA in every transaction. so the number of 
risk-bearing transactions is not even known, much less any proportional 
assessment of a fee as a function fo the risk per transaction. Second, many of 
the risks are not a function of the value of the transaction at all, so any 
concept of even a reliance limit goes out the window.

(An example would be a certificate which (erroneously) identified someone as a 
medical doctor. Someone send an encrypted message to the doctor asking for help 
in combatting his AIDS condition, only to find out that the recipient wasn't a 
doctor at all. Now we have a message with no intrinsic value at all, but the 
misidentification of the originator causes great emotional distries, etc., etc. 
to the originator of the message, who relied on the contents of the 
certificate.)

One way to control this would be to use a nonstandard format, but that just 
means that someone would have to modify the software to use that format. At the 
same time, the standard infrastructure can not be used, so the implementation 
costs increase.

Another way would be to use some of the keyUsage constraints provided in 
version 3, so that only compliant implementations would be able to use the 
certificates.

The third, and I believe best alternative, is to include sufficient legal 
notice in the certificate itself as to spell out exactly what the CA's 
obligations and standards of trust are, and then take adequate steps to ensure 
that they are met.

And finally, and this is where legislation may be in order, we need to have a 
no-fault, safe-haven for CAs that follow all the rules, are licensed and 
audited, etc., to ensure that they are not subject to a ruinous suit brought by 
someone who was harmed because a minor human error or statement of fact by the 
subscriber.


Bob

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


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