Frank Hecker wrote:My apologies, it's been a while since I did serious work on drafting the CA certificate policy (as opposed to just discussing the surrounding issures). I plan to publish a draft 12 as soon as I can; here are my current thoughts for what changes I'll make in that draft:
http://www.hecker.org/mozilla/ca-certificate-policy is draft 11.
Right. I wanted to get some comments in advance of updating the public draft. (That helps me avoid the dreaded draft 13 :-)
* To address some of the concerns expressed about CAs issuing "duff" certs, I'm considering expanding clause 4 to read as follows:
4. We reserve the right to not include a particular CA certificate in our software products, to discontinue including a particular CA certificate in our products, or to modify the "trust bits" for a particular CA certificate included in our products, at any time and for any reason.
OK, this above sentance appears unchanged. In brief, all of the text that is below that para above, I suggests, falls into the bucket of "examples" or "guidance".
Generally, this would be better off in a separate document that was entitled "Guidance on the policy." This document would list working concerns and examples, and be modifiable *without* reference to the board.
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."
The reason for this is that the current set of concerns are not tomorrow's concerns. We may get today's concerns completely wrong, and we may find that tomorrow's concerns to be of much greater importance. Yet, because we have stated in the policy a set of concerns, then we are sort of caught in having to give them some weight.
Well, I think that was exactly Nelson's intent: he wanted those particular concerns to be given weight.
The alternate is that we have to seek the re-approval of the document every time the concerns change to better reflect what threats we are facing today.
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.
If Mozilla reaches say 25% of the browser market, then don't for a moment think that you will be able to do what you want just because it is right. You will be hounded by all sorts of journos being paid or induced by people who want your policy to be their policy.
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.
<snip>Clause 4 gives the power that is needed to resolve any question over particular CA root certs. From there, it really becomes an issue of who the director of this policy is on the day.
The end effect of these examples will be simply a shackle around his neck in adroitly dealing with what he sees are today's issues.
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.
If the Director accepts the premise that a CA might have issued a cert pursuent to a government order, he has just emasculated not only the policy but the entire PKI.
<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.
As an alternate notion. If you are going to include examples in the policy then we should all think up what examples we would like to see there.
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.
* To address the concern about certificates of different assurance levels being issued under the same CA root (or intermediate), I'm proposing adding a new clause 13 as follows:
13. In addition to the requirements outlined above, we also recommend that CAs use different root CAs (or different intermediate CAs under
in 2,3 "CAs" above don't you mean "certificates" ?
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":
Again, the director has the power to mandate this any time he likes simply because of clause 4. He doesn't need any additional support in the policy. The policy gives him wide ranging powers to craft procedure to implement the concerns of the day. Which is good.
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 [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
