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."