Comment 35 for bug 232340

Questions about the appropriateness of the proposed CA policy really should be
discussed in some public forum (e.g., the Mozilla crypto mailing
list/newsgroup). I plan to start such a discussion once I have a real draft
policy, but unfortunately I haven't had time to finish that up yet. In any case,
I'll make the following semi-random points right now:

* Historically mozilla.org has delegated the process of selecting root CA certs
to a third party (Netscape/AOL). That's no longer appropriate IMO, so we have to
make some decisions about how best to do this in the context of the Mozilla
Foundation and the Mozilla project as a public open source project. This debate
is part of that decision process.

(To my knowledge Netscape never published its own policies on accepting CAs. So
while we may be now discussing criteria for including new CAs, there's also a
separate issue of what to do, if anything, about all the CAs whose certs are
already included in Mozilla. We should also discuss this at some point;
otherwise IMO we're simply letting the already-included CAs off the hook, and
discouraging new CAs based on criteria that weren't necessarily applied to the
old CAs.)

* For the moment the Mozilla Foundation is dependent on volunteer labor (e.g.,
me) to take on the task of selecting CAs. No one is getting paid to do this, and
no one is going to be paid to do it for the foreseeable future. So we have to
evaluate potential policies in light of the resources (e.g., my and others'
volunteer time) required to implement them. In that context having a relatively
liberal and easy-to-apply policy is attractive.

(Of course we can also imagine leveraging the efforts of other volunteers, as in
the Mozilla project generally; see also below.)

* From my experiences with FIPS 140-x and Common Criteria evaluations I am well
aware that "security as certified" and "security in reality" are not always the
same. So while it may be good to look at formal third party certifications of
CA, I think such certifications should not be the only criteria for selecting a
given Ca for inclusion, and I think lack of such certification should not
necessarily disqualify a CA from being included.

* IMO there's a real question of what question of what to do (and what can be
done) about problems with CAs that get selected for inclusion. Some of the
comments in this bug imply that we're dealing with a "brittle security"
situation here: that one mistake on selecting a CA for inclusion could lead to a
total meltdown in terms of user trust of Mozilla (or, alternatively, it could
lead to a significant lessening in user trust in the whole PKI setup around
SSL-enabled web servers, etc.).

Is this really the case? In a related areas, the presence of security
vulnerabilities in Mozilla hasn't led to a breakdown in user trust in Mozilla;
in fact, Mozilla seems to have a better reputation in this area than competitive
products like IE. IMO this is not all due to the care taken in Mozilla design
and implementation; it is also a function of the process the Mozilla project
uses for handling vulnerabilities once found.

Is it possible and desirable to take the same approach here? In other words, as
opposed to putting all of our effort into the initial selection process for CAs,
is it possible to divide efforts between an initial selection process and a
post-selection process for dealing with CA-related problems? Such an approach
would seem to be more in keeping with the way the Mozilla project works in other
areas. (And from a selfish point of view it wouldn't put all the burden on me or
whomever else does the initial selection.)

Anyway, some thoughts for now. Rather than continuing in this vein, I'll go back
to trying to get a draft policy finished and out for comment. And if this debate
over CAcert acts as a forcing function to get me to do that, that's a good thing :-)