Nelson B wrote:
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.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
