Hi Johnathan,
Welcome to this thread! Let me try to provide some answers and
thoughts...so don't expect my reply to be much shorter than your post ;-)
Johnathan Nightingale wrote:
my wand is not yet so magical and my power not yet so great that me
saying something makes it law.
Oooo :-( And I thought you are going to make some magic here...really
;-)....
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. If I could be so bold as to summarize this
entire thread in a sentence, I would say that basically all of these
electrons flying are trying to answer the question of which proposal
does a better job of verifying identity in a defensible way.
My point is just that we're all trying to solve the same basic problem
Not really! There are a few reasons, why we came up with an alternative
proposal, mainly because EV provides only a partial solution - if at
all. Our proposal tries to structure *all* SSL at the browser, in the
way it is handled more or less by CAs for some time and by the behavior
of the public (Subscribers and Relying Parties) alike. Additionally, EV
can be integrated into our proposal and it will be obviously part of it,
whereas EV doesn't try to solve the overall problem. It will leave the
browser "broken" as before, since there would be only flat SSL and EV.
Concerning EV there are various opinions - as you might know - and
nothing is proven nor adopted.
Let me claim, that our proposal tries to really solve SSL handling by
the [Mozilla] browser once and for all, whereas EV leaves 99% of SSL in
the same state as before. In that respect it is not even close to what
we proposed.
Please also note, that lower identity verification exist the same as
higher ones and there is no right or wrong, but it very much depends on
its purpose! Strong identity verifications exists since ever, we don't
need to "strengthen" it really...But we have to define and provide a way
to differentiate the various verification procedures (first in the
policy, than in the library, at last in the UI).
(The proposals are what they are, if they suck, let them suck for
technical reasons, not character attacks. And if they're good, let
them succeed on their merits.)
I agree with you! Let me just clarify a few things here:
- First of all, I suggest to let EV succeed within the structure we
proposed (and or in the old flat system) and not by incentives of "green
address bars" and other marketing hypes we saw already. *That* would be
the *real test* for it...(How many would run for it??)
- Second, I'd like to make clear, that we (Me and the company I work at)
don't want any credit for this proposal nor any fame (concerning our
character in this). We sincerely want to get things fixed and improved
from the moment this EV stuff started here. We studied the EV proposal
without any bias and came to our conclusions after learning the details.
Since there is willingness and thought of changing the way [some] SSL
certificates are handled by the browser, I believe that it has to be
improved from ground up (and not by putting some sauce over and on top
of it). So with the same investment we can achieve maybe much more...
2. Eddy is noble in his attempts to avoid (for the moment, anyhow :)
.....So eventually, obviously, we have to come back to the UI.
Sure! But I think you can't really start to tackle the UI if you don't
know what the deal is? Obviously this was exactly the way EV was treated
here, meaning there are the definitions on one hand and the UI will be
whatever....
In addition, one has to understand, how the underlying framework should
work in order to think about the best UI implementation. And how are
certificates handled generally and what do they mean actually... So
perhaps we should work on both proposals concerning the UI (ideas,
brainstorming), until a decision can be made? Obviously our proposal
requires somewhat more brainpower than EV ;-)
What information do our users want, need, and understand, when it
comes to safety on the web? And how much of that should be conveyed
by CAs through SSL Certs?
Oh, that's a good one!
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.
Exactly...so it was not said in this specific thread, it has been
mentioned many times already on this mailing list....
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"), 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 don't provide assessments about reputation and trustworthiness!
Period! They provide verification of certain facts (Domain, Email,
Identity, Address, etc). Obviously very important indications, but one
of the mistakes made so many times over the time is, that claims were
made about trustworthiness (including today, including EV) ...and then
it didn't live up to the expectations...
With this is mind, a proposal that imagines 4 (or 3, or 5) levels of
cert must tackle the UI question head on because, in an environment
where a richer level of detail is communicated to the user, those 4
categories have to be really relevant and distinct to provide a
meaningful contribution. 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."
Imagine that we found a way to clearly present to the user:
+ Your connection is encrypted
+ The site's identity has been verified
+ You've been here many times before
+ This site is trusted by (your friends | bbbonline | other vendor
rating sites)
+ This site appears on no blacklists
Doesn't Opera have something similar to this (called "Security
Information" window)? However I think, that the SSL stuff and the other
indicators should be separated in some way, specially since the later
apply to plain http as well (and are perhaps much more important in that
respect, because of the missing indications of identity verification).
Identity is a piece of online safety, but it isn't all of it, so my
goal in these discussions and others like them, is to arrive at an
answer for what the identity piece looks like, without losing sight of
the fact that it is only one piece of context.
Amen!
I don't think we as an organization are tied to EV and EV alone.
Right....again EV is part of SSL (and not the other way around). This
type of verification isn't new at all...and tomorrow there will be PVC
and CFF too...
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.
I couldn't say it better... (So most likely Gerv and me will disagree on
what exactly will help the user) ;-)
Now some practical questions: Which process do you propose now? What
should be done after what? Are you going to make suggestions and put
forward ideas concerning the UI. Or do you expect [some of] us to come
forward with them? Can this list continue to work on the proposal (and
perhaps eventual extension of the Mozilla CA policy)? Should the UI wait
for the framework? Do the proposals (ours, EV) depend on the UI
proposal? Or should they be implemented without relation?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
