Researchers have recently criticized the Certificate Authority Trust Model — which involves the issuance and use of digital certificates to authenticate the identity of websites to end-users — because of an array of technical and institutional problems. The criticism is significant not only because of the systemic nature of the noted problems, but also because the Model is universally relied upon by websites offering secure connections (SSL and TLS) to end-users. The Model comes into play in virtually every commercial and business transaction occurring over the Internet, as well as in a wide variety of other confidential and private on-line communications. What has not been addressed to date, however, is the nature of the legal relationships between the parties involved with, or impacted by, the Model.
Steve Schultze and I tackle this topic in our recent article “The Certificate Authority Trust Model for SSL: A Defective Foundation for Encrypted Web Traffic and a Legal Quagmire.” We looked at the standard legal documents issued by the certificate authorities or “CAs,” including exemplar Subscriber Agreements (agreements between CAs and website operators); “Certification Practice Statements” (statements by CAs outlining their business practices); and Relying Party Agreements (purported agreements between CAs and “relying parties,” such as end-users). What we found was surprising:
- “Relying Party Agreements” purport to bind end-users to their terms despite the apparent absence of any mechanism to either affirmatively alert the end-user as to the existence of the supposed Agreements or afford the end-user an opportunity to register his or her acceptance or rejection of the Agreements’ terms
- Certification Practice Statements that suffer from the same problem (i.e. no affirmative notice to the end-user and no meaningful opportunity for acceptance or rejection of terms)
There were other issues as well. For example, the Relying Party Agreements and Certification Practice Statements set forth various obligations on the part of end-users (i.e. “relying parties”) such as: the requirement that end-users make an independent determination of whether it is reasonable to trust a website offering a secure connection (isn’t that the whole point of having a CA, so that the end-user doesn’t have to do that?); the requirement that the end-user be familiar with the crypto software and processes used to carry out the authentication process; and the end-user’s duty to indemnify and hold harmless the CA in the event of legal claims by third parties.
Given the absence of notice to the end-user and assent by the end-user, it would appear that many CAs would have a difficult time holding an end-user to the terms of the relying party agreements or certification practice statements. To date, the CA Trust Model’s legal architecture has apparently not been the subject of any published court decision and remains untested.
The bottom line is that the CA Trust Model’s legal architecture inures to the benefit of no one. Neither website operators, certificate authorities, nor end-users can be sure of their rights or exposure. The Model’s legal structure may therefore be just as troubling as its security vulnerabilities.
You can read the full article in PDF form.
[Editor: Steve Roosa gave a followup luncheon talk at CITP entitled The Devil is in the Indemnity Agreements: A Critique of the Certificate Authority Trust Model’s Putative Legal Foundation. Slides and audio are now posted.]
I just got introduced to this article, and would like to add some remarks against Steve’s comments on my article on An Open Audit. Thanks for reading!
The first point I’d make is that my article was written from the perspective of a CA. It therefore tried to walk a line between serving its members, and living in the world we have to live in. Which is to say, it doesn’t say everything there is to be said, it stops short of criticism and explanation, it just lays out sufficient to get us to the next step.
Which leads to the second point: Although it is interesting to talk about legal theories and public policy, the reality of the world is that CAs take on zero liability for their work. The risk analysis of the hypothetical phishing class action suit is just one brutal and simple argument in that favour, but my real point here is that this is the way the world is, not how it should be.
Which leads us to the third point: Insurance won’t help us, because expected liability is zero, and insurance is intended for real (actuarial) risks. In which case, insurance becomes a sort of purchasable endorsement for marketing purposes, which, reading between the lines, is the intention of the insurance clauses in CABForum’s EV Guidelines.
The final point is, what to do about all this? In all of the discussions that have ever happened, the end-user is the one that misses out. Having more discussions will I fear not help the end-user one bit. What then?
I think they’d *like* to take zero liability, but as Steve Roosa notes above, “the very documents which are intended to make the CA contractually immune to loss (and which appear to fail utterly in that regard), ironically paint the end-user to be a foreseeable plaintiff to whom a duty of care might be owed under applicable tort law.”
better user education (discussions about how the system works)
better/augmented trust models like DANE (requiring design discussions)
better user interfaces (hopefully coming out of discussions like this one)
That is, “Zero liability [of the CA] to the general public is the only sane choice.”
As he articulated in http://iang.org/papers/open_audit_lisa.html
The link posted by the commenter contains a good discussion of the history of the CA audit process and describes the attempted shift of liability from the CAs to “relying parties.” I read the proposed solution of “zero liability” and had several initial thoughts, although I will confess it’s still percolating in my head. So these are just preliminary observations: First, the endgame scenario that the proposed arrangement seeks to avoid (it seems) is one in which a CA is liable to the world because of a phishing attack and that no CA is in a position to absorb that liability. The problem with this nightmare scenario (and one sees it contemplated in the CA literature going back for some time) is that it may exist only in theory, and therefore may not be a good enough reason to structure a policy in which CAs are relieved of all liability, as they may be the parties best situated to prevent the unauthorized issuance of SSL certs. It follows that it might be poor policy to disincentivize the CAs through a program of zero liability to the general public. Second, would it be simpler to require more insurance from CAs (and perhaps website operators) and thereby extend the vision of the Extended Validation regime? Then again, maybe there is room for both regimes, with the end-user having the information to make a choice as to which universe he or she wants to live in. Interesting.
These issues mostly were noted a decade ago, and a reason WHY the certif authorities model was NOT hard-coded into US federal & model laws on e-signatures. Look at UETA. Also, compare the 2000 federal E-Sign Act with some of the earlier “digsig” state laws that it pre-empted.
The federal E-Sign Act and the state digital signature laws don’t pertain to the present discussion regarding enforceable contracts and tort liability. Although it is true that various institutional and technical issues with the CA model have been noted for some time (including going back to the ABA’s PKI Assessment Guidelines nearly a decade ago), I am unaware of any critique regarding the relying party agreements and certification practice statements along the lines of what we are discussing here (from the perspective of contract and tort law). Moreover, the landscape has evolved over the past decade, with a proliferation of CAs and a greatly increased reliance on the CA Trust Model. A decade ago, the legal issues under the private law were a curiosity. Now, however, with accentuated reliance, it has evolved into a legitimate problem. The tech issues I leave to the engineers, the legal problems, however, are easily fixed. So why not fix them?
This is what comes to mind when I scroll my unknown but trusted CA list:
Trust only your bank and credit cards as CA, if the bank trust the dealer, you can do business. If the dealer is not trusted by your bank, you may not be able to do any transaction anyway.
No default CA in the browser.
Use a similar of today system for lesser Identity connectios where ssl is the goal. Certificates can be imported at a site by site basis (when you register?) and perhaps held synced on-line (Google Yahoo) between computer upgrades.
http://www.frisno.com/2010/02/28/web-verification-https-ssl/
There are no “relying party agreements” at all, because end users aren’t agreeing to anything. Nobody is subject to agreements between CAs and websites except CAs and websites. The notion of magically applying terms to random third parties simply by declaring it so is patently absurd.
Agreements by definition are opt-in; there’s no such thing as a contract that you have to opt out of. If you don’t agree, there’s no agreement.
True.
If there are no relying party agreements, then what type of legally recognized negligence claim, if any, does a relying party have against a CA? Could a relying party ever meet all of the elements of a cause of action against a CA? In other words, just like all of those dismissed data breach cases, the plaintiff would have to show duty, breach, causation and damages. How does a CA “cause” damages and what kind of damages are we talking about? Wouldn’t a web site owner really be the “cause” of damages for poor security, fraud, theft, and/or deception? Aren’t we really talking about the security framework of the Internet and “consumer protection” rather than contract and tort?
Re: “the requirement that end-users make an independent determination of whether it is reasonable to trust a website offering a secure connection (isn’t that the whole point of having a CA, so that the end-user doesn’t have to do that?); ”
Wrong. An SSL certificate never was an indicator that the holder of the certificate follows the Boy Scout Oath. There is no known way to prove that a certificate holder is now and always will be trustworthy, loyal, helpful, etc, etc… An SSL certificate binds a key pair to an identity, hence the need for users to make their own decision on who to trust.
I don’t disagree with the point that certs bind identity and not trustworthiness. That’s not the point. What is at issue is that no one has ever bothered to inform the end-user of that fact. If anything, the contrary is true. End-users are reassured that all is well so long as the happy-lock SSL icon appears. Accordingly, if the End-user is going to be responsible for “trust,” then something has to change, and someone should undertake to inform the end-user of the end-user’s “trust” obligations–at least if that someone wants to have any hope of having the notion enforced by a court. The idea that end-user “obligations” can be buried in technical specs that are posted on who-knows-what-websites, and thereby legally bind the end-user, is absurd.
What a bunch of lawyers! Do you really think sticking another legal disclaimer in users’ faces will make them better-informed?
When I click on the lock icon in a TLS session in IE I see a link to “Certificate Information.” If I click on that there’s a button for “Issuer Statement”. This brings me to the Relying Party Agreement for the CA. Since Google Chrome uses Windows certificate management it is essentially the same.
Firefox isn’t as good: click on the lock, click on the More Information button, then the View Certificate button, then the Details tab, then on VeriSign in the hierarchy then the Subject field and one of the data items is “OU = Terms of use at https://www.verisign.com/rpa (c)09″. It’s not even a link, you have to copy/paste this to the browser. This isn’t surprising, as Firefox is generally 2nd-rate at PKI issues.
Perhaps you’re all dissatisfied because you’re all using Firefox?
The user’s different experience in IE doesn’t amount to any difference from a legal standpoint. The reason for this is because users are never told to click on the lock icon. And, why should they? There is no text that says: “You will be bound by the terms and conditions of the replying party agreement if you continue; so click here for a copy of the agreement.” There is no denying that the enhanced functionality embedded in IE is probably a good thing. The problem for the CAs is that the functionality, for all its cuteness, doesn’t do the one basic thing that it needs to do for the CA: give notice to the end user that there is a legal agreement lurking beneath. Instead, one has to guess that there is something meaningful or important behind the lock icon. There is nothing about the lock icon that says “please click on me to find out your legal obligations.”
PS – Fermat was lawyer.
This is what Extended Validation certificates are for and should be communicated with the user. Domain validated is just that, domain validated. You have some certaintly you are talking to ‘that domain’, who owns that domain, etc. is left unclear.
As we have “all” come to know is that the CA’s are numerous and thus domain validated just means “this certificate was issues by CA X, supposedly because they validated the domain”.
Now I do know the orginisations applying for EV-certs are scrutinized a lot more and the number of CA’s that can issue reconized EV-certs are more limited. But don’t know what garantees their are that EV certs work any better than “this certificate has been issued by CA X, supposedly because they validated the combination of domain and organisation”.
The problem with EV certs, from a legal perspective, is the same as with domain certs: end-users are not put on notice of the existence of the “relying party agreements” and “certification practice statements” that purport to govern (and limit) the end-user’s rights. The legal regime for EV certs has the same defects as the legal regime for domain certs. Additionally, although EV certs are supposed to be the subject of millions of dollars in insurance protection for the benefit of the end-user, the CAs that I contacted would not provide a copy of the insurance policy or declaration sheet so that I could verify the amounts of coverage, the identity of the carrier, and the policy’s terms and conditions. How can an entity that is in the business of dispensing trust withhold the very documents necessary to verify its assertions that it is supposedly protecting end-users?
You say there is no way for the end user to “register his or her acceptance or rejection” but in order to reject a CA you merely delete all certificates in your possession that link back to that CA. In order to accept the CA you use the certificates signed by them… the power is very much in the end user’s hands.
However! Most browsers don’t make certificate management particularly easy for the end user. This situation is improving, but one could validly argue that with large numbers of fresh browser users turning up every day, the majority still will have no idea how to manage their certificates. That’s not really a legal limitation, it’s an education problem.
Thinking on this matter further, and replying to my own post, if there was a standard method for fetching the T&C of any given CA, then it could be built into the browser certificate management that for any certificate you happen to be using, you get a button to check T&C and then click “Agree” (then the browser activates the certificate) or “Disagree” (then the browser deletes the certificate). There are already standard methods for fetching revocation lists so all the pieces are currently in place.
Presumably the T&C would itself be just a web page, with some simple way of getting from the CA name to the T&C page. This could very easily be figured out with a bit of help from the browser teams.
The terms and conditions fetch would certainly be a step in the right direction. I would add that if the CA wants its terms and conditions to be binding on an end-user, then either the browser or the subscriber website needs to (in addition to enabling fetch) affirmatively put the end-user on notice that he or she is about to rely on digital certificates issued by such-and-such CA. This could be done with either a statement or link on the subscriber website or a notification triggered by the browser. The type of notification needed may (unfortunately) vary from state to state. For some states, a click-and-view agreement might be necessary. For others, the mere appearance of a notification and link to the terms and conditions might be sufficient.
What happens on shared computers with this click-and-view thing? Such as browsers on library computers? Or if I use a computer at my friend’s house? What if my friend made a bad decision about which CAs to trust? Am I bound by what they’ve agreed to (and haven’t explicitly informed me of)?
I think this is a good point. I would note also that although the end-user has the technical option to “untrust” a CA, that option cannot be used to “reject” the terms of the Relying Party Agreement or Certification Practice Statement because the end-user is never put on notice of the existence of those documents. “Rejection” by untrusting is only meaningful if the end-user is, in the first instance, aware that there is something to reject.
Thanks for the intriguing blog post.
The post concludes by stating that this legal structure is not to anyone’s benefit. Well, that doesn’t sound right to me. Surely it’s to the CA’s benefit. Hey, it doesn’t hurt to throw in some bogus legal disclaimers; if there’s a 1% chance that they stick in court, it’s worth it to the CA. It seems clear that these terms are designed to try to benefit the CA, at the cost of the end users and others. That’s deplorable, and the CA’s rightly deserve all the criticism they get for playing these games.
The commenter notes that a CA might enjoy a remote, “1%” chance of being protected by the Relying Party Agreement or the Certification Practice Statement (as against the end-user) and that this “1%” chance of being protected makes issuing these documents beneficial for CAs. This is untrue. What CAs fail to take into account is that while the Relying Party Agreement and Certification Practice Statement have a 99% chance of failing as contracts (relative to the end-user, according to the commenter’s math), those same documents succeed quite well in describing the end-user as: (i) a party at risk if authentication goes awry and (ii) the party for whose benefit the authentication process is intended to inure. In other words, the very documents which are intended to make the CA contractually immune to loss (and which appear to fail utterly in that regard), ironically paint the end-user to be a foreseeable plaintiff to whom a duty of care might be owed under applicable tort law. Thus, the CA’s would-be contract documents are bad for the CA as well. The documents are supposed to limit the CA’s loss and liability, but they might instead simply create a cause of action against the CA in tort.