Ram A M wrote:
Frank Hecker wrote:
I am perfectly willing to impose other
requirements on CA, like issuing technically correct certs, operating
to
particular criteria, putting a "floor" on acceptable vetting of
subscribers, and the like. I'm happy to take suggestions on this from
you and others.
Suggestion: Require support for programmatic revocation checking before
illuminating the "safe for e-banking and e-commerce" light. That means
either raising the bar on CAs that qualify for the lock and gold
background, or, making a UI change that enables an intuitive
distinction between those that do and those that don't.
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.
Turn the problem around and look at the cost of
falsely showing that you do revocation; at the
moment revocations seem to be done with just
shoving lists in a directory.
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."
A back of the napkin version:
1 Bad guy registers domain name using bogus contact information and
carefully choses a domain name that looks like it is "Example Bank of
America"'s, let's say "examplebankofamericaonline.atld."
2 Get domain-control certificate for it, process requries ability to
receive email for [EMAIL PROTECTED] and pay for
it with a [stolen] credit-card.
3 FF will now light up 'safe for commerce and banking' and the user
will see they are interacting with Example Bank of America's online
presence.
So, this can happen now, right? We agree then that
the problem - the state of the world - is here and
now. So 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?
Let's assume the domain-cert issuing CA has a reasonble revocation
policy and decides to revoke that cert to protect future would be
victims. Without revocation data being present in the EE certs, or
someother way of relying-party software programmatically checking for
revocation, this method of mitigation is useless. Given such support
this enables shutting down that site as quickly as the latency
associated with the revocation process, technology, and service
characteristics.
My understanding is that no browser gets shipped
with any revocation system turned "on", right? So
this is an untested system, yes?
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.
Costs of revocation support policy for commerce and banking profile:
1 the marginal cost to the phisher which is zero.
2 the marginal cost to the CA - this is the cost of running revocation
which is non-zero, perhaps revocation is to heavy a burden to place on
CA services that are not trying to serve internet commerce sites.
3 cost to the user is relaively small - the increased cost of CA
operations is built into the service price which is effecitvely shared
across a site's customers. Such that Big Bank passes on their marginal
$WHATEVER over their 100,000 customers.
Benefit of revocation support policy for commerce and banking profile:
Quick and easy method for closing down window that doesn't require
finding ISP contacts in every country that each have relationships with
the appropriate governing body in country with jursdiction to have a
domain name taken down (don't forget their is technology latency their
too).
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.
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?
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
