Ian G:
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process.
That might be a good idea...actually that's what I assume when a CA
makes a request for inclusion (but on the other hand, no CA has yet
confirmed or signed an agreement in this respect with Mozilla).
This is already explicit
in that the CPS must be provided, and is implicit for other key
documents.
...not sure which other key documents you refer to...there is no such
requirement per se.
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
Does that make sense?
I think it does.
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?
By requesting to have the CA root included and by the nature of Mozilla
being a relying party (yes, yes, it is..) it can be assumed that because
no special requirements were tied to that request (like, please also
confirm our XYZ agreements and conditions) Mozilla is not bound not
bound to any agreement set up before, during or after the inclusion.
I expect that the RP obligations in the CP/CPS are the binding
requirements, but not any other additional agreements - since none have
been forwarded during the request. But the legal department of MoFo can
answer these questions better.
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.
I think it's the other way around. With making a request for including a
root, any additional agreements, conditions etc. not brought forward
during the document gathering period or upon initial request for
inclusion are void (and the request itself represents a waiver of any
special agreements, conditions or requirements).
The community might not agree to them, but at a minimum, we should
know, right? Point 2 of the policy says that.
Obviously any agreement, condition or requirement tied to including a CA
root must be disclosed during request. Otherwise they are not binding
for Mozilla.
They do make a request in writing; it is the bug filing.
Nonono...it's still harder to prove than with hard copies. A CA can
claim that the request or anything else within the bug (like comments)
were modified, tainted etc. Bugzilla is under the control of Mozilla and
hence its use in court is questionable to some extend.
+ 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.
And you believe that our NSS/CA Policy team archived CP/CPSs and audit
statements upon approval? And you believe that they remain there forever
at the auditors web site? And you believe CP/CPS don't change (or can be
modified, including removal)?
This doesn't need to be in the policy, it can be working practice,
and the Mozo people can do it as well.
Sending the root printed in paper would be just an added benefit...if we
are already mailing hard-copies...
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.
I can't befriend myself with the contra arguments...none are really
valid...CA is not that much about technology, style and a lot about
legalities if we are at it...
(Might be true, not sure how relevant it is. Copying others isn't
always the smart thing to do.)
However the "others" aren't always idiots either...it's good to learn
about what others do and come to a decision if it's also good for you.
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.
Except if the CA says otherwise - something which is obviously disclosed
in the CP/CPS (and reviewed by Mozilla). For example this forum and the
comments period are excellent tools to report on them if they exist.
Secondly, a "flaw in certificates" ... is a pretty small attack
surface.
But an important one. This is what CAs are here for. But what CAs have
to do in order to remain flawless is beyond this exchange of thoughts here.
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.
That's over-simplified perhaps...liabilities is really only part of the
story, isn't it!?
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.
You are talking about one specific agreement set up by one specific CA.
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."
The four corners are in the Mozilla CA Policy. It clearly says what CAs
must do and can't do (in order to be shipped with the software).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
