Plan for draft 12 of CA certificate policy
Frank Hecker
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:
* 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.
This includes (but is not limited to) cases where we believe that
including a CA certificate (or setting its "trust bits" in a
particular way) might cause undue risks to users' security, for
example, with CAs that
- knowingly issue certificates without the knowledge of the
entities whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for
fraudulent use
This also includes (but again is not limited to) cases where we
believe that including a CA certificate (or setting its "trust bits"
in a particular way) might cause technical problems with the
operation of our software or be at variance with relevant
standards, recommendations, and industry best practices, for example,
with CAs that issue certificates that have
- duplicate issuer names and serial numbers;
- invalid public keys (e.g., DSA certificates with 2048-bit primes,
or RSA certificates with public exponent equal to 1);
- incorrect extensions (e.g., SSL certificates that exclude SSL
usage, or authority key IDs that include both the key ID and the
issuer's issuer name and serial number);
- invalid dates; or
- ASN.1 DER encoding errors.
I'm proposing including this language in clause 4 rather than clause 6
(requirements on CAs) for a couple of reasons.
First, the basic concern as I understand it is that we keep out
incompetent or dubious CAs; clause 4 is all about maintaining our
freedom to reject or remove CAs, with the new language basically
clarifying exactly why we might do this, so I think that's the
appropriate place to put the new language.
Second, IMO at least some of the example reasons to reject/remove CAs
could be problematic when interpreted as strict requirements per clause
6. For example, it's quite possible that a CA might knowingly issue a CA
with false information in response to a legitimate request from a law
enforcement agency or other government entity. If we happened to find
out about this I wouldn't want the policy (as strictly interpreted) to
always force us to remove the CA.
As another example, in some cases CAs might issue "confusing" certs for
reasonably legitimate reasons, e.g., as in the "First Bank" example I
previously gave. In other cases there might be a pattern of behavior
indicating real problems, e.g., with a CA that appears to have been set
up as mainly as a way for phishers to get certs for "paypa1.com",
"micr0soft.com", etc. IMO the policy needs to provide us the freedom to
make subjective judgements as to what indicates a real problem and what
does not. The point of clause 4 is to provide that needed "wiggle room",
which again is why I think the new language should go into clause 4.
* 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
a single root) when issuing certificates according to different
Certificate Policies, so that we or others may selectively enable or
disable acceptance of certificates issued according to a particular
policy, or may otherwise treat such certificates differently (e.g.,
in our products' user interfaces). We reserve the right to make this
a requirement in the future, and to not include a particular CA
certificate in our software products, to discontinue including a
particular CA certificate, or to modify the "trust bits" for a
particular CA certificate, based on the CA's practices in this regard.
I'm proposing this as a recommendation (at present) rather than a
requirement for the reasons I've previously stated: I don't think we
should mandate this until it's clear how much of a problem this really
is, how much it would affect the existing set of CAs already included in
the products, and whether we're going to make UI and other changes that
would depend on this. However I do think it's reasonable to put CAs on
notice that we're thinking about this issue and may take stronger action
at some point.
Also, note that I sidestepped the tricky issue of defining and
determining certificate "assurance levels". I think a better approach
(at least for now) is simply to recommend that all certs issued under a
single CA (whether issued directly by a root CA or by an intermediate CA
under a root CA) be issued according to the same policy.
As usual, comments are welcome and encouraged. I'll publish a formal
draft 12 soon; I hope that draft 12 can be the final draft, because I
think it would be unlucky to have a draft 13 :-)
Frank
--
Frank Hecker
hec...@hecker.org
Ian G
> 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.
> * 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.
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. 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.
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.
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. If
it's Frank, we get "result F." If it's Nelson, "result N."
Whatever goes in the policy, whichever examples are highlighted,
the effect will be that the implementing director will be bending
the policy to suit their judgment call.
(Which is their job, to make the call.)
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. Far better I think to have the director
manage a guidance file where he expresses his judgement calls.
If he gets it wrong, he changes the file and takes a hit.
But if it's in the policy, he can't change it. Then, all
of Mozilla has to take a hit, and so do the users.
> This includes (but is not limited to) cases where we believe that
> including a CA certificate (or setting its "trust bits" in a
> particular way) might cause undue risks to users' security, for
> example, with CAs that
>
> - knowingly issue certificates without the knowledge of the
> entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for
> fraudulent use
Err... (I see you've picked up the flaw below!)
> This also includes (but again is not limited to) cases where we
> believe that including a CA certificate (or setting its "trust bits"
> in a particular way) might cause technical problems with the
> operation of our software or be at variance with relevant
> standards, recommendations, and industry best practices, for example,
> with CAs that issue certificates that have
>
> - duplicate issuer names and serial numbers;
> - invalid public keys (e.g., DSA certificates with 2048-bit primes,
> or RSA certificates with public exponent equal to 1);
> - incorrect extensions (e.g., SSL certificates that exclude SSL
> usage, or authority key IDs that include both the key ID and the
> issuer's issuer name and serial number);
> - invalid dates; or
> - ASN.1 DER encoding errors.
>
> I'm proposing including this language in clause 4 rather than clause 6
> (requirements on CAs) for a couple of reasons.
(I'm going to leave the 'where' aside for now and
concentrate on the 'what' and the 'whether'.)
> Second, IMO at least some of the example reasons to reject/remove CAs
> could be problematic when interpreted as strict requirements per clause
> 6. For example, it's quite possible that a CA might knowingly issue a CA
> with false information in response to a legitimate request from a law
> enforcement agency or other government entity. If we happened to find
> out about this I wouldn't want the policy (as strictly interpreted) to
> always force us to remove the CA.
OK. So the way it works *today* is that if a CA is
instructed to issue a false certificate to a user,
then likely there will be a gag order. In this case,
you should not find out about the circumstances
behind the false issue in any formal sense.
Now you have a dilemma. Let's say a big CA issues
a false certificate. It is found out accidentally
and causes a net scandal. The CA is under gag orders,
and the victim looks clean. You'll now get some people
saying that the CA has to be dropped and some people
saying, wait a minute, maybe there was a government
order?
In fact, likely the Director will get hints that this
is the case.
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. Consider the recent discussion on the
Chinese root proxy MITM. Let's say a dodgy ISP in
mainstreen America is doing proxy attacks. Let's
say they're aggressively sucking up the data info
on online banking and passing it across to a data
broker who's selling it to a mate who's selling it
to a phishing farm out in deepest darkest Klapistan.
"Nobody's doing anything wrong..."
Then they get found out... but the ISP whispers in the
ear of the Director that actually the proxying they
are doing is pursuant to a government order, and it's
under gag. And, he whispers fearfully, that he
himself could go to jail for even mentioning this
and breaking the gag order.....
> As another example, in some cases CAs might issue "confusing" certs for
> reasonably legitimate reasons, e.g., as in the "First Bank" example I
> previously gave. In other cases there might be a pattern of behavior
> indicating real problems, e.g., with a CA that appears to have been set
> up as mainly as a way for phishers to get certs for "paypa1.com",
> "micr0soft.com", etc. IMO the policy needs to provide us the freedom to
> make subjective judgements as to what indicates a real problem and what
> does not. The point of clause 4 is to provide that needed "wiggle room",
> which again is why I think the new language should go into clause 4.
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 think this is an inferior path. But if the set of
concerns is going to be spelt out so that people like
the press and CAs can in the future can badger the
Director to implement the ones the Board agreed to,
then we owe it to the muggins in the hot seat - the
director implementing the policy - to make the examples
as useful to Mozilla's average users as possible.
So we should put our thinking caps on and all work
on a list of examples.
> * 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" ?
> a single root) when issuing certificates according to different
> Certificate Policies, so that we or others may selectively enable or
> disable acceptance of certificates issued according to a particular
> policy, or may otherwise treat such certificates differently (e.g.,
> in our products' user interfaces). We reserve the right to make this
> a requirement in the future, and to not include a particular CA
> certificate in our software products, to discontinue including a
> particular CA certificate, or to modify the "trust bits" for a
> particular CA certificate, based on the CA's practices in this regard.
Again, I see this as guidance and today's working
concerns.
> I'm proposing this as a recommendation (at present) rather than a
> requirement for the reasons I've previously stated: I don't think we
> should mandate this until it's clear how much of a problem this really
> is, how much it would affect the existing set of CAs already included in
> the products, and whether we're going to make UI and other changes that
> would depend on this. However I do think it's reasonable to put CAs on
> notice that we're thinking about this issue and may take stronger action
> at some point.
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.
> Also, note that I sidestepped the tricky issue of defining and
> determining certificate "assurance levels". I think a better approach
> (at least for now) is simply to recommend that all certs issued under a
> single CA (whether issued directly by a root CA or by an intermediate CA
> under a root CA) be issued according to the same policy.
Certainly, as an interim step, to see whether the
CAs can craft for themselves any commonality in
assurance, and express it in root certs, it would
seem wise to encourage use of different root certs.
But I'd do it in the guidance file. It's strategy
by the director, not policy, and won't be policy
until it is proven and so good that the board is
prepared to sign onto it.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Frank Hecker
> 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.
> 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.
<snip>
> 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.)
Ian G
a couple of minor clarifications: my perspective on the
examples / guidance question is fairly minor; I also
wouldn't want to slow down on the policy.
On the question of how you would make decisions as the man
in the hot seat - absolutely, I'd feel that you would be
wise to the games playing of desparate CAs. I'm more thinking
about what happens when you yourself aren't in the hot
seat, and someone else is; that person may not have the
"Washington DC" perspective.
(Funny you should have called it that, having visited DC
for extended periods, I understood just what you were
referring to ;)
...
>>> 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.
On that specific point, I didn't know that certificates
can't sign. I did some quick searching and wasn't able
to turn up anything that confirmed that and/or gave an
alternate wording. Anyone else know any better wording?
Nelson B
> 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...
Yes. I didn't reply to them there. I will here.
> 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 problem I have with that "any time for any reason" language is that
it is 100% discretionary. I don't think that "guidance" should be
separated from the policy. The whole point of the policy (IMO) is to
give strong guidance to the person deciding on CAs.
Frank, I'm thinking that you and I will not always be as tightly coupled
to mozilla as we are now. I want the policy to be clear enough that a
mozilla sysadmin could administer this policy if we was asked to do so,
and that wouldn't cause a huge change in the policy as perceived by
outsiders. To put it another way, if the next person to mind the store
decides he wants to change the policy radically, it should require the
same amount of care to change the policy as has gone into the creation
of the first policy. He shouldn't be able to change it on a whim because
the policy has given him total discretion!
> "The perfect is the enemy of the good."
"Absolute discretion corrupts absolutely"
>> 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.
Exactly. I want people to have to think things through before
excersizing uncontrolled discretion (or better, for them not to have
uncontrolled discretion).
There are mozilla drivers who have sais they don't trust *ANY* CAs and
just want encryption. I guess they are omniscient and can always well
without any help whether they're being attacked or not. God help
mozilla if they get to excersize total discretion over the root CA list.
>> 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.
Precisely the point! I see that as a good thing!
--
Nelson B
Nelson B
>> 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.
> On that specific point, I didn't know that certificates can't sign.
Indeed they cannot. signatures are made with PRIVATE keys. Certs
contain Public keys.
Public key certificates are used only to VERIFY the signatures created
with the private keys. A CA may have many certificates that all share
a common public key, and consequently certs that are issued by that CA
may be verifiable with more then one of the CA's certs. (This occurs
in the case of a "bridge CA" for example.)
> I did some quick searching and wasn't able
> to turn up anything that confirmed that and/or gave an
> alternate wording. Anyone else know any better wording?
I guess I would change the phrase "that CAs use different root CAs "
to something like "CAs use separate root certs eith separate public
keys..." (The use of separate Private keys is implied by the
specification of separate public keys, since the keys come in pairs.)
--
Nelson B
Ian G
> Frank Hecker wrote:
>> 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 problem I have with that "any time for any reason" language is that
> it is 100% discretionary.
The reason for that language is that *if* it is important
to people then the language will be used against Mozilla
to advance some agenda or other. If you look at the
history of various organisations you will see that some
of them aren't shy of suing people to get their own
way. (e.g., verisign and ICANN, SCO, Sun, Microsoft,...
all have their hordes of lawyers.) So that language is
suggested to remove any doubt as to Mozilla being in
charge of the process, and also to reduce the game
playing that might go on.
> I don't think that "guidance" should be
> separated from the policy. The whole point of the policy (IMO) is to
> give strong guidance to the person deciding on CAs.
I understand the desire to lock in the person into
some "good path". The difficulty lies in determining
that good path, *and* not having that good path be
used against Mozilla (and users).
> Frank, I'm thinking that you and I will not always be as tightly coupled
> to mozilla as we are now. I want the policy to be clear enough that a
> mozilla sysadmin could administer this policy if we was asked to do so,
> and that wouldn't cause a huge change in the policy as perceived by
> outsiders. To put it another way, if the next person to mind the store
> decides he wants to change the policy radically, it should require the
> same amount of care to change the policy as has gone into the creation
> of the first policy. He shouldn't be able to change it on a whim because
> the policy has given him total discretion!
In this we are agreed. I also don't like the examples
languague because it is ambiguous - does the future
incarnation of Frank treat it as policy? or as ideas?
>>> 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.
>
>
> Exactly. I want people to have to think things through before
> excersizing uncontrolled discretion
...The notion of tying people to some policy in
the future is one fraught with danger. No matter
what you think, no matter how noble you consider
your current view ... history shows that things
and views and people diverge.
If you set your views in policy now, and they
happen to clash with future views, then they
will be ignored or breached somehow. In this,
the whole policy is then put in breach.
> (or better, for them not to have
> uncontrolled discretion).
People better than us have been working on this
problem for more years than we can count. Nobody
has come up with a way to limit future appointments
in terms of the actions they can and can't do.
There are lots of mechanisms what sort of work
some of the time, but they rely on law and money,
and they are not much use for Mozilla's open
source, volunteer context. E.g., trustees,
committees, voting ...
An instructive example is ICANN, an organisation
that can do no right. Whatever it chooses will
be attacked by some; in such a situation, how
does one set a policy? Tightly? Then the process
will stall. Loosely? Then the incumbent will
not do the right thing.
The reason that people prefer "loose policy"
rather than "tight policy" is because at least
with loose policy and bad implementors of policy,
you can throw out the implementor. C.f., democracy.
> There are mozilla drivers who have sais they don't trust *ANY* CAs and
> just want encryption. I guess they are omniscient and can always well
> without any help whether they're being attacked or not. God help
> mozilla if they get to excersize total discretion over the root CA list.
Not trusting CAs can be read two ways:
* there is no default reason to trust CAs,
* the CAs are distrusted.
The first is just a logical conclusion of agency
theory (basis of accounting and governance) and
is admitted by the CAs themselves by their
complicated structure, contracts and audits and
so forth. Ask any accountant. Check out Sarbanes
Oxley.
(The second - would require more information, some
of which you may supply yourself, and some of which
can be had by reading the papers...)
But on the whole, I'd suggest that questioning
the blind faith in CAs would be something that
would align with security, and should be taken
seriously, not dismissed simply because it seems
outside ones beliefs.
>>> 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.
>
>
> Precisely the point! I see that as a good thing!
But that means your concerns are the right
concerns. Which means you also have to do
the job, and you have to not do a 'Postel'
on everyone who is relying on you.
You simply can't write down your concerns
and expect other people to understand them,
or to follow them.
Nelson B
> The reason for that language is that *if* it is important
> to people then the language will be used against Mozilla
> to advance some agenda or other.
If mozilla needs to change the policy in the future, it can do so.
> ...The notion of tying people to some policy in
> the future is one fraught with danger.
Then I guess we should have NO policy, eh?
Let every mozilla CA root czar do whatever he pleases, eh?
> People better than us have been working on this
> problem for more years than we can count.
This problem hasn't been around for more years than we can count.
>> There are mozilla drivers who have sais they don't trust *ANY* CAs and
>> just want encryption. I guess they are omniscient and can always well
>> without any help whether they're being attacked or not. God help
>> mozilla if they get to excersize total discretion over the root CA list.
> Not trusting CAs can be read two ways:
>
> * there is no default reason to trust CAs,
> * the CAs are distrusted.
Or a third view: all certs should be taken and trusted at face value.
The person to whom I'm referring (you know who) says he trusts no CAs,
yet he is apparenly willing to use all certs because doing so gives him
encryption. He apparently thinks that encryption == security, and that
authentication is unnecessary. He probably has no concept of MITM.
Maybe he thinks that he can tell if he's being phished or not by
careful examination of the loaded page's contents.
Shall we let him excersize total discretion over the root CAs?
>>>> 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.
>> Precisely the point! I see that as a good thing!
> But that means your concerns are the right concerns.
Our concerns. It means the concerns of the people who collectively
form the policy are the right ones, and no one individual should
have the power to ignore them at his sole discretion.
> Which means you also have to do
> the job, and you have to not do a 'Postel'
> on everyone who is relying on you.
No, the policy does that.
> You simply can't write down your concerns
> and expect other people to understand them,
> or to follow them.
You are arguing that there is no point in a written policy because
people will not follow it. In that case, Frank can stop now, I guess.
I think we are pursuing a policy precisely because we can and DO
"expect other people to understand them [and] to follow them."
--
Nelson B
Ian G
> Ian G wrote:
>
>> The reason for that language is that *if* it is important
>> to people then the language will be used against Mozilla
>> to advance some agenda or other.
>
>
> If mozilla needs to change the policy in the future, it can do so.
This argues both for adding that at a later date,
and taking out things, at a later date. What it doesn't
address is whether any of these ideas are useful or not.
>> ...The notion of tying people to some policy in
>> the future is one fraught with danger.
>
>
> Then I guess we should have NO policy, eh?
> Let every mozilla CA root czar do whatever he pleases, eh?
No, this is the reason that Frank has written it to
be loose in the areas that discretion is indicated,
and tighter in areas where we all seem to agree. I'm
not however expecting it to be perfect, I suspect in
a year, we'll all be thwoking our foreheads over some
mistake or other.
>> People better than us have been working on this
>> problem for more years than we can count.
>
>
> This problem hasn't been around for more years than we can count.
The problem of how to get someone in the future to
follow laid down policy agreed by people in the past
has been around at least since the beginning of
organised democracy.
(I ruled out salaries earlier, which leaves democracy
and laws as a useful analogue.)
>>> There are mozilla drivers who have sais they don't trust *ANY* CAs and
>>> just want encryption. I guess they are omniscient and can always well
>>> without any help whether they're being attacked or not. God help
>>> mozilla if they get to excersize total discretion over the root CA list.
>
>
>> Not trusting CAs can be read two ways:
>>
>> * there is no default reason to trust CAs,
>> * the CAs are distrusted.
>
>
> Or a third view: all certs should be taken and trusted at face value.
> The person to whom I'm referring (you know who) says he trusts no CAs,
Specifically, I don't know who. It would make things
a lot simpler if you just mentioned names, and I
don't see it as a grave accusation as you seem to be
intimating. It would be much more interesting if we
could simply ask the question why this person doesn't
trust any CAs ... and then we could move on to measuring
the policy against that person's reasons.
> yet he is apparenly willing to use all certs because doing so gives him
> encryption. He apparently thinks that encryption == security, and that
> authentication is unnecessary. He probably has no concept of MITM.
> Maybe he thinks that he can tell if he's being phished or not by
> careful examination of the loaded page's contents.
> Shall we let him excersize total discretion over the root CAs?
Well, all this sounds very confused, but I suspect
that's partly your own suspicion over these alternate
viewpoints.
Security is a very difficult area, and there is no
doubt that many are confused about it. I wouldn't
take it as a shocking accusation at all to find some
confused notions there, it's a matter of recorded
fact that the people who put together all of the
systems that we are discussing got some of the areas
completely wrong. This isn't meant to be an accusation,
it's simply a reflection of the complexity of the area,
they did the best they could at the time.
FYI, security is going through a bit of a revisionist
period at the moment, as researchers are working to
disentangle why apparently good systems didn't work
and why apparently bad systems did work. Some of the
notions that are being wound back include such things
like non-repudiation, signatures, identity, trusted
third parties, online certification. These are all
things that have been roundly criticised and where
protocols are themselves based on these concepts,
they also suffer flaws.
(One of the questions I am working on is "what is
security?" and to many people's surprise, perhaps,
there isn't a good answer. What this means is
that almost every system that went out there and
said it delivered security did so almost by
definition on false assumptions. Just by way of
example of how seemingly simple questions can blow
away years of work.)
>>>>> 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.
>
>
>>> Precisely the point! I see that as a good thing!
>
>
>> But that means your concerns are the right concerns.
>
>
> Our concerns. It means the concerns of the people who collectively
> form the policy are the right ones, and no one individual should
> have the power to ignore them at his sole discretion.
No matter what and how the policy ends up saying,
we are still talking about an open source, volunteer
organisation. The power to ignore is built in to
everything that Mozilla does; it's all about rough
consensus and forking if not able to agree.
Frank is trying to write the policy to recognise
that he has no control over who or what the people
do after he's moved on. He's not presenting them
with a fait accompli, simply because they'll ignore
it if its not to their desire.
>> You simply can't write down your concerns
>> and expect other people to understand them,
>> or to follow them.
>
>
> You are arguing that there is no point in a written policy because
> people will not follow it. In that case, Frank can stop now, I guess.
Nope, I'm saying that if it is written as an
expectation, then that ignores the whole ethos
Mozilla. It's a consensus, best efforts, best
judgement organisation, not the army. It would
be totally reasonable to expect someone to say
"today, I'm not following the policy, but I'm
doing this anyway."
> I think we are pursuing a policy precisely because we can and DO
> "expect other people to understand them [and] to follow them."
Help, promote, advise, hope, suggest ... would all
be better than "expect". Unless the guy in the hot
seat is on a salary, and is charged formally with
following the policy, I think expectation is simply
too strong.
Ian G
into whether his suggestions for a draft 12 will be
adequate.
(I would say they are fine; my objections were mostly
theoretical, and the sky doesn't fall down if they
are ignored.)
What it really means is - reading between the lines
here - is that Frank wants to be able to efficiently
complete the policy and present it to the board as
the recommended and consensus-based compromise. But
he doesn't want to do that and then have a bunch of
discussions over points and intentions and expectations
occur *before the board*.
Which is fine and efficient; the idea is to present
the consensus, not expect the board to discover that
there is no consensus, or that there is still wide-
spread disagreement.
So are we at the point where the changes that Frank
has suggested are acceptable? Or is there still a
grave degree of concern with even those changes and
the resultant draft 12?
iang
Ram A M
behind them a technical failure or would it otherwise violate the
spirit of the policy as you see it?