On 12/18/2008 2:09 PM, Ian G wrote: > On 18/12/08 18:25, Anders Rundgren wrote: >> CA liability has been focused on the RP since it an RP that "trusts" a CA >> and its certificates, right? > > > Um! > > If one takes a PKI view, then there exist 3 main parties: CA, RP, > Subscriber. However other views exist. Liabiliy is an issue at law (in > that it is ultimately pyramided on a decision found in court) and > liability is seen as (a) found in any contract / agreement, (b) torts > where no contract / agreement exists, and perhaps (c) where stated in law. > > (That's my current understanding; I'm no lawyer.) > > So we can look at both those. Classically in PKI, a CA has an agreement > with RP and subscriber, and this will generally nail down the liabilities. > > However, secure browsing, secure email, etc (the Internet variant of > PKI) do not follow the classical PKI view. Subscriber is the same. RP > is split into three parties, potentially: RP-with-agreement, vendor, > end-user. > > So, the question is, how is liability handled in these three cases. To > cut a long story short: > > 1. The RP-with-agreement is covered well by most CAs' RPAs. > 2. The vendor is uncertain. > 3. The end-user is left in the wilderness. > > The vendors are all almost big enough and ugly enough to look after > themselves. The courts would view the vendors as responsible and well > informated parties. E.g., they would have their legal counsels, and > often they are as big or bigger than many CAs. So, ignore 2. > > The end-user however is not big, is a consumer, and is at the end of a > slightly fraught chain of retail distribution. For example, a user of > Redhat Linux might be using certificates in Konqueror, using the Mozilla > root list. When it gets hairy for her, who does she go to? > > And, for various reasons she is subject to myths & marketing, some of > which might stick. > > It is this situation that leads to the suggestion that the vendor (in > the above, Mozilla, KDE, and Redhat all) follow the industry standard of > setting the liability to zero, so at least there is a unified standard > understanding. > > >> A problem with this notion is that there is no end to what a wrongly >> certified >> entity could cause in damages, particularly not for "eID" kind of >> certificates >> that potentially opens any number of doors. The obsession with signatures >> has also been extremely contra productive; authentication is 100 times more >> important since it cannot be "rolled back", "repudiated" etc. > > > Right. However, as the liabilities are set to zero by the CAs (*), this > is the baseline. Tn the above, although there is a theoretical "massive > damages" by a rogue cert + scammer, the real liabilities are zero to the CA. > > So the only issue is whether any of the mud sticks to other players. > > > > (*) except in the case of qualified certificates. Frankly, I'd rather > ignore them, they are an oddity! > > >> IMO it would be more reasonable to make CA liability an affair between >> the subject subject (subscriber) than towards unknown RPs. > > Well, it already is, to the extent that the CA and the subscriber have > an agreement which specifies liabilities. This is easy, because in the > normal course of business the CA and the subscriber strike up a > relationship that is naturally turned into a contract. > > The problem is, the subscriber might have disappeared (and likely will > in the canonical case of "massive damages") ... which leaves the RP > talking to who, exactly? > >> In some >> way I understand why banks when acting as CAs essentially *never* >> accept dealing with unknown RPs... > > > Yes, this is business (that word, again). > >> Regarding "accumulation" in the referred PKIX RFC, I mean the sum of >> all transactions, break-ins etc. an incorrectly certified entity could >> perform. > > > I understand that. > > My quick skimming of the RFC indicated there was something there for > that, but I'm not going to endorse the writings that I skimmed; anyone > who thinks they can do legal work through RFCs will be taught a harsh > lesson. I agree with you, that RFC was a hopeful piece, and hopefully > is better off forgotten. > > >> At least from a CA liability point of view that's the most interesting part. > > > Um, is it? I don't see that. The CA sets it to zero, why is many times > zero interesting? > > ;) > > >> An identity certificate<<>> credit card because only the latter allows >> comparatively simple damage control using account monitoring. > > > They are very different beasts, yes. It is not easy to compare them at > a real liability level, no matter how attractive it seems. > > >> Perhaps you could explain what you mean by accumulation? I skimmed >> through that document, and had my own qualms. > > > Thanks, answered. > >> Q: does any CA actually use that extension? Does any code display the >> extension? > > > I'm thinking not. > > iang
See the thread "Unbelievable" in this newsgroup. Now we have the situation in which Comodo allowed third-party CAs under its root to issue site certificates without proper authentication of the subscribers (e.g., whether they actually owned the domain). Apparently, Comodo failed to enforce its own CP/CPS with regard to the operation of external CAs for which Comodo signed their intermediate certificates. It is known that bogus site certificates did indeed result (at least for testing to determine if the situation was really happening). Now, what is Comodo's liability to consumers if any of those consumers were defrauded through this situation? I too am not an attorney. However, it seems to me that any denial of liability by Comodo might be nullified by its failure to enforce its publish policies. -- David E. Ross <http://www.rossde.com/> Go to Mozdev at <http://www.mozdev.org/> for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
