Ben Bucksch wrote:
Frank Hecker wrote:

For example, as I noted in the metapolicy, many people have proposed that Mozilla move away from a CA-based model (i.e., for SSL-enabled servers, S/MIME email, and signed code) and move to a SSH-like model of self-signed certificates.


I'm not alone? Interesting. So, maybe add a "for now" to that meta-rule?


You are not alone!  There has been substantial
work done in the last 5 years or so that has
revealed the "CA-based model" to be .. not as
advertised.

There's also been enough time, and a change in
business climate, so that people can look back
and see how it worked in practice, and how well
or badly competing models worked.


Regardless of whether this would be a good idea in theory or not, IMO it's certainly not a change we can make in the near term, for lots of reasons.


Agreed about the near term.


There is one big problem:  phishing.  This is a
growing issue, related to identity fraud.  It is
a breach of the browser's security model, and
costs a lot of people a lot of money.

Phishing can be addressed by some of the changes
that have been suggested.  Specifically, it can
be addressed by moving from a CA-centric model
to a graduated model (CA and opportunistic) where
users have to complete the security loop.

How big phishing gets will determine how much
pressure there is to modify the model - and thus
defines "the near term."  Right now, there are no
hard stats on how many losses are experienced, so
it's easy to ignore.

(I've seen one ludicrous number, and I likewise
found it easy to ignore:  http://www.antiphishing.org/ )


But if really so many people believe in that model, we should consider moving to it or at least fully supporting it, right now it's not possible *at all* in practice, not even for advanced users, because of bugs like 211498 <http://bugzilla.mozilla.org/show_bug.cgi?id=211498> (I was upset about the treatment of that bug).


It was certainly interesting reading!  The assumptions
from the RFC (at the beginning of comment #11) are the
sort of thing that we now recognise as inadequate for
the construction of Internet security systems.


> This goes in scope far > beyond the policy.


Yes, in principle. There is an open question as to whether the policy makes sense without addressing the weaknesses in the model. Right now, for example, if the policy had to be "concluded" then the security model would be left at listing phishing as a current but unaddressed threat.


So, in the current model, you are vulnerable to governments (actually anybody) which control root CAs.


Correct.  This isn't going to change any time soon.
Anyone who's up against "national technical means"
had better do their research.  It's a bit of a stretch
to say that Mozilla or any browser or any other app
should protect people against *all* threats.


There's probably not much we can do in the policy (the typical SSL model is probably (intentionally) inadequate to protect against that). Maybe it will make a difference in practice during CA evaluation in one case or the other, maybe we can't do anything in practice (in the policy). But I personally think we should acknowledge that risk, be concerned about that, and state so.


Yes, legal or governmental control over a CA should
be listed in any threat model.


I think these criteria are critical to the well-functioning of the whole system. The criteria I mentioned are things I would expect as a *matter of course* from all default CAs. If they are not followed, I'd consider the whole system to be broken. I probably didn't even include everything I consider necessary. Basically, because the whole security model stands and falls with the CAs, I think the criteria for the CA's own security can hardly be too strong (as long as they are still doable). And weak verifying of certs by one CA means practically weakening it for the whole system, because all CAs are treated equal.


That indeed is the crux of the debate.  Strong
quality control on CAs just begs the question:
how strong?  where strong?

Or, fix the model. Which begs further questions...


iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to