On Sun, Dec 28, 2008 at 6:24 AM, Ian G <i...@iang.org> wrote: > (following is just for the record so as to deal with the response. No new > info is in here for other readers.)
I would very much appreciate it if you would stop using fear, uncertainty, and doubt to manipulate the audience into believing your and only your viewpoint. 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. Just because you also happen to be an advocate for CAcert (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. 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. They have lost my trust, the same way that you have. > 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). > 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. >> 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." 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 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. 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. >> 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? 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. >>> 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.) >>> 4. Security will go down, because less certs are delivered and in use. >>> (It's hard to calculate the secondary losses here, but not impossible.) >> >> That's easy to revert, I'm certain there are a bunch of CAs ready to >> issue new certs to them. > > > That's hopeful marketing talk, not security analysis! It can be accepted as scripture that there are a bunch of CAs ready and willing to issue new certificates to entities who can pass the validation requirements of the WebTrust guidelines, if they can cough up the fee. (and there's at least one CA which is ready and willing to issue new certificates to entities who can pass the validation requirements, without coughing up any fee.) If there's another CA which is willing to issue certificates to entities who CANNOT pass the validation requirements of the WebTrust guidelines, even if they cough up a fee... well, I'd very much like to know about it. I'm sure the rest of those who are actually concerned about user security would like to know the same. >>> 1. Against that you can weigh the damages done so far and the harm to >>> protect against. We know it is down to 11 or so certs, all revoked. >> >> That's absolutely not correct. Right now nobody knows - including Comodo >> - how many certs are really unvalidated because of the lack thereof. > > > They stated how many, IIRC. I recall it was something like 111 certs issued > and 11 outstanding that had not been re-verified within around 48 hours > (these numbers are not accurate, but indicative) and were therefore revoked. > > Are we disputing their stated claims? Or are you making a wider claim that > their entire cert base is unverified? Or? I am making the claim that CertStar, as a registration authority, submitted requests for at least two certificates which were not appropriately verified. I am also making the claim that this is indicative of a lack of effective control in Comodo's processes, and that this calls into doubt ALL unreviewed registration-authority-submitted requests, regardless of company affiliation or contractual obligation. This view is shared by many security professionals, not all of whom are on this list. >> This is what I know at the moment and it would be good if Comodo could >> dispute that claim and advice differently or confirm it. >> >>> 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". >>> 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. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
