I have just posted draft 10 of the proposed CA certificate policy:

   http://www.hecker.org/mozilla/ca-certificate-policy

There are only two substantive changes in this version:

* I changed the language on disclosure of financial compensation (i.e.,
of independent evaluators by CAs) to read "publicly disclose" as opposed
to "fully and publicly disclose"; in other words, I dropped the word
"fully".

My motivation was to make it clear that we don't want and need to see a
fully-itemized disclosure statement (e.g., "$5 for lunch at McDonald's"
:-), we just need a statement about the overall compensation (e.g.,
"$2,000 for expenses incurred during the evaluation").

(For those coming late to the discussion, this requirement is really
intended for the case of independent evaluators who don't fit the
traditional mold of being accountants or goverment-authorized test labs,
e.g., they might be volunteers being reimbursed for expenses.)

* I added a section discussing revision of the policy, and noting that
such revision would be done only after public discussions (similar to
what we're doing now).

As I did last time, I've attached a detailed list of diffs to the actual
web page.

OK, now for the hard part...

At this point I face a decision: to try to revise this policy further,
or to go ahead with the current draft as a reasonable 1.0 policy, with
further work pushed to a 1.1 version.

My personal opinion is that the current draft does a good job of
codifying and clarifying the current practices that I've been following,
  as well as allowing for us to incorporate new practices like the use
of volunteer evaluators. On that basis I would be comfortable submitting
this draft (or a very slightly tweaked version of it) to the Mozilla
Foundation for consideration as the official 1.0 policy.

However, this draft does not address some of the larger issues that have
been raised. In particular, as noted by Nelson Bolyard among others, the
proposed MF policy as written requires that CAs be evaluated to confirm
that their practices match their own policies and assertions (e.g., as
expressed in the CPS, CP, etc.); the proposed MF policy does *not* go
beyond that to attempt to put requirements on those CA policies, for
example, to require particular assurance levels for CAs issuing
particular types of certificates.

Should we attempt to change the policy to reflect these larger issues?
For my part I am predisposed to adopting the current draft as a 1.0
policy, partly for the selfish reason that it's less work for me :-)
More seriously, I do think that the proposed draft is consistent with
the current state of affairs with regard to browsers and CAs, and is a
good base for future policies that might be further-reaching.

I'm prepared to modify my opinion in the face of compelling arguments to
the contrary. However I am concerned about getting bogged down in
discussions about the right way to approach more significant changes to
the policy, and not reaching consensus on actual policy language. See my
previous response to Nelson (on 2/15, subject "Re: Low assurance SSL
CAs") for a more detailed discussions of my concerns around the idea of
expanding the requirements on CAs to include minimal assurance levels.

I'm also concerned about adopting a policy that implies or requires
underlying implementation changes or (even worse) changes in the CA
business as a whole, as I've previously noted in the metapolicy. (For
example, some proposals imply or require additional browser UI or other
changes, for example to display information to the user about the
particular CA "class" or to recognize hypothetical standardized policy
OIDs.)

It's not that I don't think these suggestions are good ideas; it's just
that I think additional experimentation and investigation is needed in
order to determine if these suggestions are doable and worth doing, and
I don't necessarily want to wait on the results of that work prior to
putting an initial 1.0 policy in place.

As usual, I welcome your comments on this issue, and in particular your
opinions as to whether I should take this draft forward to the Mozilla
Foundation for consideration as a 1.0 policy.

Frank

--
Frank Hecker
hec...@hecker.org

[ ca-certificate-policy-diff.txt 2K ]
Index: mozilla/ca-certificate-policy.html
===================================================================
--- mozilla/ca-certificate-policy.html  (revision 358)
+++ mozilla/ca-certificate-policy.html  (working copy)
@@ -142,7 +142,7 @@
       <li>the party is not financially compensated by the CA;</li>

       <li>the nature and amount of the party's financial compensation
-       by the CA is fully and publicly disclosed; <em>or</em></li>
+       by the CA is publicly disclosed; <em>or</em></li>

       <li>the party is bound by law, government regulation, and/or a
        professional code of ethics to render an honest and objective
@@ -205,7 +205,12 @@

     We will reject requests where the CA does not provide such
     information within a reasonable time after submitting its
-    request.</li></ol>
+    request.</li>
+
+  <li>We reserve the right to change this policy in the future. We
+  will do so only after consulting with the public Mozilla community,
+  in order to ensure that all views are taken into account.</li></ol>
+
 </div>

 <p>This policy applies only to software products distributed by the
@@ -227,26 +232,30 @@
 to related questions.</p>

 <div class="important">
-<p>Version 0.9, February 11, 2004. Extended requirements to cover all
+<p>Version 0.10, Feburary 16, 2005. Dropped "fully" from financial
+disclosure requirement. Added section on revising the
+policy. Corrected date references on version history.</p>
+
+<p>Version 0.9, February 11, 2005. Extended requirements to cover all
 CAs included with Mozilla products. Changed "independent and qualified
 third party" to "competent independent party" and clarified that they
 need to have information on CAs' operations. Added ETSI TS 101 456 and
 102 042 as acceptable criteria. Changed language on financial
 compensation to evaluators. Various other minor changes.</p>

-<p>Version 0.8, February 8, 2004. Clarified references to
+<p>Version 0.8, February 8, 2005. Clarified references to
 "users". Added requirement for a CPS or equivalent document. Removed
 reference to X509v3. Clarified that the MF could do its own evaluation
 if it wished to do so. Added that requests without supporting
 documentation will be rejected.</p>

-<p>Version 0.7, February 6, 2004. Tweaked language on "trust bits",
+<p>Version 0.7, February 6, 2005. Tweaked language on "trust bits",
 "preliminary determination", "software products", etc., as
 suggested. Added more information on how third parties will be
 evaluated for competence. Added more language on what it means to be
 an "independent" third party.</p>

-<p>Version 0.6, February 4, 2004. Changed conformance requirement to
+<p>Version 0.6, February 4, 2005. Changed conformance requirement to
 use "acceptable criteria", currently defined as X9.79 or WebTrust.</p>

 <p>Version 0.5, December 23, 2004. Added "WebTrust or equivalent"

Good stuff!

Makes sense.

Good!

I would agree with this.  It needs fresh review, and
the group that has reviewed it so far has said lots
already ... you will get far more value now by finding
people who haven't seen it before and getting some
feedback from them.

(And, as there are some outstanding issues as you
raise them, I suspect they will get some airplay...)

There are lots of fundamental reasons why the above
notion of looking for commonality in CA statements is
unlikely to work.  And, try as I might, I can think of no
reason, nor theory nor example that shows it would
ever work.

So I shall try to briefly suggest some of the key reasons
why it won't work:

a. getting a group of CAs to cooperate on a high standard
brings in the possibility of cheating.  The one who cheats
is rewarded.  The way to overcome this (classically) is to
form what is called a cartel.  But, that is an unstable force,
and the ways to make it stable are ... not pretty.

b.  basic competition theory suggests that companies try
to compete on all fronts ... including quality.  In this sense,
the basic desire of a company is to discriminate (that's the
technical marketing term) its product against everyone
else's.  Setting a standard works against that.

c.  Competition theory also suggests that one way to raise
profits is to raise barriers to new entrants.  If a group of
strong players can force over a standard, then it creates
a costly way for new entrants to come in, and the insiders
then can raise prices.  (Ref: Porter.)  In this world, standards
are a 'bad'.  This approach trumps b., above, if they companies
can arrange it.  Hence the concept of anti-trust.

d.  Safety is one way to look at it.  The issues with safety
are that a) nobody wants to pay for it unless all pay for it, b)
nobody wants some other player to set the rules, so it has
to be 'the government' and c) nobody knows how to do it
anyway (in the security field, that is).  All this leads to a
tendency the 'safety' field to become a government field.

e.  In general, there is now a body of economics thought
(Mises, Buchanan) that says that the standard result of
government is worse off for everyone.

Now, you'll probably say that's just economics.  So I'll flip
that around and ask:  is there any reason or theory to show
that it would work?  Is there any analogue anywhere in the
world that will make this notion of shared policies among
CAs fly?  I don't think there is.  Nor is there any evidence
to suggest that within the CA field they've ever really
shown any tendency to do this.  They've been at it for 10
years, and nothing.

Go for it!

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

It just occurred to me that the list that I posted might
be bemusing and apparently out of context.  Let
me add this quick comment:

By asking for a common policy we have shifted the
context out of '_technical_' and into '_business_.'

The tech part of doing this is easy.  It's the business
part that is a real headache.  Hence, that list is a
business list.

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

Frank Hecker wrote [in part]:

We can keep polishing this forever.  That's the nature of such
policies.  However, I don't think further polishing will really
improve the policy without being based on actual experience in
using it.  Therefore, I suggest it is time for the policy to be
adopted formally by the Mozilla Foundation.  

--

David E. Ross
<URL:http://www.rossde.com/>  

I use Mozilla as my Web browser because I want a browser that
complies with Web standards.  See <URL:http://www.mozilla.org/>.

* Frank Hecker:

Sorry for jumping in so late.

Some CAs claim copyright (or trademark rights, or whatever) on their
*root* certificates, and license them in rather obnoxious ways (for
example, require certain user behavior which has privacy
implications).  I believe that this is a significant problem, even if
the license terms turn out to be unenforceable in most jurisdictions.

After reading such a CA "license", the next question pops up: Are CAs
which explicitly disclaim responsibility for the certificates they
issue acceptable for inclusion?

First, thanks for your comments. Now, my response:

What you describe may be a problem in theory, but are there cases where
it's proved to be a problem in practice? Certainly from the point of
view of the Mozilla Foundation I find it very hard to imagine that any
CA would seek to limit distribution of their root CA certs due to
copyright or trademark issues; on the contrary, they're the ones asking
us to include the certs.

As for problems caused to typical Mozilla end users by CA legal
agreements, again, what if any problems have actually occurred in practice?

I presume you're talking about CAs whose relying party agreements,
subscriber agreements, certificate policy, etc., extremely limit the
CA's liability, or cast that liability in such a form that a typical
Mozilla end user (typically playing the role of the relying party) in
practice would not be able to satisfy the  requirements of the relying
party agreement, etc.

I see your question as analogous to the question "Is code from software
developers who explicitly disclaim responsibility for the software they
distribute acceptable for inclusion in Mozilla?" This is of course the
standard situation for open source code contributed to the Mozilla project.

I believe that the whole legal framework around PKI is for the most part
irrelevant as far as typical Mozilla users are concerned, in the sense
that I believe that in practice it's unlikely any CA would ever suffer
significant legal harm based on their practices vis-a-vis typical
Mozilla users. As for harm to Mozilla end users, I think the more likely
scenario is harm to users' actual security in the here and now as
opposed to harm resulting from users being forced to comply with CA
legal agreements.

Hence in accordance with my previously-expressed opinions (see 4 of the
metapolicy, "The policy should focus on security risks associated with
CA certificate selection, not on legal risks."), I'm inclined to not
worry about this issue in version 1.0 of the CA certificate policy,
until/unless someone presents compelling arguments to the contrary.

Frank

--
Frank Hecker
hec...@hecker.org

Here's a bit of history on that subject.  A certain well-known CA had
some root CA certs that expired on the eve of Y2K.  As I recall, they
claimed copyright (as Florian described above) and, IIRC, they had a
policy of not allowing their certs to be distributed except inside
releases of software that relied on their certs.  They had new CA certs,
but they wouldn't allow those certs to be downloaded individually (apart
from other software) by end users, as I recall.

In effect, this forced new releases of another company's software
products just prior to Y2K in order to distribute the new certs.  That
last-minute release made for some unhappy software users/customers who
vented on the software company, not on the CA.

To avoid a repetition of that scenario, it might be advisable for MF's
CA policy to require that CAs permit MF to distribute CA certs via means
of MF's own choosing as a condition of inclusion in MF's root CA list.
At the very least, MF should know in advance which CAs will similarly not
permit distribution of replacement root CA certs apart from software
distributions.  It would also be advisable for MF to keep track of
upcoming root CA expirations and plan releases for them.

In my opinion, of course.

--
Nelson B

Sigh, that is _so_ brain-dead.

I can certainly add a new item to the CA requirements in the policy:

   5. We require that all CAs whose certificates are distributed with
      our software products: ...

      * permit redistribution of their certificate(s) with our software
        products or through other means as we may choose to do so

However in practice what's the actual point of this? Assuming that a
"certain well-known CA" continues the policy of not allowing end users
to download their cert directly, are we going to yank them from the
included cert list because they don't meet the requirements? I doubt it.

I don't think it's a good idea to include policy language that one is
not likely to enforce should it come to that, especially for a problem
that may or may not actually occur.

I do agree that we need a plan for this. My proposal is not to revise
the actual 1.0 policy to address this, but to first look at the actual
situation (in terms of CA cert expiry dates and relevant CA copyright
language) and see how serious this problem actually is today. At the
same time we can consider ways to push out root cert list updates.
(Things like the Firefox update mechanism are obvious candidates, but
then we have to address the whole signed XPI issue.)

Frank

--
Frank Hecker
hec...@hecker.org

It is!  But it's the CA's problem, surely?  MF can only
go so far in mollycoddling the CAs, and at some point,
it becomes an abusive relationship, which I would
suspect was an issue in that sad story.  But very
illustrative of real world problems, thanks Nelson.

I agree with that.  If a "certain well-known CA" decides to
play silly buggers with the customers, then it's between
the CA and the customers ... and the CA should suffer in the
market place.  The right thing to do is to surface the info
and let the CA decide whether its reputation is worth
trashing in this way, or whether the exigency is severe
enough that it's the right option, IMO.

If a "certain well-known CA" did that, then it should be
named, and become well-named for who it is, not obscured
nor protected by MF.  Maybe it had a good reason to do
that - nobody can really judge on their behalf - but likewise
it is not up to MF to hide the problems from users.

(This sounds like an implementation detail, rather than a
policy detail?)

As an implementation detail, one could run a script to
just mail the CAs 2m and 1m before expiry, like the domains
people do.  Or, alternatively, just mail out the release
planning dates to CAs saying "make sure your certs are
up to date for those dates."

Another way of doing this is to put the info in the release
notes.  That is, when the rootlist is manufactured, it spits
out the certs list with expiry dates.  Then, all the users
get told it is an expired cert, and it isn't MF's fault that
the CA hasn't kept up to date.  Plus the release notes
can be promulgated on the web page for CAs, which
would be useful info for the various user communities
to browse.

Just some ideas...

iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

* Frank Hecker:

But those who redistribute your software want some reassuring
statements, too.  (Debian has rather strict policies WRT to licensing
for part of its archive, but this is the exception.)

IMHO, mandatory OSCP checks are an unacceptable privacy invasion.

This is probably reasonable.