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
