Eddy Nigg wrote: > On 10/10/2008 01:48 AM, Ian G: > >> IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED >> TO USE VERISIGN INFORMATION AS SET FORTH HEREIN. >> >> https://www.verisign.com/repository/rpa.html >> >> Now, curiously, unless we agree to that text, we can't even rely on >> that agreement, let along certs, due to its broad commentary, my >> emphasis above. That even applies now that the RPA is delivered >> under a pretty green cert ;) > > It's certainly an "interesting" approach Verisign took here...I think > Rick Andrews happens to be on this list or somebody else from Verisign > can comment on it. > > However for what it's worth, the agreement itself is more or less what > I'd expect (rpa.html). The RP obligations are reasonable: > > As a Relying Party, you are obligated to ensure the reasonableness of > your reliance on any VeriSign Information by: (i) assessing whether the > use of a Certificate for any given purpose is appropriate under the > circumstances; (ii) utilizing the appropriate software and/or hardware > to perform digital signature verification or other cryptographic > operations you wish to perform, as a condition of relying on a > Certificate in connection with each such operation; and (iii) checking > the status of a Certificate you wish to rely on, as well as the validity > of all the Certificates in its chain. > > In the end of the day all the legalities are only necessary in case > something goes really wrong,
Right, there are two ways of looking at software, like certs or any
other. What does it help to make go right, and what happens when it
goes wrong?
We need to consider both cases; the former view is that the
software should make more things go more right, the latter view is
that it should present some form of fair & efficient resolution.
If we ignore either side, we will end up unbalanced, and we fall over.
> in which case an RP might or might not be
> tied to this agreement (it still has to stand up in court first).
Well, it's worth walking through the possibilities, just to see this.
First, for the last decade++ it has stood up because it has kept
them out of court (any cases yet?).
Next. If the RP was not tied to this agreement, what else is there?
The agreement is very clear; you have to agree to it, or *you've
got nothing*. No agreement, no rights. And, especially NO
RELIANCE. Nothing, except perhaps some vague theory that CAs are
good for you, which is nothing.
Finally, if it ever did get to court, I don't see any good reasons
why it would not stand up? There are some "IANAL" thoughts below
[1], but the long and the short of it is that there is no reasonable
case for hoping it will be struck down at your 11th hour.
Sure, anything's possible. Meanwhile, it is best to assume the
(highly) probable case: the RPA is a solid and likely expression of
the situation.
> Also
> Verisign makes explicit reference to their liability (limitations) which
> sounds to me reasonable too. (I'm not here to defend Verisign, but I'm
> commenting on it nevertheless)
Yes, István already described how setting any number other than ZERO
creates a huge problem for the CA.
Basically, all CAs are encouraged to set their liability limits to
the general user to ZERO, and I don't know of any CA that doesn't.
I also can't see how in general it can be anything else.
So why not recognise it? Make it policy, let's move on.
(OK, things may look a little different with EV, but EV does not
control liability, only sets a minimum limit on disclaimers of a
liability value. Lawyers will know these are two different things.....)
>> I'm not Mozilla, so I guess we have to ask: Frank, is there any
>> such agreement that explicitly gives Mozilla permission to RELY?
>>
>
> I think this should be granted. It's a good point, but certainly also a
> solvable one.
>
>> I don't think there is an agreement, and I think the reason is
>> historical, not nefarious, these things just weren't thought about
>> way back when, and it is an acknowledged fact that there hasn't been
>> so much (if any) review of grandfathered CAs.
>>
>
> Yes, even though Verisign went through the same procedures as every
> other CA with their last request for upgrading to EV.
Something like that. There is no "agreement for CAs" posted
anywhere on the site.
( I should clarify things here: there is certainly an agreement
between each CA and Mozilla. It's however not a written agreement
with only one form, rather it is a compilation including:
* the policy,
* and in the case of EV, the Guidelines are incorporated,
* audit criteria,
* any side agreements or historical understandings,
* the filed documents under the ascension process,
* etc.
Either way, none of those suggest any permission to RELY, that I've
ever seen or heard of. )
>> Does it want to impose this on Verisign? Eddy, I guess you are
>> happy to take on that (having expressed those opinions) .. but what
>> about the others?
>
> Lets hear about those...
>
>> (That is my assumption; the authors
>> were probably not directly thinking about certs. Either way, it's
>> the only guide I know of, because the policy doesn't address this
>> question.)
>>
>
> Another good point to pick up...
>
>> OK, I'm not enough of an expert in agency / principle legal theory
>> to fully understand what the above "take care of it" approach does
>> when contrasted with the real agreements in place.
>
> Technically NSS (in Firefox) does perform the RP obligations of the
> Verisign RP agreement. The legal requirements bound to their agreement
> (which doesn't have to stand up in court, but isn't hard to prove either
> when using Firefox) might need some review.
Hmmm...
So, you are saying that Mozilla, by way of its software agent
("Firefox" and/or "NSS") are standing in for some of the risks,
liabilities, obligations expressed in the CA's RPA ?
I guess Verisign agrees, as per (ii), (iii) above in the Verisign
RPA above.
(I agree. The user certainly isn't doing it, and that is more or
less a policy decision by the browser.)
So, what happens in any real case? If grandma stands up and says "I
don't know how, but I was robbed!"
And the CA stands up and says "Your Honour, our RPA is very clear on
this point, and besides, we do not know this woman."
I guess we would need a software expert witness to outline the part
that is played by the browser in verifying and presenting the cert?
Then, the judge could muse on who is responsible.
>> OK, we should check EV to see what it says.
>>
>
> There are no RP agreements but limited liability per RP.
Right, EV sets a minimum liability limit of $2000 (from memory).
However, the essential incentives described above still exist, EV
does nothing to change the economics.
We then need to ask: is there a separate RPA? are there other
tools that effectively reduce liability? Are there tools that
seriously manage a liability of non-zero?
iang
[1] IANAL thoughts on whether a well-written RPA might be knocked down:
A judge might knock the RPA down on the basis that there is a better
agreement, but I don't know what that would be -- certainly the
mozilla agreements and policies, EV, PKI docs and so forth don't
present a better case as to what happens "when something goes
wrong." As we've not come across a better document, it is fairly
safe to assume that the user has not either.
( If we were instead talking about just the CPS, then we could make
a case (and some have) that such a document is not fit; I have not
looked at the one in question, this is a general remark. )
It might be knocked down under consumer protection clauses, but this
is a bit tricky because the user is not a consumer. That is, the
user didn't buy anything, only the subscriber did.
It might be knocked down because it is deceptive, or contradicted by
other claims. Now, in the past, there were many CAs who claimed
things on their websites, like "you can trust our certs" or "our
certs secure you". This is bad, but I think most CAs have stopped
doing that so blatantly. E.g., today, there is a claim that says
"When consumers trust you, trust Verisign!" But that is a message
to the subscriber, *not* to the user nor to any RP.
There is not a lot of applicable law, because most of the CA laws
exclude coverage one way or another. I guess it might be different
in those places where the CA registered as regulated under the state
(Utah?) but they are not so common. Under the European directive,
there might be more law, but it is strongly oriented towards
qualified certificates, and that's a corner case. The advanced
signatures sometimes come in for some protection; but not enough to
be consistent.
There is the "duty of care" theory but I don't see this can apply,
because "what is care" isn't expressed carefully enough, the CA's
position is very carefully expressed, they have a very small part of
the action, there are too many parties, and it has never been tested.
Then, there is the possibility of various class-action style
lawsuits based on actual losses such as phishing. The problem with
this is (and here is not the place to go into it, but others have
heard it before) is that the CA's job is more or less done when the
subscriber is shown not to have phished.
A short answer that is often presented is that they spent a huge
amount of money on legal fees to make this stand up, and it has
stood the test of time. It seems that other CAs have also followed
suit, so maybe the real arguments have been replayed over time, more
money has been spent, and the same results reached.
Well, enough of amateur lawyering.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
