Practice Cryptography!
Even with all of the cryptologic and cryptographic technology that has existed in the world for the past 60 years, we still don't really know what encryption is good for or how to use it -- or, more importantly, why it's important. Maybe it's time for people and coders to actually start practicing how to use it, like any other skill.Saturday, February 09, 2008
Message(s) I posted to dev-tech-crypto (mozilla)
recently pointed out to me. The business models of commercial CAs
involves what is essentially "selling trust".
If you look at the fact that they have no real accountability, no
procedure in place in any of the browsers to revoke their trust as a
matter of policy if they violate their CSPs, and a need to maintain a
positive cash flow, you will quickly see that there are severe
conflicts of interest inside the individual organizations.
(If you don't believe my assertion that there is no means to remove
root certificate trust as a matter of policy, I am still waiting for
action on Thawte's issuing of SSL123 certificates by a root which had
a CSP which stated that no SSL server certificates would be issued
without at least "medium assurance" of identity. This issue was
brought up before I moved to my Mac as my primary machine, so over a
year and a half ago.)
Frankly, this entire discussion is utterly and disgustingly ludicrous
in light of this.
Add to this the fact that there is no legal recourse available for
"relying parties" if the CA somehow fails to live up to its CSP, and
the entire argument falls completely on its face.
You all seem to be frighteningly disconnected from the realities of
the situation if you're still arguing the minutae of trust models
allowed by CSPs. I lost my faith in the process you're trying to
follow long ago.
On Feb 9, 2008 8:50 AM, Frank Hecker <hecker@mozillafoundation.org> wrote:
> We also have the problem that the cure (removal of root certs) is often
> seen as worse than the disease (problems with particular CAs), in the
> sense that the actual security threat to users is perceived as not
> justifying provoking user annoyance at having a whole set of SSL sites
> suddenly stop working. So instead of going with the "nuclear option" of
> removing root certs, in practice we've fallen back on the alternative of
> nagging CAs to improve their practices (of which the issue at hand is
> yet another example).
Mozilla (and the other browser vendors). They have to maintain market
share, which means ensuring compatibility -- even when the
compatibility flies in the face of one of the reasons why the CA
program exists in the first place (basically, it was started by
Netscape to make it possible for people to have faith in the
identities of the entities they were giving their credit card numbers
to, in order to facilitate electronic commerce).
The end result is that anyone who chooses to spend a hundred thousand
bucks or so on a single audit can then go around selling the benefit
of their inclusion in the trust list to the highest bidder without
fear of repercussion. Which is what they've been doing. And nobody
has the balls to stand up and say "user security is more important
than user convenience". (In addition, roots have been sold to other
companies, which have not passed continuing conformance audits.)
With this kind of a view, it's more of a "you have to have money and
spend money to make money" game than any kind of attempt to adhere to
the principles that actually allow the system to be 'secure'.
Without fear of delisting and decertification, CAs are running
roughshod (not just 'are going to run roughshod', but 'ARE RUNNING
roughshod'), making a farce of the process and the 'trust' in place.
Without a clear view of user security held by a majority of the
Mozilla Foundation board, everything that happens on this list with
respect to CA inclusion requests is as effective as pseudointellectual
masturbation.
Not that my vote counts for anything since I'm not a member of MoFo,
but until these issues are resolved I must vote 'nay' to any
additional inclusion requests under the current guidelines.
-Kyle H
Archives
2006-02-12 2006-02-19 2006-02-26 2006-03-05 2006-03-12 2006-03-19 2006-03-26 2006-04-02 2006-04-09 2006-04-16 2006-04-23 2006-07-23 2008-01-13 2008-01-20 2008-02-03 2008-02-17 2008-03-16 2008-04-06 2008-05-11
