Eddy Nigg wrote: > On 10/10/2008 01:45 PM, Ian G: >> Finally, if it ever did get to court, I don't see any good reasons >> why it would not stand up? > > > Well, I prefer to refrain from commenting on this, but the fact that I > mentioned it could give you some hint ;-)
Sounds a bit like the RIM/Blackberry case, "right" and "might" and
"justice" was on their side, all the way up to a $600m settlement :)
I don't think anyone wins by relying on hints and hopes. In a
business setting, it would be gambling at best to rely on the basis
that an agreement "might" be struck down if it ever needed to be
tested.... We need certainty.
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process. This is already explicit
in that the CPS must be provided, and is implicit for other key
documents. We might just want to recognise that the RPA or similar
forms a very important part of that which we call the overall "CPS
package".
Once so declared, it is agreed that this is "the agreement". That
reduces uncertainty, because the CA, Mozo, and the reviewing
community agree that it was the document; this only leaves the poor
end user with the possibility of saying otherwise.
Does that make sense?
>> ( 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.
>
> Actually the request made by the CA to have their root included
> is/should/might be interpreted as a waiver for any special requirements,
> agreements, conditions except if specifically conditioned in the bug.
??? That I don't follow. How can a request for adding a root be
interpreted as a waiver? Special requirements?
My basic default expectation is that, if there are any waivers, they
would have to be specified in the bug request. They would have to
be clear to the community.
The community might not agree to them, but at a minimum, we should
know, right? Point 2 of the policy says that.
Otherwise we would see all sorts of issues arising. The notion of
there being unknown waivers and exceptions would rip the guts out of
any public faith in the process, I would think?
But I admit to not understanding, can you rephrase?
> The inclusion request is obviously an implicit agreement. I suggested in
> the past to have CAs
>
> - make a request also in writing
They do make a request in writing; it is the bug filing.
> - provide audit statements, root certificates and other documents in
> hard copy
+ I saw Gerv mention that the CAs have to provide a digital copy
from the auditor's website or email address. That's IMO good enough.
+ Root certificates are provided, otherwise it wouldn't work :)
+ Hard copy is not necessary; what is sufficient is clearly
designated digital copies. If this is an issue, ask the CA to amend
their bug to add the hash of each digital copy uploaded or mailed.
This doesn't need to be in the policy, it can be working practice,
and the Mozo people can do it as well.
> - sign a standard agreement with Mozilla
This then is a good point. There is (AFAIK, me not being Mozo) any
real *single* agreement in a document form.
Should there be?
Yes: it would allow mozo to protect themselves and their users.
it would allow mozo to establish some baseline things (e.g.,
Nelson's comments a few weeks ago about one standard for all CAs).
It would allow one law (choice & forum).
It would allow some standard no-no clauses.
It would simplify the complications of deciding what was in the
agreement and what was just "wiki chatter".
It would allow Mozo to push some CAs to tighten up their game.
No: it would cramp the style -- slow down the development of
things, as a single document has a lifetime of 2-8 years.
It would subject us to a long argument as to what it should be.
It would shift the power around a bit (EV v. Mozo v. big CAs).
It would offend the techies. It would empower the lawyers.
It isn't Mozo's policy nor style to slam an EULA on everything.
Each CA is so different, it should have a different agreement.
The browser is the proxy (relying? using?) party for the user and it
is up to the CA to lay this down to user and browser alike.
(yes, big long open question. luckily nobody is paying me to answer
it today!)
> This is the common approach with all major browsers besides Mozilla.
(Might be true, not sure how relevant it is. Copying others isn't
always the smart thing to do.)
>> 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 ?
>
> No, but a user can easily prove that by using the browser he adheres to
> the RP obligations (except if he overrides the browser configuration -
> adds an exception)
This is the same thing, just the other side of the coin. Who then
provided this software? Who then sets up this "adherence to RP
obligations" ? Who understands them, who wrote the code to do that?
>> So, what happens in any real case? If grandma stands up and says "I
>> don't know how, but I was robbed!"
>
> That's not a case for the CA. Grandma has to sue the party which robbed
> her. Provided that there was no flaw in the certification, the CA is
> clean and not party of such circumstances.
OK. Two things:
We agree that there is no special duty of care for certificates (as
opposed to a general duty). That's an important point, because it
might be that the only way to establish standing for a user in any
cert dispute is through some special, cert-related duty of care.
Secondly, a "flaw in certificates" ... is a pretty small attack
surface. If we are entirely agreed on that, this simplifies a whole
lot of stuff.
For example, the old hope of secure browsing is that these things
will authenticate a site to a user. Or, as some adverts have it
(below) the certs will apparently say that the site is secure.
That's a big difference from "no flaws in certificates".
It would be nice to agree which it was. Then, we could simply
allocate the liabilities left & right of that statement, and
everyone would be a lot better off.
>> 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
>
> No, that's not the case, but I'm not really inclined to give ideas here...
Sure. We all have our interests and hopes. But, let's look at it
this way.
It really doesn't help anyone in this forum to protect or downgrade
or mystify things... because these uncertainties rattle through time
until they become failures.
So, assuming that it is not outside ones interest to make things
more certain, what ways can we come up with to clearly make the
agreements of all CAs more certain?
If not in the judge's eyes, but at least in terms of our agreement
that "this is the document", or as the legal folks say, "the answer
is between these four corners of this page."
>> This is bad, but I think most CAs have stopped
>> doing that so blatantly.
>
> Really? I haven't seen that....
I live in hope, but hopes get dashed more frequently than I dare
admit...
https://financialcryptography.com/mt/archives/001050.html
iang
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
