Right. I wanted to get some comments in advance of updating the public
draft. (That helps me avoid the dreaded draft 13 :-)

Yes, in theory you're correct: The additional language, examples, etc.,
could go into a FAQ or other document rather than in the main policy.  I
also agree that the existing language already gave the flexibility to
reject CAs for the various reasons stated in the examples. (I made this
point in a reply to Nelson.) However...

I added this new language to directly respond to concerns expressed by
Nelson that the policy as written would let "bad" CAs slip through;
these concerns may be shared by others. If Nelson and others of like
mind think that this purpose can be accomplished by putting the examples
into a separate "guidance" document (e.g., a FAQ) then I'd be glad to do
that. On the other hand, if they believe that they should go into the
policy itself then I am prepared to do that in the interests of
achieving consensus. "The perfect is the enemy of the good."

Well, I think that was exactly Nelson's intent: he wanted those
particular concerns to be given weight.

In doing Mozilla policies I have found that amending policies to reflect
new realities is much easier (by an order of magnitude) than creating
new policies from scratch (as in the present case). If the document
needs to be tweaked in the future then I'm prepared to tale on the work
necessary to do that.

As I think I've previously written, in formulating policy I think we
need to be accountable to a number of groups, but that doesn't mean that
the opinions of every group have equal weight. I give special weight to
the concerns of the NSS developers because

a) they have more direct experience than anyone else with the
practicalities of accepting certificates in Mozilla;

b) their personal and professional reputations are potentially affected
by perceived insecurities in how Mozilla handles certificates; and

c) they are the module owners for NSS within the Mozilla project, and
hence should be given the benefit of the doubt to a certain extent when
making decisions that affect NSS.

If someone comes in "off the street" then I am prepared to pay attention
to what they have to say (just as I have paid attention to what you and
others have said). If I believe their arguments have merit (as I believe
some of your and others' arguments have had merit) then I am also
prepared to reflect those arguments in policy even when they go beyond
(or even to some extent contradict) accepted wisdom. But I'm not going
to do so lightly, particular on points on which universal consensus is
lacking and there are strong opinions both ways.

Two points here. First, I don't think including examples, even the
policy itself, ties the hands of the MF and whoever is responsible for
implementing the policy. The policy explicitly states that these are
illustrative examples (and I can tweak the language a little bit to make
that clearer).

Second, I think leaving policy interpretation up to policy implementors
works best when there is a high degree of consensus and there aren't
major external factors to consider. However as we've seen there is not a
universal consensus on even the technical issues (in terms of what best
protects users) and there are also the external issues that PKI has been
subject to pretty much from day one: legal frameworks, government
policies, identification of PKI use with financial applications and
e-commerce, etc.

I don't want to speak for Nelson and others of like mind, but I think
they want the policy to be more black and white in part because they
think that "bad" CAs will exploit ambiguities and lacunae (i.e.,
"missing parts") in the policy to "force" their way into Mozilla
products, by legal action if necessary. I think this concern is
overstated, but I am sympathetic to the desire to provide more clarity
on what we might consider reasons for rejecting CAs.

<example snipped>

Having living in the Washington DC area for many years I am quite
familar with arguments that go something like "I can't tell you all the
details -- because then I'd have to kill you! -- but believe me it is
very important that you do X". Your hypothetical example is basically a
variant of that: "I'm sorry, but the government forced me to issue these
duff certs!"

Leaving aside the issue of whether your example is actually realistic, I
think the bottom line is that to the maximum extent possible policy
implementors should make decisions based on public information available
to all. To address your example, I personally would be very reluctant to
make a decision based on someone "whispering in my ear"; I would likely
tell that someone to make their case to the public at large, or at least
that portion of the public interested in what we do regarding CAs. I'd
then make decisions based not just on my own opinions but those of
others as well.

I'd be happy to have more examples. Whether or not I put them in the
policy itself or in a FAQ depends on whether I need to do this in order
to achieve consensus on advancing the policy to final form.

Not strictly speaking, since certificates per se can't issue other
certificates. There's some unavoidable ambiguity here between using the
term "CA" to refer to the "technical means" (private key, etc.) by which
certificates are issued and using the term "CA" to refer to the
organization employing those means. I'd happily accept suggestions on
how to clarify this distinction.

re "separation of CAs":

I included discussion of this for the reasons I stated: to address
(some) people's concerns re this issue, and put CAs on notice as to
possible future changes. If people are OK with putting this in a
separate guidance document then I'd happily do that instead. (That would
certainly be my preference.)

Frank

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