Some comments.
Heikki Toivonen wrote:
Some people have pushed for making SSL errors such that you cannot just
click OK and proceed to the site. I'd like to see that happen. The thing
that seems to be holding this back is the fear of misconfigured sites
becoming inaccessible. In any case, that can be done with or without EV
certs.
The thing is that this is making a judgement call
that the programmer knows more than the user.
A moment's reflection should lead us to realise
that this can never be true; the programmer is
programming today, the user is working tomorrow;
the programmer has info from a book, the user has
info from their site, their company, their support
personel.
Certain things the programmer can know better:
whether to use SHA1 HMAC or AES in garble
mode ... but the programmer can never know the
identity better than the user.
Duane wrote:
This might be good or bad, disabling click through might end up making
people disable SSL altogether, ...
Right, in which case ... there would be a reduction
in security. Security can be measured by the average
that each person gets, multiplied by the total number
of people. If a system is only enabled 1% of the
time it ain't delivering much of anything.
I fail to find the logic in not letting me know the identity of the
website operators I want to do business with.
Well ... complicated. First, there is the identity of the
website operators ... then there is the risk that this is
wrong ... which is somewhat mitigated by the knowledge
that a certain CA might have signed a cert over a certain
domain.
But, that cert only makes any sense if you know the
CA that signed the cert. The blah-blah standard isn't
so much at issue; what is at issue is who signed the
cert, and what did they mean by their signature (which
might include the blah-blah standard or the whoop-de-
doo standard or the trust-me standard... ).
So, anything that adds the CA name to the chrome
is a good thing. Anything that hides the CA name
from the chrome is a bad thing. We've been living
with a bad thing for the last decade, back to the beta
of Netscape (can't recall the version) where they
dopped the CA name because of real-estate wars.
... because of cost very
few people will purchase EV certificates, in my opinion it will be a
really small amount, perhaps 1, or at most 2% of all certificates
purchased (I think someone else mentioned that Verisign only expects
1%), so we are left with a situation of EV certificates only covering 1%
of business, this will either discriminate against small business that
doesn't have a business case to pay exorbitant fees for SSL certificates
or they will simply not use SSL at all so there is no warnings presented
to users, this could have a very negative effect rather then a positive one.
Well, it means that the smaller CAs than Verisign
will not be able to issue EVs. Go do the maths,
the whole concept is designed to be very expensive
to implement, and if Godaddy gets 1% of its volume
from its EVs it won't be able to cover the additional
cost.
Hmm, so is your suggestion that instead of EV we should use something
like petnames instead? I don't think petname-like systems alone can
solve the problem nor do I think EV alone can solve the problem. I think
we need both. This thread is about discussing EV.
The point is that petnames cover 80% of the phishing
risk at $0 cost. EV covers 1% of the phishing risk at
>>$1k each for tops 1000 certs, and way more that
in rollout costs.
I don't think we need EV certificates, it's a thinly veiled attempt at
retaining a monopoly position, however it has the potential to back fire
and put users at more risk, not less.
People have been creating relationships for a very long time with
business without having some 3rd party tell them the relationship will
be good or bad (word of mouth is still the best form of advertising).
That's all that petnames do -- let you name your
relationship.
The bigger issue here is identity checks don't show trust, they show
identity, Gerv is saying this is ok because the checks are extensive
enough that you will be able to sue someone, but this isn't always the
case, take Enron for example, I'm sure before all that happened with
them people would have said they were trustworthy.
It's not true that the checks permit suits, and the
document is almost structured to ignore suits.
Not exactly, there are a couple of throwaway
lines, but the bulk of the document works to
maintain the line that users cannot rely.
Well, that is not entirely fair ... the document
does *finally* raise the possibility that liability
must not be limited below $2000. It does not
however offer the user $2000 of *protection*,
that is a very different matter. Expected Value
(another sort of EV) would lead us to suggest
the value to the user is v. much less, like around
a few bucks.
Where is the research and studies conducted to say this is any better
then what we have already? Where are the impact studies to show that
this won't in fact lead to less SSL use, not better SSL use? In fact was
any research or studies conducted to say this will do anything to
protect users, or is this simply a thought exercise saying this is what
we think is best for everyone and what we say goes?
LOL... My impression from reading the document
was that after 15 years of trying, the PKI field has
learnt nothing from the experiences of failure. Not
a thing, they have written this to fail, and I can't
even see how Verisign will make it work.
iang
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
