Here is the message I sent to [EMAIL PROTECTED] earlier today
recommending adoption of the "1.0 Release Candidate" version of the
Mozilla CA Certificate Policy. Note that I tried to distinguish areas on
which there has been reasonable consensus (at least among the people
who've commented on the policy throughout this process) and areas on
which no real consensus exists IMO; I also tried to fairly characterize
the nature of any remaining disagreements and indicate the implications
for future policy.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
--- Begin Message ---
As you may recall, some time ago I proposed to create a new formal
policy to govern how we accept new root CA certificates for inclusion in
Firefox, Thunderbird, and related products. I am glad to report that I
now have a version of the policy that I can recommend to you for
consideration as an official Mozilla Foundation policy:
http://www.hecker.org/mozilla/ca-certificate-policy
Below I provide some background to the policy, a description of its
salient features, and a discussion of open issues around the policy that
you should be aware of, and that might motivate our revising the policy
in the future.
Background: A default set of root CA certificates is bundled as part of
the NSS crypto library maintained in the Mozilla source tree and
released through mozilla.org. Any product that picks up the standard
mozilla.org version of NSS will use these root CA certificates; this
includes Firefox, Thunderbird, Seamonkey, Camino, etc. (There are some
minor issues like Firefox and Thunderbird 1.0.x maintaining
product-specific versions of NSS on separate branches, but we can ignore
that for our purposes here.)
After taking on the task of reviewing new root CA certificates, and
after some false starts, I settled on an interim policy of accepting new
certificates only from CAs that had successfully completed a WebTrust
for CAs audit or an equivalent third-party audit. Thus far I've approved
several new CAs for inclusion under this policy. However I believe that
this interim policy is not sufficient to address all of the issues
around approval of new CAs (or review of existing ones), and thus I've
gone through a public process in an attempt to create a more
comprehensive policy. The current "1.0 Release Candidate" policy is the
result of that process.
Features of the proposed policy: The new policy has several features
that distinguish it from the current interim policy; I included these
new features for the reasons stated below:
* The policy explicitly expands the set of acceptable CA criteria beyond
WebTrust to include three other sets of criteria, as noted in clause 8.
The basic issue here is that the WebTrust for CAs criteria have the
disadvantage of being tied to a particular commercial evaluation program
sponsored by accounting professionals. Many CAs use alternative
approachs to evaluation, for example being evaluated by government
agencies under programs established national digital signature
legislations. The new criteria provide alternatives to the WebTrust
criteria; the ETSI criteria in particular are fully public, can be
downloaded at no charge, and have no restrictions on who might use them
for the purposes of evaluating CAs.
* The policy adds some additional criteria beyond the criteria listed in
clause 8, addressing security risks associated with particular CA
practices (clause 4), technical problems related to CA practices (clause
4 again), and verification measures performed when CAs issue new
certificates to their customers (clause 7). The issue here is that the
WebTrust criteria and other criteria are not complete: They address how
well a CA adheres to its own published policies, but they do not
necessarily address the content of those policies. The result is that
(at least in theory) a CA could pass a WebTrust or other audit even
while engaging in practices that could negatively impact the security of
typical users of our products. (To cite two extreme examples, a CA might
have a published policy of issuing certificates without verification, or
issuing certificates with obviously false information, with a
third-party audit then simply confirming that the CA does indeed act in
accordance with their stated policy.)
There was consensus that we should do more to put a "floor" in place
relating to acceptable CA practices, and the language in the policy
represents the additional criteria on which there is currently
consensus. (But see also the discussion below regarding open issues.)
* The policy allows for alternative ways to evaluate that a CA has met
the criteria noted above. This is related to expanding the acceptable
criteria beyond those associated with the WebTrust for CAs program: With
alternative criteria we have the possibility that CA evaluations might
be done by people or organizations other than accounting firms or
government-authorized test labs. The consensus is that there is no
reason in principle not to accept the results of such evaluations, so
long as there is sufficient information available for us to judge
whether the evaluations have been done in a suitable manner. Clauses 9
and 10 outline how we evaluate the evaluators themselves, and thus
determine whether or not to accept those evaluators' evaluations of CAs.
Note that in practice I believe that the number of "alternative"
evaluations will be few, and will be mainly limited to nonprofit CAs
and/or CAs associated with academic and research organizations. (There
is at least one CA, CAcert.org, that might apply under this provision,
and perhaps a couple of others as well.) Note also that the policy
provides for the possibility that we might do our own CA evaluations
(clause 11). I included this clause mainly for completeness, as we don't
currently have sufficient resources to do full CA evaluations; however
it's possible in the future that we might find one or more people
willing to do this, in which case we could take advantage of clause 11
and have them act on our behalf.
* The policy has some non-binding language relating to CAs maintaining
separate roots (or separate intermediate CAs under a single root) in
order to avoid issuing certificates according to different policies
under the same CA. For more information on why this language was
included (even though it's non-binding) see the discussion below
regarding open issues.
* The policy has more details on how CAs should go about submitting
requests (clause 14) and language confirming that issues relating to CA
certificates will generally be handled in a manner consistent with
practices elsewhere in the Mozilla project (clauses 15 and 16).
Open issues: There were some issues on which there were significant
differences of opinion and a consequent lack of consensus on what the
policy should contain:
* There was significant disagreement concerning how far the policy
should go in mandating how CAs verify people or organizations applying
for certificates. In particular, with regard to SSL certificates some
CAs offer "low assurance" certificates based on simply verifying that
the applicant controls the domain name for which the certificate is
being issued, as opposed to "higher assurance" certificates for which
the CA also performs some additional measures to verify the applicant's
identity (e.g., checking personal identity documents, business licenses,
etc.)
Some people believe that such "low assurance" (or more neutrally,
"domain-validated") SSL certificates pose a undue risk to the security
of typical users of our products; for example, phishers might obtain
such certificates for their fake web sites and lead users to assume that
because the sites are SSL-enabled that therefore they are legitimate.
Other people (including myself) believe that issuance of lower-cost
domain-validated certificates is a legitimate practice that does not
pose undue risk to users and has the potential to expand use of SSL (and
the protections it provides against certain types of attacks) beyond the
minimal fraction of web sites that are currently SSL-enabled.
Incidentally, even CAs themselves disagree on this issue; some CAs have
publicly disparaged the use of domain-validated SSL certificates, while
others have claimed that identity information in SSL certificates
(beyond the domain name itself) is inherently unreliable and that using
domain-validated certs can be a perfectly reasonable decision from a
security point of view. For examples of such divergent views see the
following references:
http://www.comodogroup.com/news/press_releases/28_02_05.html
http://geotrust.com/resources/advisory/sslorg/
http://geotrust.com/resources/white_papers/pdfs/SSLVulnerabilityWPcds.pdf
We came to a consensus that the policy should mandate that CAs implement
verification measures at least to the level used today for
domain-validated SSL certificates; however there was no consensus for
having the policy mandate implementation of additional verification
measures beyond that (and thus require our rejecting CAs issuing
domain-validated certificates).
* Relating to the discussion above regarding domain-validated SSL
certificates vs. "identity-validated" certificates, some people have
proposed changing the browser UI to distinguish between certificates of
different "assurance levels" and/or to provide more information about
the CA and its policies (for example, to display a CA logo in addition
to the simple lock icon). In connection with this some people proposed
that the policy attempt to classify CAs into different categories based
on the types of certificates they issue (e.g., "low assurance" vs. "high
assurance") and also mandate that CAs implement a standard way for us to
distinguish such different classes of certificates.
In particular, it was proposed that a CA not issue different types of
certificates under the same root CA, but instead use different roots for
different types of certificates. This would in theory provide one way to
distinguish the types for purposes of the UI, and would also in theory
allow us to disable acceptance of "low assurance" certificates (i.e., by
removing the root CA certificates for CAs issuing such certificates)
should we ever feel the need to do so, without affecting acceptance of
"high assurance" certificates.
I see several problems with this approach: First, there is no consensus
on what if any changes we might want to make to the browser's SSL UI,
and no present commitment on anyone's part to actually make such changes
even if there were consensus. Second, there is not necessarily
consistency between CAs on what constitutes a "high assurance"
certificate versus a "low assurance" certificate, and thus it is not
totally clear how we could go about making such a distinction ourselves.
Finally, there are existing cases where CAs issue certificates of
different types under the same root, and we would have to figure out if
we could deal with these cases in a reasonable way (as opposed to
treating all of the CA's certificates as "low assurance" or just
rejecting them entirely).
Given the lack of consensus on this issue, I decided to include some
language in the policy relating to CAs separating issuance of
certificates of different types, thus highlighting the issue and our
interest in it, but decided to make the language non-binding. I
recommend that we learn more about what CAs are doing (or are likely to
do) in this regard, and perhaps revisit this issue in the future.
Summary: I believe that the policy as it stands now is workable, is an
improvement over the current interim policy, and reflects what consensus
there exists regarding how we should handle CA certificates. I therefore
recommend that you approve our adopting it as an official 1.0 policy.
If for some reason you don't want to do that, here are your alternatives:
* Adopt the policy with indicated changes.
* Reject the policy entirely.
* Postpone further work on the policy until we determine what if any
changes we might make to the SSL UI and related security UI.
My preference is clearly for adopting the policy as is or with at most
minor changes. I believe that the policy as proposed is a better policy
than the current interim policy, and I believe that it is better to
adopt a 1.0 policy now and revise it later than to postpone adoption of
a policy awaiting code and UI changes that may never be made.
But in any event the decision is yours, and I look forward to hearing
your comments on this matter. If you have further questions on the
policy I'll be glad to answer them.
Frank
P.s. I also plan to create a FAQ related to the CA certificate policy:
http://www.hecker.org/mozilla/ca-certificate-faq
This is currently in an early state and is far from being complete. I'll
post more drafts of this as I finish them, however I don't want to hold
up the policy waiting on the FAQ.
--
Frank Hecker
[EMAIL PROTECTED]
--- End Message ---
