Ram A M wrote:
If I was a rogue CA I'd consider that hardly a
barrier. It wouldn't take more than a weekend
to knock up a "null revocation" service AFAICS.
I don't see anyone throwing their arms up over an immediate patch to FF
to remove a CA that does this.
It's never been done as far as I know. Maybe
we should defer conjecture until it has been
done?
Turn the problem around and look at the cost of
falsely showing that you do revocation;
Cost is not being a CA. Once you demonstrate bad intent people are
quick to shun you. Your statement doesn't seem thought out, that's ok -
I'm not perfect either.
I perceive we are talking at cross purposes here,
so I'll make the rest as brief as possible and
try and stick to facts that we can agree on.
Even if you are talking OCSP and automated checking,
it would still seem to be relatively easy to knock
up a server using open source code that just reports
"no revocations today, come back tomorrow."
It would take a lot more than that to affect an attack which suggests
it makes the overall PKI model resilient. Maybe if you think about this
from a more inclusive perspective it will help.
Sticking to facts here - are you saying that it
is not possible or is inordinately expensive to set
up an OCSP server that simply reports "none today"?
Are you saying it would not be plausible to trick
Mozilla into believing that you ran a CA with full
revocation? From a bedroom? Of if you were the
Chinese government intent on tricking your dissident
users into revealing themselves?
The domain name system is meant to serve a diverse audience. That means
some of its users security needs unfulfilled. PKI style delegated
authentication is part of an answer in several ways includng that it
brings the notion of identity into play which allows the existing legal
and law enforcement systems to add their capabilities to the system.
Authentication is imperfect and so the upfront vetting process of even
a really hard trying CA is imperfect. The better the authentication
practices the fewer failures. Revocation is useful in addressing the
remaining weaknesses of authentication procedures.
You point out that things are imperfect. You seem to argue both the
position that PKI helps and the position that PKI doesn't help. You can
drill down on many things and find them imperfect. I assume you can
find imperfection in the 'show the CA brand on the chrome' concept and
yet you argue it is a worthy addition. What gives?
A worthy question. The great value of the
'show the CA brand on the chrome' is that it
takes Mozilla out of the judgement game and
into the tools game. In testing it against
the phisher, it seems to answer that threat.
The recovation process has more complexity.
It has scaleability problems. It relies on
the CA being non-rogue. It introduces a
contradiction into the nature of offline
certs (that which certs are there to do).
It requires it to work very well for it to
be effective. And it further embeds the CA
into the "trust" equation which puts an ever
increasing reliance on the CA.
Does it answer the phishing threat? I don't
see that. It seems too easy to bypass if
enough attention is put in place. But I'm
prepared to see how this is wrong.
Now, as these are both "future" or "emerging"
ideas, I'd say sure, go ahead and experiment.
But that's not what is being proposed here -
what you are suggesting is that revocation is
good enough to differentiate between good
CAs and bad CAs.
Is that indeed what you are suggesting? I'm
simply asking that we get the facts here.
Revocation being good enough for *policy* I
don't see. So I wouldn't suggest it be part
of a policy as yet.
(Nor do I suggest that chrome branding be
part of policy.)
changing the policy to slow down the influx
of dodgy CAs is only half the story, and unless the
other half - cleaning out the current lot of dodgy
CAs - is put on the agenda, this is an incomplete
approach?
Where did you get the idea that evaluating the current CA list is not
on the table?
These forums. Current policy. It is the project
statement that no revision of the current list is
to be undertaken until the additions are made.
My understanding is that no browser gets shipped
with any revocation system turned "on", right? So
this is an untested system, yes?
Wrong. Revocation checking is on by default in quite a few systems at
this point, even public consumer ones. Deployments are more prevalent
on the wireless infrastructure because of different risk profile. Also
Microsoft Windows has revocation checking turned on by default for
code-signing last time I checked, and has been that way for quite a
while if memory serves.
OK. Which browser has it turned on? And has anyone
reported on the experiences? For web browsing?
I know you will find these questions uncomfortable,
but they are what for example TrustBar has shown -
field experiments and experience against phishing,
which is the threat.
From a policy point of view, it would be wise to
see this thing in action, and then adjust the policy
to suit. As the current root list is apparently full
of control-of-domain opportunities, this doesn't
represent a problem.
I strongly disagree with your suggestion that we should wait for heavy
exploitation before adopting useful technologies. Fortunately for both
of us, I know I'm not alone in this.
I'm not saying don't adopt. I'm saying do not
set policy to rely on it before it has been shown
to make a difference. I take it you are not at
this stage claiming it has made a difference?
OK, but that's on paper. The notion that someone has
a quick and easy way for closing down a web site is
so ... much further forward than where we are now, that
I would be skeptical. Let's see this thing in action
first, before relying on it, as nobody else has ever
been able to do such a trick.
Wrong. CAs have been revoking certificates for inappropriate use for
many years. That is even if a "subscriber" (to the CA service) is
correctly named a certificate a CA may decide based on policy that they
will revoke the subscriber's certificate. In the case of private
deployments (where a CA operates a PKI system for lets say a wireless
carrier, large corporation, government body etc) the policy is set by
the CA customer (the wireless carrier) and enforced by the CA using
whatever feedback and control mechanisms are specified in the defined
policy. This is really old stuff and there are many examples.
In action - against an aggressive target. The
fact that someone runs a recovation for an
administrative purpose is not the same thing.
There was very little UBE in 1995. I wouldn't count that as an
argument
to say that the email infrastructure was good enough for broad
adoption. The value of UBE went up and the problem grew to suit.
What is UBE?
http://www.sendmail.org/~ca/email/spam.html
Not all 'SPAM' is UCE as fraud or politics are not typically included
in "commercial."
For others, UBE is Unsolicited Bulk Email.
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
