From: Jueneman@gte.com
Date: Fri, 12 Jan 1996 16:58:19 +0800
To: Michael Froomkin <cypherpunks@toad.com>
Subject: Reliance Limits Considered Harmful
Message-ID: <30F54978-00000001@wotan.gte.com>
MIME-Version: 1.0
Content-Type: text/plain


>Suppose I am a CA.  I am worried that by issuing a certificate with a 
>lifespan of more than 2 milliseconds I am opening myself up to unlimited 
>liability if for some reason, despite my best efforts, I issue an 
>erroneous certificate.
>
>I know I can write disclaimers, but that's not reliable since courts 
>often ignore them, and anyway it scares off customers.
>
>I know I can put an expiration date on the certificate, but that's not 
>enough.  I can accumulate a lot of exposure in a few seconds, much less 
>weeks.
>
>I know I can put a reliance limit in the X.509 ver 3 certificate, but 
>that's not enough.  Even a $1 limit could be used many millions of times.
>
>Is it feasabile to say: Can only be relied on once per day/week/month?  
>Is this something the relying parties can reasonably be expected to monitor?
>
>It seems to me that this sort of a limit is essential if a CA is to feel 
>comfortable outside Utah....
>
>A. Michael Froomkin        | +1 (305) 284-4285; +1 (305) 284-6506 (fax)
>Associate Professor of Law | 
>U. Miami School of Law     | froomkin@law.miami.edu
>P.O. Box 248087            | http://www.law.miami.edu/~froomkin
>Coral Gables, FL 33124 USA | It's warm here.
>

I have been troubled from the first with the concept of a reliance limit, in 
particular because of the problem Prof. Froomkin cites. In the "normal" 
paradigm for digital signatures, neither the CA nor the relying party(ies) have 
any knowledge of how many times that particular certificate/key has been used. 
As a result, there are few if any controls that would operate to enforce the 
notion of a reliance limit.

Even in the electronic credit card environment where there is some sort of a 
closed loop system (the purchases are reported back to the Issuing Bank, and 
presumably would be or could be known by the CA, which is probably acting as an 
agent of the bank), there are some substantial problems.

The first problem is one of privacy.  If I have a very high credit limit, I 
certainly don't want to advertise that fact in a public certificate. On the 
other hand, if I have a low limit, I don't want to advertise that either. And 
in any case, the reliance limit is not intended to be a "floor limit", i.e., an 
amount below which it is not required to contact the credit card company for 
authrotization.  (Floor limits used to be popular, especially in Europe where  
the cost of telecommuncations was high. But now almost all transactions are 
authorized against the customer's current balance and credit limit, and if the 
merchant doesn't check he can be stuck with the charge if the customer doesn't 
pay.)

I have argued (quite unsuccessfully in the credit card community) that the 
reliance limit can provide a useful means of limiting the subscriber's exposure 
(as well as the CA's) in the event of a security compromise affecting the 
subscriber's private key.  Since there are no perfect computer security 
solutions available at any price, much less an affordable price, both the 
subscriber and the CA have to make a tradeoff between their risks and the 
rewards of greater convenience, etc. I tried to get around the privacy issue in 
the credit card environment by treating a negative reliance limit as a 
percentage of the customer credit limit. But no one in the credit card industry 
was convinced, and maybe I'm not either.

The concept of a reliance limit is enshrined in the Utah Digital Signature 
statute (and the ABA draft Digital Signature Guidelines), where it is wrapped 
up with a draconian requirement that registered CAs have to put up a surety 
bond or irrevocable letter or credit in the amount of 30% of the aggregate of 
all outstanding reliance limits.  This is not just an insurance policy -- a 
CA's corporate assets are pledged to back up the certificates issued, not 
withstanding the fact that the identification system we have in this country is 
not sufficiently reliable to warrant such representations.  And surely no CA is 
going to hire private investigators to check out who someone claims to be with 
sufficient credibility as to be able to issue certificates to individuals -- at 
least if they intend to charge any kind of a reasonable price for the 
certificates. In my personal opinion, that requirement in the Utah law makes it 
highly unlikely that anyone will ever become a registered CA in Utah, unless 
the reliance limit is set to $1 and/or the expiration period to about 1 
millisecond.  

(Maybe the Utah statute was really trying to set up a lottery, rather than a 
system for registering CAs.  Everyone gets to play, and if you can find a 
person who has invalid credentials, even if issued through an innocuous 
clerical error (someone misspelled the street name in someone's address), you 
can claim you were harmed in some way, sue them big time and collect millions.  
That's the American way, isn't it? :-)

Although X.509 v3 provides a simple mechanism to allow additional attributes, 
potentially including a reliance limit, to be included in the certificate, 
there are at present no plans that I know of for any existing CA to actually do 
so, or more importantly, for anyone else's software to be able to read and 
comprehend those reliance limits or perform any checking.

As a purely technical matter, the problem could be solved by requiring the 
relying party to validate the transaction (not just the certificate) with the 
CA in real time.  (Checking a CRL database isn't good enough.) By providing a 
transaction amount, the CA could keep track of the extent of its liability, and 
could detect misuse. Alternatively, the subscriber could request a new 
certificate for each one time use. However, both of these "solutions" would 
require a significant extension to the current mechanisms, and also give rise 
to a number of privacy issues.

In addition, there are other practical problems.  If I am the relying party (or 
the CA), and the subscriber is using his digital signature to confirm an order 
to sell futures on the commodities market, how can I evaluate the potential 
risk?  If the subscriber is selling futures for orange juice and a storm wipes 
out all of the orange trees, his losses could be unbounded. Similar situations 
could exist in the case of a signature on a patent claim, and creative people 
can probably think of many more cases.

Although the notion of a reliance limit usually arises in conjunction with 
digital signatures, it would presumably apply to certificates used for message 
encryption, to set up encrypted sessions, etc., as well. This puts the CA in an 
even more difficult position, for now we are not talking about a (single) 
financial transaction.  If I send an encrypted message to someone, and it turns 
out that the person who received it was not who he claimed be, I may in fact be 
greatly harmed. (If the message wasn't important, why would I have encrypted it 
in the first place. Suits for violation of privacy have resulted in millions of 
dollars in damages  -- does that mean that the CA ought to provide a million 
dollar reliance limit?

My conclusion after having thought about this a lot is that reliance limits are 
at best ineffective and at worst positively harmful.  They are difficult or 
impossible to enforce in any meaningful way, they raise substantial privacy 
issues, and at least as codified in the Utah Act and the draft Digital 
Signature Guidelines they will almost surely act to dissuade any prudent 
business from setting up a licensed CA.

Does this mean that the subscriber, relying party, and CA all have effectively 
unbounded liability, absent a stated reliance limit?

No, I don't think so, but we may have to change our paradigm a little bit.

Most people accept a driver's license as providing a degree of proof of 
someone's identity, but very few would consider it proof positive. Since the 
state-issued driver's license is the only practical means of identication 
available to a CA in the case of private individuals, that consitutes the 
weakest link in the system and is quite likely to remain so.

The only other identification document I am aware of that is available to 
private individuals that provides substantially better identification than a 
driver's license is a permit to carry a concealed weapon. Here in 
Massachusetts, obtaining a pistol permit requires a trip to the local police 
station, where you are photographed, fingerprinted, and two or more affidavits 
concerning your character are reviewed prior to submitting your fingerprints 
and picture to the FBI, where a search of the NCIC database is used to 
determine if you have any prior arrests, etc. The permit card that is issued 
carries your residence or business address, your picture, fingerprint, date and 
place of birth, height, weight, complexion, hair color, eye color, and 
occupation. Since the Brady Bill was passed, I believe that many states have 
set up similar systems. (Of course many jurisdictions sharply limit who can 
actually receive a weapons permit.  I'm only describing the process, not 
debating the reasonableness or unreasonableness of gun controls.)

Even if state laws were amended to make this degree of identification assurance 
available for purposes other than weapons permits, many if not most people 
would have strong reservations about the privacy implications. And to the best 
of my knowledge, private companies are not allowed to access the NCIC, also for 
privacy reasons.

Does all this mean that digital signatures are worthless?  No, not at all. But 
it does mean that they are unlikely to convey a degree of surety as to 
someone's identity that is very much stronger than a driver's license 
identification.

In my personal opinion, I think we need to establish a stronger degree of "no 
fault" protection for CAs that follow the rules.  Whose rules are to be 
followed, and who audits them for conformance are valid issues.  We clearly 
don't want irresponsible CAs issuing certificates to all and sundry, but we 
can't make the cost of entry into the business so high that no one takes on the 
burden of being a CA at all.  The issue is how to balance risks, the costs, and 
the rewards equitably between the subscriber, the relying party, and the CA.

In the case of the credit/debit card industry, the credit card companies charge 
a fee that covers both the risk and their administrative costs. If digital 
signatures can be used to reduce their risks, presumably the fees charged to 
the merchants can be reduced somewhat. But in any case, the fee that is charged 
is proportional to the amount of the transaction, and therefore statistically 
covers the risk.

The real question is what to do outside of the credit card industry, where 
certificates may be used for transactions are much more complex, and where 
there may not be the infrastructure to collect a percentage fee for each use.

Please copy me directly on any replies, as (to the best of my knowledge) I am 
not a subscriber to cypherpunks.

Bob

----------------------------
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 

"The opinions expressed are my own, and may or may not
reflect the official position of GTE, if any."