On 29/12/08 00:36, Kyle Hamilton wrote:
On Sun, Dec 28, 2008 at 6:24 AM, Ian G<i...@iang.org> wrote:
Unlike you, Eddy actually runs a certifying authority. This means
that he has operational experience with not only the technical sides
of things, but also the legal sides of things.
I support your right to an opinion, but can you please ground your
criticisms in facts of relevance, rather than ad hominims.
Just because you also happen to be an advocate for CAcert
Strawman. An Auditor is perhaps an advocate in the sense that he writes
an opinion. I have not done that, and won't for another 6 months at
current progress. Here's *just* the local dirt:
https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158
I think the advocacy claim looks a little silly, no? Absurd, even.
(and --
unlike Eddy -- feel the urge to hide that affiliation) does not mean
that you actually run it, or have the depth or breadth of knowledge
necessary to do so. This message shows me that you honestly don't
care about what "security" actually is, you just care about "the
end-user experience". This is NOT the same thing. As such, my
opinion of your authority on the subject matter has diminished
severely.
You are entitled to your opinion, but I would ask you to consider that
this is a policy forum, not an ad hominem shooting match.
True "security" involves knowing what the risks are. Mozilla's policy
for root inclusion tries to reduce the uncertainty for end-users;
unfortunately, as has been pointed out repeatedly, there is still far
too much uncertainty for end-users in Comodo's operations.
The point I have made is that the discussion of Comodo's operations is
outside scope of this forum. You may feel that you have an opinion, and
you have a right to it. However, this forum is not for the
investigation of breaches or failures to comply with policies.
If you dislike that, don't start a war against me. Suggest a policy
change to Mozilla. If you want wordings, try this:
x. Any breaches of security or failures to comply will be
discussed in the policy forum of Mozilla, a ruling by consensus
delivered, and will be binding on the CA.
Don't disagree with me in a post, do something. Write the proposal,
change the policy. Words are less important than acts.
They have
lost my trust, the same way that you have.
Now over to you. Act, not talk. Make a dispute resolution forum happen.
On 28/12/08 14:21, Eddy Nigg wrote:
On 12/28/2008 02:46 PM, Ian G:
1. Certs: All end-users who rely on these certs will lose. That probably
numbers in the millions. All subscribers will lose, probably in the
thousands. The CA will lose; potentially it will lose its revenue
stream, or have it sliced in half (say), which is what we would call in
business circles a plausible bankrupcy event.
Not relevant.
Well! If they are not relevant, then perhaps we can turn SSL off, with no
consequences?
If Nelson can upbraid me for ad hominem attacks, I'm going to upbraid
you for ad absurdem arguments.
TLS (can we PLEASE stop using "SSL", since the last version of SSL
that got ratified by any standards organization was SSLv2, and SSLv3
is a hack that reached internet-draft phase but was never formally
recognized?) has the option of negotiating a secure connection without
the use of any certificates at all. (Further, SSLv3 also had the same
mechanism.)
There's still the "endpoint confidentiality" concept -- nobody between
the client and the server that the client is talking to can hear
what's being said between them. The problem that certificates (or key
continuity management) is designed to solve is the problem where the
client thinks it's talking to one server, when it's really talking to
another (the "fraudulent endpoint" attack in the case where the
server-endpoint doesn't pass any data to the real server, and the "man
in the middle" attack in the case it does).
Er, Kyle, you are off on a tangent here. My point with Eddy was fully
addressed by him pointing out that he was only dealing with the last
sentance, I thought he was referring to the earlier sentances. A
reasonable clarification.
To ignore the obvious legal ramifications (agreements in RPAs, disclaimers
to end-users, potential lawsuits ...) would be negligence, IMHO.
We know the ramifications exist. We know they may be serious. We know that
assertations of security are being made to end-users. Hence to continue
making these assertations, and not treat them seriously would be negligence.
I personally choose not to follow that path into negligence, and will
continue to consider the legal ramifications, which leads to the question of
how we consider them.
In my mind (and this is not legal advice, merely a statement of
thought presented for the purposes of argument), Mozilla has a duty to
me as an end-user to uphold the letter and spirit of its CA
Certificate Policy. I've already presented my thought on how a full
tort could be brought against Mozilla by the operator of any CA
already in the trust list. If a Comodo-issued certificate causes any
user damage after the initial disclosure on the list, a tort could be
brought against Mozilla by that end-user.
I do not disagree! My point was that Mozilla also has a duty (however
arrived at) towards the CA.
Let me cast in simple terms. In this particular question, the CA talks
to the Mozo. The user doesn't even know to talk. The CA wins.
This is reality. I don't like it. I've been talking about what you say
for the last 4 years, and it hasn't happened.
Mozilla has no legal or any other requirement (as far as I
know) to include or keep a root.
No, I'm afraid there is an agreement to list the root, under a policy. Once
listed, Mozilla has to operate according to its side of the bargain.
The policy explicitly provides for Mozilla removing a root, at its
option. Section 4 of the CA Certificate Policy: "We reserve the right
to not include a particular CA certificate in our software products,
to discontinue including a particular CA certificate in our products,
or to modify the "trust bits" for a particular CA certificate included
in our products, at any time and for any reason."
(By the way, I was there when that section was written. I may even have
suggested some of the text? Now I don't like it. I want it changed. I
want it strengthened. What wrong is that?)
It gives examples of the situations that it could do so in, but it
also explicitly states that its appropriate reasons for doing so ARE
NOT LIMITED TO those examples.
Please also recognize that the right and protection of the many tends,
at least in the US court system that Mozilla and Comodo are subject
to, outweighs the right and protection of the few or one (the company
which operates the CA).
This is where we make a judgement call. You call your estimated risks
and costs. I call mine.
None of us win this game. It only gets won in court.
Agree to disagree; think about the other side's point.
This is a general consequence of business, there is nothing special about
it. Ask any experienced business person.
It may be -- but since this is a case where this certificate in
Mozilla's root store was included for the purposes of identifying
websites for the purpose of enabling commerce, and thus it had to
operate under the WebTrust Principles and Criteria for Certification
Authorities -- and in this case, since the root is also EV-enabled,
WebTrust for Certification Authorities—Extended Validation Audit
Criteria... well, any conduct which provides reasonable doubt as to
the viability of its certificate issuance policies (and, in this case,
such reasonable doubt exists) suggests that people who rely on
Mozilla's adherence to its CA Certificate Policy in deciding to trust
Mozilla's root list are relying on bad information.
It's not much of a stretch to imagine that Mozilla is essentially
violating a fiduciary duty if it doesn't remove the trust bits or the
CA itself from the trust list.
I agree.
The problem is, the other theory exists as well. They get to be argued
out in the next forum: court.
As a particular point, it states that it reserves the right to remove
CAs for any reason. It does NOT state that it reserves the right to
NOT remove a CA.
Mozilla can certainly reserve the right to remove the root. It can even
remove the root.
This however doesn't mean that it is protected from damages.
There is no disclaimer. No statement of warranty.
Join me in fixing these problems; don't shoot me because I bear an
uncomfortable message. If you shoot me, it isn't me that loses, it is
Mozilla.
The Mozilla CA Policy clearly reserves
the right to remove any of the roots (including all of them) at any
time. If this isn't the case we all should know about it.
The problem being, that even if it reserves the right to make a choice for
any reason, this does not give Mozilla carte blanche. If it makes a bad
choice, a judge can imply a "reasonableness" test.
Is it reasonable to expect that a CA which is theoretically audited to
financial certification standards, and is shown to have insufficient
controls to maintain those standards, can stay in a position where it
can cause financial harm to relying parties?
Look, we can all have our day in court, and argue as long as our legal
budget holds out .... the point is, is this what you are going to argue?
Does Mozilla wish to have its day in court?
This is not about what is RIGHT but about what happens in COURT. These
are two completely different things.
As it stands, we do not know how many RAs Comodo has engaged. We do
not know what types of certificates those RAs can submit requests for.
We do not know how many of these have chosen to ignore the
contractual obligation.
And it's entirely possible that Comodo is relying on the "must
internally audit at least 3% of EV-enabled issued certificates" as the
standard for its "representative sample" (a charmingly vague term
which suggests that a single request could be reviewed as a
"representative sample"). The audit requirement only applies to
ISSUED certificates, and there's no requirement that even 3% of
requests received from each RA be reviewed/audited. (not to mention,
even if they did audit 3% of each RA's submissions, it just means that
out of 100 submitted requests, only 3 need to be reviewed. Put
another way, 97 out of every 100 submitted requests could be bogus and
Comodo wouldn't have any idea.)
This is why I advocate more openness as regards the processes.
Without that openness, I have absolutely no reason to trust Comodo.
I agree. It sucks. But, all of your complaint directly above is OUT OF
SCOPE. We are not invited here to audit, check, confirm or review any
RA or any CA. That right is reserved to MOZILLA and the CA's AUDITOR,
in the policy.
We are only here to talk policy. And in the "week of review", comment
about the CA of the week.
Yes, propose we open up the audit process. I'm all for it, and I do it.
But there is no way that I can compromise Mozilla's process by
overstepping the line. I am an "interested party," an opinion of mine
will one day be here. I must read the policy and follow it. I cannot
support an unfair attack on the process.
You have to change the policy and practices before you have any standing
in addressing the Comodo question.
That's my opinion of course. Until we find different. I'm waiting and
ready to be corrected by someone who does have authority over the forum.
3. Industry: All other CAs will lose because they will now have to
include in their business plans the possibility of a root being dropped
by a bad decision.
Very good! Even though I'm not the proponent of the proposal to remove
Comodo's root (instead work towards a real improvement, with the removal
as a stick), this is exactly what possible removal should achieve.
Please read it carefully. a root being dropped by a BAD decision.
My opinion is that this instant case would not be a "bad" decision.
However, this would also be something that I'd suggest talking to the
lawyers about. (I also tend to think that a waiver of attorney-client
privilege would be appropriate, in this case, to promote the goals of
"public process". However, my opinion does not control, and it
doesn't come from a lawyer anyway.)
Yes, talk to the lawyers. "BAD" is subjective of course, until the
judge rules, and then it is fact.
[competitive / marketing talk deleted]
[dispute with comodo deleted]
2. There is the possible benefit to the other CAs as a punishment tool,
in the case where the decision is good (see 3. above). There could be a
knock-on effect in convincing CAs to tighten their game.
Right! I'm all in favor of that, lets go for it!
Well, that is the expectation of some people. I suggest it is hopelessely
unfounded, in business terms, and may achieve more damage than good.
This is, by the by, one reason why X.509's single-certificate-issuer
model is (in practical terms) severely flawed. If a given certifier
becomes untrusted (especially since there's a prevailing view that
trust is 100% or 0%, evidenced in an argument against the creation of
a "trustability in doubt" flag), there is no way for an affected
certified entity who has followed all the rules to mitigate the damage
caused by their certifier's state-change from "trusted" to
"untrusted".
Right. Hence overly massive attention on what is a BAD decision, and
what is a good decision.
However, this
needs to be balanced against other costs and loss of certs, and in
practice, the dominant factor is this: more certs is more security, less
certs is less security.
Less unvalidated certs is more security, not less. An unknown number of
unvalidated certs is no security at all.
Yes, we are now getting into the difficult area of estimating the overall
benefit of different models of security. This game is well known to be
controversial. Let's leave that aside for now.
I don't believe that we can.
Mozilla's CA Certificate Policy includes the language "[...]based on
the benefits and risks of such inclusion to typical users of those
products" in point 1. That means that it's an essential aspect of
this debate.
Everything beyond that is subject first and foremost to that criterion.
Well. I don't disagree. But I try to avoid battles that cannot be won
by either side :)
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
