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
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
