Richard Freeman wrote:
I think the cert-by-email practice could work with suitable safeguards.
Yes, I was thinking something along these lines.
Nelson was for proposing more stringent ways
to tie down the "identity" than email because of
the fairly easy to spot difficulties. It's very true
that email isn't that strong, but survives where
people are being a little careful and it doesn't
really matter.
I think the main way this works in the auditing
world is:
a. make a statement about what you are doing,
b. show how you keep to that statement.
So if the statement is "we check the email only."
then it's easy to meet, as well as being a low
standard. If however the standard is that "we
check that you can trust in sending your CC to
this business" then it's a high standard, and is
also a lot more work in showing.
The question then is, what is the statement that,
say Verisign makes, as opposed to CACert, and
do we accept the differences, or do we want them
to be the same?
This is a big dilemma. I can't see a world where
all CAs do the same thing! But I also can't see
a world (yet) where we can show the users the
difference.
It all depends on what we're certifying. Are we saying that you are
connected to example.com, or that you're connected to a server owned by the
human being who bought example.com?
The first prevents man-in-the-middle attacks, and the second prevents
phishing over SSL (or at least makes it easy to find out who the guilty
party is). The first probably can be done via email. The second would
probably require an in-person visit with government-issued ID (possibly
more than one form). Anything less than visual inspection of ID by a
trusted party would make the system unsuitable for prosecuting somebody
based on abuse of SSL identity - which is what you need to stop phishing.
Right. Now, I'm scratching my head on this one,
where in the SSL world or the CA world does it
say that the business identity is the thing being
checked? Is this something that just ... emerged?
We know the domain name is being checked, and
we can trace this to the cryptographic security
model of SSL: It provides encryption in order to
stop eavesdroppers. In order to overcome spoofing
(a.k.a. MITM) the domain name is checked in the
cert.
But, the cryptosystem only asks for the domain
name to be checked ... primarily I think because
in those days it was fairly obvious that anyone
could easily hijack DNS and DNS resisted easy
fixing (still does!).
So the central question is: domain name or
business identity?
[snip]
1. You sign up via a website. The website sends you an email containing a
verification link. All communications are signed, and include a copy of
the certificate request.
2. They repeat this at a few intervals over a week or two. At random
times.
The other thing that can be done is to prove
ownership of the website. Ask the cert provider
to insert XXX into the HTML of the domain's page.
In fact, it is common practice to "offer deals" to
people if they put their logo on the site in a small
tasteful corner (Intel Inside meets viral marketing).
So CACert would say: ok, first step, put this logo
on your site [proudly using CACert]. Then send
us the CSR....
I guess it really depends on what you want SSL certs to prove. I'd argue
that right now they don't meet the standard some people are proposing - so
why worry about lowering the standard?
I would be surprised if phishers couldn't walk
through the major CA's practices right now like
chocolate through a goose... There's a huge
difference between selling certs to honest
people and putting up a facade of faxed paper
work, and having to deal with people who will
basically lie about anything to get your cert.
Phishers are experts in creating forged info,
remember.
The only way we're going to have really strong SSL certs would be if
governments issued them and they were kept exclusively on smartcards so
that the average member of the public wouldn't let them get out of control.
LOL.... be careful what you wish for!
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
