On 23/12/08 20:23, Kyle Hamilton wrote:
On Tue, Dec 23, 2008 at 10:43 AM, Frank Hecker
<hec...@mozillafoundation.org> wrote:
I've asked Robin Alden of Comodo to make an accounting regarding these two
issues. I don't expect to see that immediately (i.e., in the next day or
two), though I also don't expect to wait a month for it (as Kyle is
concerned about).
Actually, I think it's very important that the accounting include this:
for each name (not just certificate, but name in
subjectAlternativeNames) that has been certified, a connection to the
TLS ports should be made, and the certificate presented by the site
compared against the certificate that Comodo issued. This obviously
won't be a complete verification, but it should give a start to see
how widespread the problem is.
Um. Some questions... On what basis are we asking for this "accounting" ?
Is there a criteria that calls for public breach accounting? Perhaps
Mozilla needs to add it? Most of the criteria call for revocation when
a false cert has been issued, and that seems to have been met right now.
Also, some of the process might instead rest with Comodo's external
auditor or its internal audit process or its internal security process.
Perhaps in the next audit, there will be an examination of the
remedial steps taken, to see if they conform to the security manual, etc.
There are some slippery slope aspects here. If the framework for such
"accounting" is outside Mozilla's area, then care might be needed.
There could be confusion in role and liabilities.
It's nice if Mozilla were minded to do all the audit and security
activities for all, but I'm not sure Frank has time ;) OTOH, if we feel
the need to usurp the CA's processes and the conventional audit
relationship with an "accounting" then perhaps we need to also simplify
some other processes?
Another aspect here is that the goal of any security or governance
process is not to eliminate or stop all breaches. The process is more
about how you keep dangers to a minimum, deal with the breaches that do
happen, and improve.
I hate to say this, but this IS The Worst-Case Scenario.
Noooo.... With respect, I'd say worst case is that a root has been
breached, and the Carders have got hold of it and are MITMing the major
retail sites. Damages!
Earlier, Frank used the language of "clear and present danger."
* clear: we can measure the costs of it, and cost of defences.
* present: it is happening today, provably.
* danger: it can be shown capable of doing damage, at least in theory
Only the last one is shown. It is a danger in that anyone relying on a
cert wrongly issued could be harmed. But it hasn't actually caused
anyone damages, and nobody has shown it to exist.
This situation is about as harmful as the average exploit demo. In this
particular case it was caught by an insider rather than by an outsider.
However, beyond that, the situation is already sealed in that Comodo
have already taken the urgent triage steps to make sure nobody else gets
one.
A CA has
gone rogue and issued certificates that violate its standards, and the
standards of the root programs that it's a part of -- it is true that
Comodo didn't /intend/ to go rogue, but it has, and we can't afford to
let it damage the greater PKI.
This is no different to when Verisign got schnikered into issuing a
couple of Microsoft certs. No damages ever resulted. The system worked
as it was expected to, it seems. Panic is not called for.
Since every CA in the root store is
treated the same, there is no differentiation between them -- and this
means that Verisign and Comodo and Thawte and *every* CA share the
same reputation. If one goes rogue, it's exactly the same as if all
of them have gone rogue, in the eye of the end-user.
...
THIS is why I want to see greater differentiation in the browser
chrome between CAs, so that one bad apple doesn't spoil the whole root
barrel. THIS is why the argument against changing the chrome (user
convenience) fails.
Oh, on that, yes, strongly agree. There's no trust without brand :)
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
