Johnathan Nightingale wrote:
1. To a first approximation my sense is that, unsurprisingly, EV and
Eddy's proposal are trying to accomplish the same thing: strengthening
the internet's TLS/SSL certificate infrastructure to provide stronger
identity verification.
Actually, I'm afraid I might have to quibble even over your attempt to
find common ground. :-(
EV is indeed an attempt to strengthen identity verification. (How well
it will work in practice is, of course, under debate.) Eddy's proposal,
however, is an attempt to map a generic underlying framework onto the
status quo. His suggestion is that CAs self-classify their existing
offerings into one of 4 categories.
Therefore the reason I object is that it seems to me that, in the face
of the new consumer-level identity spoofing threats which were not
present for the first ten years of the life of SSL, _none_ of the
current practices are sufficient. Therefore, classifying them doesn't
really help.
Examples:
* https://www.noticall.net/ has a certificate issued under current
organisational validation practices, and has an "O" field (the one that
Opera and IE display) of "Chase".
* https://www.noticall.org/ has a certificate issued under current
organisational validation practices, and has an "O" field of "Fleet".
Both of these are the names of banks. The organisation which obtained
these potentially confusing certificates (to prove a point) didn't even
have to lie to get them. I'm sure those willing to stretch the truth a
bit more could achieve "better" results.
The second part is critical, because one thing I haven't seen reflected
much in this thread (for obvious reasons) is that a cert is not the only
source of info we have here. We have a user's browsing history ("Note:
this looks like your bank's site, but it's the first time you've ever
been to this url"),
Just for your interest, I proposed a UI to take advantage of that fact a
while back; I called it "New Site" or "First Visit":
http://www.gerv.net/security/phishing-browser-defences.html#new-site
Although some of them are out of date (or I would no longer agree with
particular UI proposals in them), you may also be interested in other
documents in the Phishing category here:
http://www.gerv.net/security/
we have the anti-phishing blacklists, we have third
parties like resellerratings and bbbonline that bite off the piece CAs
don't want ("Yes, this site is trustworthy, their reputation as a
business is positive"). CAs are nonetheless critical in all of this
because more than any other group, they have the ability to do the kind
of validation that both EV and this proposal seek to provide, and that's
important information.
And, of course, they are the bedrock of all that the browser can know.
After all, you can't contact bbbonline over an unverified channel in
case you end up talking to someone else. So you need CAs to verify you
are connected to the BBB. :-)
Also, certificate information is the only real-time information we can
get without the privacy violation of sending all your visited URLs (or
domains) off to a third party.
As beltzner mentioned in his post, we can more
easily talk to a user about the difference between "Encrypted" and
"Encrypted + Identity Verified" than we can about the difference between
"Identity Verified" and "Identity better verified."
I agree. And (see my examples above) I'm not sure that some current
practices allow us to assert with any confidence that the identity has
been verified. And, absent a validation standard to which CAs can sign
up (EV or something else), and absent the desire of the Mozilla
Foundation to play "CA Cop" and spend ages evaluating the different
procedures of all the CAs, all we can do is lump all existing
"organisationally-validated" certificates into the same "identity not
sufficiently verified" category.
Yes, this is a really bad situation for the industry and the Net to be in.
4. I think Gerv was right on when he said that (I hope I'm not
misquoting him here) Mozilla would have no problem with there being two
strong standards for identity validation, EV and XYZ, and with
presenting them both using whatever "Identity is verified" UI we evolve.
I don't think we as an organization are tied to EV and EV alone.
You aren't misquoting me. :-) But I did go on to say that each such
standard we support is an effort, and so we'd need good answers to
questions such like "How is this different from what we already support,
and why should we care?"
Our goal is to create a safer environment for our users and when we
can't protect them actively (e.g. aggresive anti-phishing warnings) we
want to at least enable them to make good decisions. The acid test for
me, for any proposed standard like this, is whether it will help users
do that more successfully.
While I applaud the goal, my concern is that even today, users do not
take any notice of the lock, and happily type CC details into
unencrypted forms served from IP addresses. (OK, so the UI could be more
visible.) There's obviously a continuum between "dump all the raw info
on the user and wash our hands" and "make the decision entirely
ourselves, blocking all access to sites we don't like", but I think we
need to be closer to the latter end than the former.
Some user education will be unavoidable; however, minimising user
education is a serious plus point for any proposal. See:
http://www.gerv.net/security/stay-safe/
and associated discussion, and also:
http://www.squarefree.com/securitytips/users.html
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
