You're failing to recognize one thing: if a Growl-like notification came up whenever my browser established a TLS session, describing "This certificate is said to belong to <subject>. The one who's saying it is <Issuer>. BEWARE: this issuer is NOT audited to financial services standards, do NOT put in your credit card or other financial information"... well, I'd be able to see it, know about it, and react to it appropriately.
In fact, this could easily take the place of the "unknown_issuer" and "issuer_not_trusted" errors. (Really, what are we saying there? We don't know/trust the issuer to keep our financial information secure. Why are we bundling 'financial security' with 'any security'?) As for "We aren't really purposing SSL to "just ecommerce" as far as I know..." -- that's a load of baloney. When you look at the history (Netscape partnering with Verisign to provide the lock icon *in order to promote trust in ecommerce* -- remember, this was back just after the Commercial Internet eXchange started, and began taking traffic off of the entirely non-commercial NSFnet), and you look at the fact that every audit requirement that the Mozilla Foundation is willing to accept is based on either the ANSI X9 standards for financial-services certification authorities, the WebTrust standards for the same, or the ETSI standards which are designed to enable the issuance of Qualified Certificates... ...every single one of these standards is for *financial services*. I honestly don't believe that it should be limited to financial services (including due diligence related to providing financial instruments including credit card numbers over the net between the cardholder and the merchant). But, that's what we currently have, because the inertia is so entrenched that nobody has ever been able to convince the browser vendors that it might even remotely be a good idea. (in fact, it wasn't until a LOT of people got infuriated at Netscape over the Verisign tax that other CAs were even allowed into the program -- but every one of them was vetted to the same extent Verisign was. Now, Mozilla, as the direct descendant of that code base and mentality, has kept the same thing.) -Kyle H On Tue, Dec 30, 2008 at 3:43 AM, Ian G <i...@iang.org> wrote: > On 29/12/08 19:28, Ben Bucksch wrote: >> >> Background: CertStar issued certificates without verification >> whatsoever. The faulty certs were signed with the PositiveSSL >> certificate, which is chained to the UserTRUST root cert that Mozilla >> ships. The UserTRUST cert is owned and operated by Comodo. >> >> Our policy mandates that CAs have a valid audit to prove that they do >> diligent verifications. > > > Audits provide an opinion. Literally, they provide this opinion over checks > over a "management assertion". More practically, they follow a set of > criteria, and general practices and principles, as well as the "management > assertion." They also generally include language -- code -- that indicates > the limitations. Sometimes these limitations are quite broad. For > particular example, Frank pointed out this standard comment: > > "Because of inherent limitations in controls, > *errors or fraud may occur and not be detected*." > > Given such a situation, I believe that your belief > > "_audits prove that they do diligent verifications_" > > is almost impossible to support. Although, I would not be surprised if > audit suppliers and audit users that know better do not bend over backwards > to correct this frequent mistake. > > Think of it like credit card processing. The fraud rate in credit cards is > around 0.1 to 0.2% (from memory). These are all audited systems (several > ways), yet fraud and error still exists. > > So, expect a few errors, *routinely* in verifications. > > (Again, I am not saying I like it. It's just the world we live in. Before > we start jumping to conclusions about what is wrong, let's understand the > world we live in, first.) > > > >> Thanks to Frank Hacker for posting the link to the what he thinks is the >> latest audit of Comodo regarding normal certs (non-EV): >> <https://cert.webtrust.org/SealFile?seal=798&file=pdf> >> >> This audit is issued by KPMG. It merely certifies that Comodo follows >> its *own* self-defined guidelines. (I think that is not sufficient, but >> EV fixes that to some extend.) > > > With respect, it also refers clearly to WebTrust for CAs. This includes > around 25 criteria which are more focussed to the CA task. > > From memory, EV is a "supplement" to WebTrust for CAs, leaving WebTrust for > CAs in place as a valid and useful audit, at least in the opinion of the > CABForum. > > I personally would criticise this as a particularly strange approach, given > the post-2003 world of fraud and phishing and malware as we know it, but > this is what the CABForum chose to do. The perils of closed organisations, > I suppose. > > >> The Comodo guidelines and processes, as certified by the above document, >> are at >> >> <http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf> >> >> >> Section 1.10 shows that Comodo indeed uses Registration Authorities to >> do all verification, see my previous post "Re: CAs and external entities >> (resellers, outsourcing)" >> >> <http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/43bdc908878eb4b4?q=#fd8d123e7881c729> >> >> >> Most interesting to the current case, where the PositiveSSL certificate >> proved most problematic and which was already contemplated to yank, is >> section 2.4.1 a): >> >>> a) PositiveSSL Certificate >>> PositiveSSL Certificates are low assurance level Secure Server >>> Certificates from Comodo ideal for mail servers and server to server >>> communications. They are not intended to be used for websites >>> conducting e-commerce or transferring data of value. >>> ... >>> Due to the increased validation speed and the nature of how Comodo >>> intends >>> PositiveSSL certificates to be used, the certificates carry no warranty. > > > Good analysis, up to here! > > Most all certificates carry no warranty or have zero liability disclaimers. > Of course the words may differ, but even EV Guidelines permit the CA to set > zero liability, except where it shown that the CA is at fault, and even that > may be limited to something fairly tame given the market they are heading > into. > > >>> PositiveSSL certificates are available from the following channels: >>> Comodo Website, Reseller Network, Web Host Netowrk, PoweredSSL >>> Network, and EPKI Manager. >> >> "not intended for ... e-commerce. ... the certificates carry no warranty" >> >> It's clear that these certificates were never defined to be used in >> browsers, and therefore never should have been shipped with browsers. > > > I do not see that conclusion? There are a million web sites out there with > certs (by one survey, and another reported many more). Not all of them are > doing ecommerce. Probably in excess of 90% are basic work websites where > users access private data, and want SSL protection for that (yes, finger in > air guess, no more). > > If we are saying that acceptable certificates for browser-website use must > *be good for ecommerce*, then we would need to establish monetary values for > the certificates. That's the only thing that consumers will likely be > interested in. That is a really tough challenge, and in general the > industry has rejected this approach (c.f., EU monetary limits). > > >> In >> any case, whatever Comodo's intends or actions, PositiveSSL does *not* >> carry a valid audit for inclusion in browsers. > > > I didn't follow that step! Did the Audit or Comodo exclude the PositiveSSL > from consideration? > > (I wouldn't be surprised ... I just didn't see it. There were some > surprising admissions there....) > > >> I think the fault is clearly on Codomo's side, as the PositiveSSL cert >> is not included directly in Mozilla's root certs, but signed by Comodo's >> UserTRUST cert, which is included in Mozilla browsers. Therefore, Comodo >> is responsible for having allowed certificates for e-commerce which were >> specifically excluded for e-commerce and which explicitly "carry no >> warranty". > > > My claim -- check if this is true -- is that most nearly all certificates > have an *effective* liability and warranty of zero. And, as a claim to > address the above point, there is no standard that puts ecommerce at a > higher number than zero. (And, Mozilla does not currently have an > "ecommerce certificate" policy or difference.......) > > As I read it, Comodo remains responsible for validation of any certs under > its roots, and the audits should cover them all. > > >> The audit was also faulty, because the signature of PositiveSSL by the >> UserTRUST root and its inclusion in browsers is mentioned in the same >> document in section 1.8.3. In other words, the document contradicts >> itself and should never have been approved by the auditor (KPMG) as-is. > > > Could you post on the contradiction? That would be helpful. > > >> Suggested actions: >> * Add PositiveSSL cert to cert root with trust bit disabled, i.e. >> disabling it, assuming that works. IMHO, the current Firefox UI dialog >> is fine. It's as if PositiveSSL were never added to the cert store, >> which is what should have been the case all the time. > > We aren't really purposing SSL to "just ecommerce" as far as I know... > >> * Reconsider inclusion of Comodo certificates in the Mozilla root, as >> Comodo has violated its own definitions. > > This would possibly fall within their general warning about "errors". > >> * Require Comodo to remove the concept of Registration Authorities and >> do all verifications themselves. At minimum, Comodo must do a Domain >> Validation themselves. > > I suspect there is no chance of this. Just guessing, but some of these > operations have thousands of resellers. > >> * For KPMG having done a faulty audit, I don't know what the possible >> actions are, legal or reputation nature. > > > OK, a general comment on audits: likely, they have stated the truth in > their opinion. See the errors & fraud warning. It is far more likely that > the opinion is difficult to read and interpret, than that there is a fault > in it. After all, they have been doing this for a while. > > What is perhaps a more useful question is whether the audit provides > anything for you or Mozilla to find useful? As Mozilla (and its policy) is > not covered in that audit, and as the audit is not purposed beyond the > WebTrust for CAs, how far can you or Mozilla rely on it? It is useful, but > do we really understand what its use is and its limitations? > > > > iang > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
