CA liability has been focused on the RP since it an RP that "trusts" a CA and its certificates, right?
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. IMO it would be more reasonable to make CA liability an affair between the subject subject (subscriber) than towards unknown RPs. In some way I understand why banks when acting as CAs essentially *never* accept dealing with unknown RPs... Regarding "accumulation" in the referred PKIX RFC, I mean the sum of all transactions, break-ins etc. an incorrectly certified entity could perform. At least from a CA liability point of view that's the most interesting part. An identity certificate <<>> credit card because only the latter allows comparatively simple damage control using account monitoring. Anders ----- Original Message ----- From: "Ian G" <i...@iang.org> To: "mozilla's crypto code discussion list" <dev-tech-crypto@lists.mozilla.org> Sent: Thursday, December 18, 2008 17:00 Subject: Re: Publishing CA information documents in PDF format On 18/12/08 13:20, Anders Rundgren wrote: > Kyle, > I fully agree with your conclusions. > IMO a signature's primary function is to provide a mark of authenticity > to something. If the signature is associated with an unknown signer > the value of the signature becomes rather limited. > > The Qualified Certificate concept is based on the strange idea that > because the CA is liable to very high amounts of money, you can > "trust" such signatures and thus do advanced business with total > strangers. This is based on the monetary view of reliability, in that it is only worth what you can get for it. Standard finance principle. If there is nothing, it is worth nothing; if you can do harm X then it is worth X, potentially; if you can get Y then it is worth Y, potentially. (Case in point about a year ago, oh how soon we forget, is S&P, Moodys and the rating agencies.) This I find to be quite a valid view, and it is widely used in the corporate and finance world, c.f., NPV, MTM, CAPM, where numbers are called for. Although it certainly doesn't explain all of contracts & agreement behaviour. Whether you can take that monetary number and relate that to "trust" is a whole other discussion... And, we probably agree that the end result with Qualified certificates is likely to show the same as with non-QCs, in that the resultant value to relying party in objective monetary terms is zero. (In other posts I have expressed the opinion that the expected liability is zero, which is another way of saying it.) > What the designers of QC didn't think of is that anybody > can get a QC without being checked to be a good payer, dependable > vendor, etc. If there is discomfort in a business relation, the CA has > no means to rectify things making the value of the high liability very > limited. > > IF people started to believe that QC actually works as described we would > soon be in a very bad position since a single disgruntled employee could > send "fully authorized" POs all-over-the-map. Yes. But companies and people are generally smarter than that. They know the monetary value is zero, and non-monetarised values are limited to the regulated needs, in general. > PKIX took this to another extreme by publishing an informational standard > for liability with is one of the most ridiculous things I have ever seen > http://www.ietf.org/rfc/rfc4059.txt > since it doesn't deal with accumulation!!! The motive behind this RFC > was "to increase the acceptance of certificates" :-) Perhaps you could explain what you mean by accumulation? I skimmed through that document, and had my own qualms. Q: does any CA actually use that extension? Does any code display the extension? I note that it "must be non-critical" which I find amusing :) iang _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
