Comment 40 for bug 232340

(In reply to comment #33)
> But Nelson's points are still valid, one mistake on CAcert's part, and you may
> have the press all over the place.

One needs to be aware of where the failure is here. It is not, or will not be, on CACert's
part.

The failure is in the PKI design.

(As Peter Gutmann points out that) there is one security policy within browsers, and it is
shared amongst all CAs. That is, when a browser encounters a cert from a website, it
accepts the signature on that cert from *any one* of the CAs that happen to be in its
database.

This means that any CA can cause breaches. It also means that all security statements
are homogonised to one level. Lowest common denominator, if you will. It matters not if
one CA has a high standard, if another has a low standard.

In this environment, there are two choices - either set a high standard, and *stick to it*,
or, set a low standard, and don't rely on the results.

Setting a high standard is the choice of CAs that are trying to make a business of this.
But, regardless of their attempts to do this, it is implausible to believe that all of those
hundred or so top level certs are in fact managed and protected according to some
high standard.

The high standard approach implies that Mozilla and every other browser maker has to
vet and approve every CA, and monitor them along their life cycle. It's not adequate to
simply shift the burden to some standards body like a club of accountants, unless one is
paying them money to do that, and one is then vetting their activities.

The alternate, setting a low standard, is more realistic. Firstly, it's cheap in terms of time
and effort. Secondly, there are no unrealistic nor unrealised expectations. Thirdly, it is
aligned to the security delivered by browsers.

(SSL security as delivered within HTTPS between browser and server is vastly
overrated in its efficacy. There are no reportings of MITM attacks over unprotected
credit card transmissions, and in practice, the vast majority of attacks on browser users
bypass and ignore the SSL barrier (successfully). That is, there is no practical threat
that needs certificates, and, at the same time, there are real life losses occurring daily
due to the browser's poor security model.)

In this context, it only makes sense to set a simple minimal set of rules for new CAs to
be vetted by. Something that can be checked by one guy in less than an hour, maybe.

In the meantime, there is a lot of work needed to add security to the browsing domain.
It involves migrating the CA-cert regime across to the approach of SSH, and
incorporating GUI enhancements, and drawing the user more into the security model.
There was a rather fine paper on this done in 2001 or so, which was got working in
Mozilla, but I lack the references for it.

iang

Interesting links:
http://www.cs.auckland.ac.nz/~pgut001/
http://iang.org/ssl/