Extended Validation Certificates
Gervase Markham
called the CA/Browser Forum (CABF), an association of the major
public-facing CAs and all the major browser-makers except Apple. See
http://www.cabforum.org/ , which went up recently.
Currently, there is no minimum level of validation which is done before
a certificate is issued, leading to the existence of "domain control
only" certificates, which have no information in them about the party to
whom they are issued. Such certificates have some uses, but are not
recommended for e-commerce. Other CAs claim to do more vetting -
however, their methods are trade secrets and there is no
standardisation. However, the current browser presentation of all
certificates is the same padlock icon.
The aim of the group is to develop a new, higher standard for the
validation which is done before certificate issuance, called Extended
Validation. The idea was that such certs would be presented differently
in the UI, to give the CAs a reason to go to the extra effort, and to
give customers a reason to buy them. In IE 7 at least, the use of an EV
certificate is tied to the green background in the URL bar.
The Foundation representatives have so far not made a commitment to the
CABF on the exact timing or nature of our support for EV. This includes
the UI.
The guidelines have been developed via a very long and drawn-out
process, including several face-to-face meetings with competing
specifications from different groups of CAs over the past two years.
Eventually and quite recently, a Microsoft employee synthesised a
unified specification, which has now been made available for public
comment. The latest draft of this document can be found here:
http://www.cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
The Mozilla project as a whole needs to decide whether EV will make a
material difference to the reliability of information in certificates
and, if so, whether that warrants a different UI presentation for EV
certificates. It would also be good to have a more general discussion
about how we present security information to users.
All comments welcomed. Ideally, I would be able to give any feedback to
the editor before November 19th, after which there may be another vote
on adopting the updated specification. If you have any questions about
the process or the CABF, please ask.
Gerv
Eddy Nigg (StartCom Ltd.)
Currently we (StartCom CA) are studying the documents of CABF since
yesterday and we are going to comment on this within the next few days.
Thanks for opening this thread!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
> For some time, the Mozilla Foundation has been taking part in a group
> called the CA/Browser Forum (CABF), an association of the major
> public-facing CAs and all the major browser-makers except Apple. See
> http://www.cabforum.org/ , which went up recently.
> <snip>
>
> The Mozilla project as a whole needs to decide whether EV will make a
> material difference to the reliability of information in certificates
> and, if so, whether that warrants a different UI presentation for EV
> certificates. It would also be good to have a more general discussion
> about how we present security information to users.
>
> All comments welcomed. Ideally, I would be able to give any feedback
> to the editor before November 19th, after which there may be another
> vote on adopting the updated specification. If you have any questions
> about the process or the CABF, please ask.
>
> Gerv
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
Ka-Ping Yee
On Wed, 1 Nov 2006, Gervase Markham wrote:
> For some time, the Mozilla Foundation has been taking part in a group
> called the CA/Browser Forum (CABF), an association of the major
> public-facing CAs and all the major browser-makers except Apple. See
> http://www.cabforum.org/ , which went up recently.
I have looked over the draft guidelines at
http://cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
(yes, the extra dots look weird but seem to be correct) and my first
question is this:
The first primary purpose of an EV certificate is to identify the
legal entity that controls a website.
Clearly individuals control the vast majority of websites. So why
are individuals forbidden to get EV certificates?
-- ?!ng
Duane
> Clearly individuals control the vast majority of websites. So why
> are individuals forbidden to get EV certificates?
If you have to ask, you can't afford it...
--
Best regards,
Duane
http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP
"In the long run the pessimist may be proved right,
but the optimist has a better time on the trip."
Gervase Markham
> The first primary purpose of an EV certificate is to identify the
> legal entity that controls a website.
>
> Clearly individuals control the vast majority of websites. So why
> are individuals forbidden to get EV certificates?
Good question. The original answer was that it's much harder to get
sufficient verified information on an individual than it is on the
existence of a company; in other words, it was fallout from the strength
of the vetting.
However, several CAs have expressed displeasure at this, and are working
in the next few weeks to try and find a way to expand the guidelines to
allow more different types of entity to get EV certificates, without
weakening them.
Suggestions as to how that might be achieved would be welcome.
Gerv
Eddy Nigg (StartCom Ltd.)
about the proposed EV certificates draft. Obviously they are mostly
interesting from our perspective:
1.) As mentioned already on the list, extension to individuals in some
form would be indeed interesting.
2.) Under section C. 4. (a) Compliance:
It is not fully clear to us, how approval by the CA/Browser Forum is
preformed and how equivalent of the WebTrust programs are defined. In J.
(a) 1) it says "/or a currently valid unqualified opinion indicating
compliance with equivalent audit procedures approved by the CA/Browser
Forum/", but this unqualified opinion is nowhere defined? Also
membership at the CA/Browser forum is currently an exclusive club of
CA's, but we'd like to know if issuance of EV certificates is a
requirement for membership or can there be membership without actively
issuing EV certificates? It is regrettable, that there is explicitly
the mentioning of "WebTrust" instead of "a neutral and competent 3rd
party" or allow for alternatives such as ETSI. This monopoly isn't
really healthy and doesn't reflect the Mozilla CA policy! Additionally
we'd suggest to make sure, that CA's approved and included by a minimum
of one or two software vendor's software will be able to issue EV
certificates (according to the guidelines) and accepted as such by the
relevant software vendors - including the listing of the CA in CA/BF,
even if a CA is not present in some of the (other) software vendors.
3.) Under section C. 4. (c) Insurance:
The draft mentions two different insurances with 2 million, resp
5 million US$ coverage. However it doesn't say, if this insurances are
for all the CA business or only for the EV certificates. Assuming that
it means for all the CA business a CA may perform. However there is no
ratio given to issued certificates, meaning, that there is a difference,
if a CA issued 1 million certificates or 100 (Just an extreme example).
I suggest to make that relative to the issued certificates, i.e. for
every X issued certificates the CA must be covered for Y US$.
The value of an insurance may decrease tremendously for CA's which
issue big amounts of certificates, making a big CA's potentially weaker
insured than smaller ones, whereas smaller CA's would have a higher
overhead for insurance costs it doesn't really need because of the
smaller amount of issued certificates. In short, this should be perhaps
defined better.
4.) Also not clear is, how the software vendor "knows" about, if a
certificate is EV. We understand, that CA roots and Intermediate CA
signer certificates can be marked as EV issuers, however Intermediate CA
lifespan is usually lower than the root certificate of the CA, in our
case valid for 5 years. Does software vendors have to manage a list of
CA signer certificates which are EV issuers? How does Mozilla intend to
handle/manage that?
This are the most critical parts, which we think should be addressed. We
will not "vote" if to follow the "psychological" green address bar, but
would like to have the issues above addressed properly. Additionally
here a few suggestions: Obviously a very small number of businesses will
acquire EV certificates, but somehow discriminates other properly
verified and serious certificates issued, making them "less" valued,
which we think is wrong! When the idea was first published, we expected,
that certificates would be more divided into categories, such as Class 1
- 4, or in other words:
1) Domain validated only,
2) Reasonable verification of the identity/business,
3) Thorough verification if identity/verification,
4) Government authorized or issued, or similar to EV,
reflecting the status by different colors. This would give the user more
indications about the status of the certificate without being a PKI
expert. In the current proposed draft, the current situation will remain
similar to todays confusion, except the introduction of an elite and
expensive new standard. This is not exactly what was proposed and
suggested in Toronto a year ago (at least to our understanding)!
Therefore the real issues of the "browser lock only" indication is not
solved, which is regrettable!
Thank you for giving us the chance to voice our concerns and opinion.
Robert Sayre
>
> Good question. The original answer was that it's much harder to get
> sufficient verified information on an individual than it is on the
> existence of a company; in other words, it was fallout from the strength
> of the vetting.
Will we see Extended Extended Validation Certificates in a few years,
after CAs sell too many EV certs? Is there an incentive for them not to
do that?
- Rob
Gervase Markham
> Will we see Extended Extended Validation Certificates in a few years,
> after CAs sell too many EV certs? Is there an incentive for them not to
> do that?
What do you mean by "too many" EV certs? Do you mean "if they start
selling EV certs to the wrong people"?
If a CA sells an EV cert to someone who subsequently does use it for
fraudulent purposes, we'll do a number of things.
Firstly, we'll take the information we have gathered about them and pass
it on to law enforcement. If things are working well, then they'll get
arrested and charged.
Secondly, if some of that information turns out to be incorrect (and so
perhaps we couldn't find the person after all), we'll analyse what
happened, find the hole in the procedures, and issue an update to the
document tightening them. The document is not a standing target.
Gerv
Robert Sayre
> Robert Sayre wrote:
>> Will we see Extended Extended Validation Certificates in a few years,
>> after CAs sell too many EV certs? Is there an incentive for them not
>> to do that?
>
> What do you mean by "too many" EV certs? Do you mean "if they start
> selling EV certs to the wrong people"?
It seems like EV certs are claiming to provide the sort of protection
regular certificates were initially supposed to provide. Could you
explain why this is not a bait and switch, because it looks that way to me.
Surely we should support them, just like we do normal certificates, but
I don't see why we should present them any differently in the UI.
- Rob
Gervase Markham
> It seems like EV certs are claiming to provide the sort of protection
> regular certificates were initially supposed to provide.
Yes, basically.
> Could you
> explain why this is not a bait and switch, because it looks that way to me.
I don't understand what you mean by "bait and switch" in this context.
Certificates may, at one time, have had good vetting behind them.
However, because there were no standards, that led to a race to the
bottom, where some CAs tried to cut corners and costs, knowing that
their certs would still turn on the padlock. This devalued the padlock -
and it remains devalued today.
We could rehabilitate the padlock by examining carefully the issuing
practices of all existing CAs, throwing them into two buckets marked
"good enough" and "not good enough", and not displaying the padlock for
the second lot. This would a) be a great deal of work, if it were even
possible to get access to each CA's proprietary processes, and b) break
half the SSL web when we threw out some of the root certificates.
Alternatively, we could start again with a new UI indicator, this one
actually backed by an objective standard and a minimum level of vetting.
Which is the idea behind EV.
> Surely we should support them, just like we do normal certificates, but
> I don't see why we should present them any differently in the UI.
Because they would then be differentiated from existing certificates
which don't provide the sort of protection etc. etc.
Gerv
Robert Sayre
>
> Certificates may, at one time, have had good vetting behind them.
> However, because there were no standards, that led to a race to the
> bottom, where some CAs tried to cut corners and costs, knowing that
> their certs would still turn on the padlock.
I don't see a financial incentive to prevent that from happening again.
Is there one?
>
> Because they would then be differentiated from existing certificates
> which don't provide the sort of protection etc. etc.
>
My understanding is that they don't provide additional protection from a
technical perspective. They only indicate a different social procedure.
We should be skeptical that they will work as planned, since there is no
track record of success. If there are problems, all we've done is add
green to the list of meaningless colors.
-Rob
Eddy Nigg (StartCom Ltd.)
Gervase Markham wrote:
> Alternatively, we could start again with a new UI indicator, this one
> actually backed by an objective standard and a minimum level of
> vetting. Which is the idea behind EV.
>
May I suggest an idea / proposal for a real improvement for the UI in
conjunction with SSL certification, which perhaps will help the casual
user best:
It is very common in the CA industry to mark digital certificates in
some form in order to differentiate between various verification
procedures. This is usually done by adding some text to the O or OU
field in the subject line of a certificate. CA's do the marking
voluntarily, because of the lack of a different display mode in
software, except the binary padlock.
At the low end we have "Domain Validated" certificates and at the high
end will be the proposed EV certificates. Both of them have a place in
the SSL landscape, specially if used for the correct purposes. But there
is also a range in between, which seems to be thrown together with the
lower end. My suggestion would be to define a standard for marking, such
as the OID for policies, which would allow the CA to mark certificates
accordingly. Guidelines for correct marking could be defined (EV is
being defined already by the proposed standard).
1.) White address / tool bar and padlock ON for Domain / Email validated
only (Class 1).
2.) Yellow address / tool bar and padlock ON for Identity / Business
validated (Class 2 & 3).
3.) Green address / tool bar and padlock ON for EV certificates (Class 4).
4.) Self signed, temporarily accepted or unknown issuer even a
different color??
Of course there are certain problems with this, such as adherence by the
CA's to correct marking. Obviously EV certificates must be treated
differently (authorized list etc), but there might be ideas and
solutions to this issue. The user however will gain the most, since he
can understand in an easier way, what type of certificate the site uses.
Casual users sometimes don't know how to look at a SSL secured web site
or its certification details, but with an easy color scheme (and some
explanation by hovering over the padlock) could give a good indication.
Issuing CA's will have it easier to mark their different certificate
levels and most likely support it. Other browser vendors might follow as
well. It could be worth the effort which needs to be put into this
proposal...
A second proposal would be, to display the most important certificate
details (subject line and issuer) by hovering over the pad lock (in the
address bar and status bar). This would display the user with most
information without being technically skilled to double click on the
padlock -> Select Security Tab -> Click View -> etc, etc. As mentioned
already, text within the subject line, such as O and OU would be
displayed and show the various, sometimes important details.
Boris Zbarsky
>> Will we see Extended Extended Validation Certificates in a few years,
>> after CAs sell too many EV certs? Is there an incentive for them not
>> to do that?
>
> What do you mean by "too many" EV certs? Do you mean "if they start
> selling EV certs to the wrong people"?
No, he means "once all the reputable businesses have EV certs, it'll be to the
CA's financial advantage to introduce a new 'even more trustworthy' type of cert
(call it EEV), so they can sell all those businesses EEV certs too".
-Boris
Ka-Ping Yee
> It is very common in the CA industry to mark digital certificates in
> some form in order to differentiate between various verification
> procedures. This is usually done by adding some text to the O or OU
> field in the subject line of a certificate. CA's do the marking
> voluntarily, because of the lack of a different display mode in
> software, except the binary padlock.
How is the user to distinguish when the displayed name is correct?
This is a crucial question. Right now we have the problem that the
certificate-verified information (the domain name) is chosen by the
attacker, and can be chosen to confuse users. A name like
"bankofthevvest.com" is confusingly similar to "bankofthewest.com",
and a name like "amazon.tv" collides with "amazon.com" unless you
are aware of that they belong to different namespaces. This is a
common and effective attack tactic.
So how can EV certificates and EV certificate UIs avoid confusing
users with displayed names that are similar, or the same but
registered in different jurisdictions?
-- ?!ng
L. David Baron
> The guidelines have been developed via a very long and drawn-out
> process, including several face-to-face meetings with competing
> specifications from different groups of CAs over the past two years.
> Eventually and quite recently, a Microsoft employee synthesised a
> unified specification, which has now been made available for public
> comment. The latest draft of this document can be found here:
> http://www.cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
After skimming some parts of the draft, my biggest concern here is
the tension between B.2.a.1 and B.2.c.3, and its implications on
when certificates would be revoked.
In particular, I think misrepresentation of identity within a Web
site that uses an EV cert must be grounds for revocation. B.2.a.1
says that one of the primary purposes of a cert is to identify the
legal entity behind a Web site. But I don't think the average
consumer knows the exact name of the legal entity running every
business they interact with.
For example, suppose a company is formed called "Washington Banking,
Inc.", and they apply for and obtain an EV cert under that name.
They then write a Web site that uses the name and logo of Washington
Mutual as part of a "phishing" attack. What percentage of consumers
would know that the legal entities behind the bank they know as
Washington Mutual are (based on the contents of
http://www.wamu.com/personal/default.asp ) "Washington Mutual Bank",
"Washington Mutual, Inc.", and other legal entities, but not
"Washington Banking, Inc"?
It seems that given that preventing such an attack is excluded from
the purposes of EV certificates and would not (I think, although I
didn't follow all the pointers leading out of the revocation part of
the spec) lead to revocation of the certificate. This seems like a
problem.
It seems like this spec overemphasizes the concept of "legal entity"
when the real problem here is misrepresentation of identity. So
shouldn't misrepresentation of identity, within any Web site served
using an EV cert, be grounds for revocation of that cert? In other
words, it seems to me that B.2.b.1 should be a primary purpose of EV
certificates, and B.2.a.1 should be secondary.
Also, what's the time scale of the average phishing attack? Are the
revocation guarantees in the spec (G.26.a) actually useful, or will
the attack be mostly over by the time anything is usefully revoked?
> The Mozilla project as a whole needs to decide whether EV will make a
> material difference to the reliability of information in certificates
> and, if so, whether that warrants a different UI presentation for EV
> certificates. It would also be good to have a more general discussion
> about how we present security information to users.
Presumably the idea here is that we would have a process for
determining that root CAs on our list are also valid EV root CAs,
and mark them as such? Would we need a policy for determining which
CAs should be so marked? I'd think we should have a clear policy
for this, and for when we would *un*-mark a CA. And I think we
should have that clearly defined before we start doing anything with
EV certificates, and make it clear in advance that if CAs do any of
the things that we said would make them be kicked out of our root CA
list, we'd actually do it.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Eddy Nigg (StartCom Ltd.)
> How is the user to distinguish when the displayed name is correct?
>
> This is a crucial question. Right now we have the problem that the
> certificate-verified information (the domain name) is chosen by the
> attacker, and can be chosen to confuse users. A name like
> "bankofthevvest.com" is confusingly similar to "bankofthewest.com",
> and a name like "amazon.tv" collides with "amazon.com" unless you
> are aware of that they belong to different namespaces. This is a
> common and effective attack tactic.
>
First of all, CA's should prevent the issuing of certificates in obvious
cases. Obviously identity/business validated certificates are most
likely less problematic, since the CA holds various data about the
subscriber, in addition to the displayed details within the certificate,
which could be used against him. But also FF2 provides an excellent
anti-pishing tool which helps to prevent such an attack.
However one must note, that most pishing sites don't even bother to
acquire digital certificates, but run their sites plain http. More than
that, most pishing sites don't have any similarity to the domain name
they are pishing.
> So how can EV certificates and EV certificate UIs avoid confusing
> users with displayed names that are similar, or the same but
> registered in different jurisdictions?
>
That's perhaps a question for the EV/Browser Forum... but since the
subscriber is supposed to get validated extensively, he would not dare
to try something like this. Also, EV certificates would and should not
be the common form of digital certification, therefore users might
recognize and pay attention to the different color. It might help a
user, if Paypal or eBay suddenly would loose it's green color (after the
user got used to see it for a while when visiting their sites). Other
type of confusion could happen however, if the entities are legitimate
businesses and validated as such...
Duane
> That's perhaps a question for the EV/Browser Forum... but since the
> subscriber is supposed to get validated extensively, he would not dare
> to try something like this.
This merely raises the cost of doing business for "the bad guys", it
doesn't prevent or deter things, since ID theft and ID fraud and plain
old fake ID documents are rampant, basing a strong system around a weak
one (ID documents) won't fix the problem, just cull the stupid.
Although as you pointed out, most phishing/fraud attacks don't even
bother with SSL certificates so this isn't going to prevent much until
the population can be educated (good luck with that) or shown how to
tell better (pet name tool bars etc) that something is up with the site
they are visiting.
Attacks, just like water, will always take the easiest path.
Eddy Nigg (StartCom Ltd.)
> This merely raises the cost of doing business for "the bad guys"
>
REQUIREMENTS, specially 16. Verification of Applicant’s Physical
Existence.....But as you said below....this is not the path pishers will
take...
> Attacks, just like water, will always take the easiest path.
>
--
Duane
> I guess the cost would be very high...read F. INFORMATION VERIFICATION
> REQUIREMENTS, specially 16. Verification of Applicant’s Physical
> Existence.....But as you said below....this is not the path pishers will
> take...
Again this isn't impossible, just raises the cost of doing business,
after all how do you think people have been committing cheque fraud over
the years when they steal mail from other peoples mail boxes?
Or the fact there is companies buying old printers from power companies
and other businesses for the purposes of reprinting "old account"
documents, for the purpose of ID fraud.
ID theft, and ID Fraud is rampant, none of these moves will stop a
determined attacker, it will only cull out the stupid.
Gervase Markham
> I don't see a financial incentive to prevent that from happening again.
> Is there one?
If the CAs don't pass the EV audit, then the browsers issue a security
update which stops that CA's certs triggering the EV UI. Whereupon all
their customers shout at them loudly, and decamp for other CAs.
>> Because they would then be differentiated from existing certificates
>> which don't provide the sort of protection etc. etc.
>
> My understanding is that they don't provide additional protection from a
> technical perspective. They only indicate a different social procedure.
Yes. What's your point? There's no need for additional technical
protection; SSL is a good and secure techology. Technical protections
are not what CAs do; their entire job is "social" (in your terms).
> We should be skeptical that they will work as planned, since there is no
> track record of success.
Neither is there for anything new. Read the draft. Do you see any reason
why it shouldn't work as planned?
Gerv
Gervase Markham
> So how can EV certificates and EV certificate UIs avoid confusing
> users with displayed names that are similar, or the same but
> registered in different jurisdictions?
Eddy's suggestion which prompted your question did not relate to EV.
However, I will answer the question anyway. The IE UI, at any rate,
shows the jurisdiction (country).
I would note in this connection that phishing is a crime (it's deception
and fraud). If someone gets an EV cert with misleading information in
(say they set up a real company called Bank Of The VVest) and use it for
phishing, then the information gathered as part of the EV process can be
used to track them down and convict them.
If they are spoofing the real Bank of the West, then their company has
to be US-based, otherwise the jurisdiction indicator will say something
else and the spoof will not be complete. And even if they aren't
US-based, it doesn't matter; local law enforcement can deal with them.
The point of EV is not that it's impossible for someone to get one and
commit fraud. The point is that if they do, you know enough about them
that you can arrest them and prosecute them. The guidelines have been
opened for review so people can see if they will result in a sufficient
level of validation that either a) the information is correct, or b) the
fraudster needs to spend a disproportionate amount of time, money and
effort faking, spoofing or subverting all of the different data sources
used - such that they won't bother.
We are seeking comments on whether they achieve this goal.
Gerv
Gervase Markham
> No, he means "once all the reputable businesses have EV certs, it'll be
> to the CA's financial advantage to introduce a new 'even more
> trustworthy' type of cert (call it EEV), so they can sell all those
> businesses EEV certs too".
The CAs can't provide a business case for that unless the browsers agree
to have yet another UI differentiator for these new EEV certs. And
that's pretty unlikely, given that we want to reduce UI complexity and
make security decisions easier. We'd have no motive to support EEV, even
if they went off and invented it.
Gerv
Gervase Markham
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> That's perhaps a question for the EV/Browser Forum... but since the
>> subscriber is supposed to get validated extensively, he would not dare
>> to try something like this.
>
> This merely raises the cost of doing business for "the bad guys", it
> doesn't prevent or deter things,
The second half of your sentence contradicts the first. If the cost of
doing business is raised, it will deter. The higher the raise, the
greater the deterrent.
> since ID theft and ID fraud and plain
> old fake ID documents are rampant, basing a strong system around a weak
> one (ID documents) won't fix the problem, just cull the stupid.
Have you actually read the draft? This is not a "fax in your letterhead"
system.
> Although as you pointed out, most phishing/fraud attacks don't even
> bother with SSL certificates so this isn't going to prevent much until
> the population can be educated (good luck with that) or shown how to
> tell better (pet name tool bars etc) that something is up with the site
> they are visiting.
Don't "pet name tool bars etc" require education to use also?
A potential advantage of EV if all the browsers adopt it is that
browsers, CAs, financial and other secure sites and consumer advocacy
groups can have a single, simple consistent message for users. This
makes it more likely that they'll actually pay attention.
Gerv
Gervase Markham
>
> Gervase Markham wrote:
>> Alternatively, we could start again with a new UI indicator, this one
>> actually backed by an objective standard and a minimum level of
>> vetting. Which is the idea behind EV.
>>
> May I suggest an idea / proposal for a real improvement for the UI in
> conjunction with SSL certification, which perhaps will help the casual
> user best:
This proposal has already been made in the context of the forum. (As a
CA, I would suggest you consider becoming a member and putting your
feedback in that way, rather than through this group.)
> At the low end we have "Domain Validated" certificates and at the high
> end will be the proposed EV certificates. Both of them have a place in
> the SSL landscape, specially if used for the correct purposes. But there
> is also a range in between, which seems to be thrown together with the
> lower end.
Absolutely - and quite right too. The vetting procedures which apply to
this middle ground are secret and proprietary, and have never been audited.
When we looked at the current problems 2 years ago, the browser makers
had a choice of trying to find out everyone's procedures and work out
which ones were "good" and which were "bad" (a Herculean task) or
defining a new, public, higher standard that CAs could choose to adhere
to or not. We chose the latter; no browser maker seems keen to revisit
that decision.
> 1.) White address / tool bar and padlock ON for Domain / Email validated
> only (Class 1).
> 2.) Yellow address / tool bar and padlock ON for Identity / Business
> validated (Class 2 & 3).
> 3.) Green address / tool bar and padlock ON for EV certificates (Class 4).
What benefit is there to users of having a more complex system such as
this? EV _is_ Identity/Business validated.
Gerv
Duane
> fraudster needs to spend a disproportionate amount of time, money and
> effort faking, spoofing or subverting all of the different data sources
> used - such that they won't bother.
No, you hope they won't do it, but given enough incentive to move away
from non-https sites, and domain validated sites, there is enough people
caught by these scams to more then make it worth their while.
You also indicated law enforcement agencies would hunt down and capture
these perpetrators, which is another false assumption as most of the
world has bigger problems then catching people stealing money from
westerners.
Robert Sayre
>
> Yes. What's your point? There's no need for additional technical
> protection; SSL is a good and secure techology. Technical protections
> are not what CAs do; their entire job is "social" (in your terms).
SSL is a good confidentiality technology. Most information submitted
over SSL is completely reusable once received by the server. I don't see
any benefit whatsoever for Mozilla users absent some concrete Mozilla
policies, as dbaron suggests. Without those, it's just security theater.
Even with them, I don't see why we should alter the UI immediately.
-Rob
Duane
> The second half of your sentence contradicts the first. If the cost of
> doing business is raised, it will deter. The higher the raise, the
> greater the deterrent.
There is no way you can raise the bar high enough to outweigh the scams
while still allowing existing businesses to be able to afford it as
well, and that is the crux of the issue, and why phone spam and other
social problems exist and will continue to exist until you can work out
a way to allow businesses to exist, but make it
> Have you actually read the draft? This is not a "fax in your letterhead"
> system.
*Sigh* as usual, missing the point, and just picking on one aspect of my
points...
> Don't "pet name tool bars etc" require education to use also?
The level of education is minimal as they take the approach to make
things intuitive that if you do X and Y occurs, there is a problem.
Compared to existing education programmes by banks and the like that if
X, Y, Z and some other factors exist, there may or may not be a problem.
> A potential advantage of EV if all the browsers adopt it is that
> browsers, CAs, financial and other secure sites and consumer advocacy
> groups can have a single, simple consistent message for users. This
> makes it more likely that they'll actually pay attention.
*yawn* ho hum, this won't do anything for security, it will do something
for Verisign's bank balance however, at least by those that buy into it,
and it could be a pretty big uphill battle of getting buy in from small
merchants and the like, although I'm sure they aren't Verisign's target
market with all this.
And yes I am picking on Verisign as they are the ones most vocal for this.
Ian and others were pushing for UI changes for years to add CA branding,
but of course he wasn't taken seriously... After all how do you really
punish a CA if the end users don't know who or what you are doing...
While you are pushing this particular variation of snake oil, and
claiming if someone sees ebay drop from green to yellow, all panic will
occur and a break down in society, it's been proven time and time again
that users click through dialog boxes and they won't care if goes pink
with purple polka dots.
Duane
>> 1.) White address / tool bar and padlock ON for Domain / Email validated
>> only (Class 1).
>> 2.) Yellow address / tool bar and padlock ON for Identity / Business
>> validated (Class 2 & 3).
>> 3.) Green address / tool bar and padlock ON for EV certificates (Class
>> 4).
>
> What benefit is there to users of having a more complex system such as
> this? EV _is_ Identity/Business validated.
EV would be at best Class 3, Class 4 would be extensive background
checks, not just providing ID documents and this potentially would have
some weight as it could provide a history on a person but *ONLY* if they
have been caught and prosecuted, but would give more scope then ID
documents do.
By background checks I'm leaning more toward criminal then civial credit
checks, credit checks don't prove much in this respect as even honest
people can have bad credit through mis-management etc, and learn from it
next time, criminal checks that show a history of fraud and deception on
the other hand is a different matter.
Although this would really be no deterrent either, as people that have
been bankrupt in the past simply hide behind a family member that does
have good credit etc, until any statutes of limitations kick in...
Eddy Nigg (StartCom Ltd.)
> Absolutely - and quite right too. The vetting procedures which apply
> to this middle ground are secret and proprietary, and have never been
> audited.
and practices are no secrets and published in most cases. Most
procedures are defined and disclosed publicly the same way the EV draft
is now on show. The relevant CA's were also audited in that respect.
>> 1.) White address / tool bar and padlock ON for Domain / Email validated
>> only (Class 1).
>> 2.) Yellow address / tool bar and padlock ON for Identity / Business
>> validated (Class 2 & 3).
>> 3.) Green address / tool bar and padlock ON for EV certificates
>> (Class 4).
>
> What benefit is there to users of having a more complex system such as
> this? EV _is_ Identity/Business validated.
problem. This is the high end of digital certification and I assume also
an expensive one. The majority of businesses will most likely refrain
from EV certification for various reasons. This doesn't mean, that
properly and reasonable verified entities and the associated
certificates are on the same level as for example "domain validated".
If a user must make a decision, if to trust a certain web site operator,
it will help him, if he can easily get an indication about what type of
verification the entity has undergone. And since a change of the
behavior of the UI is discussed right now, I think, we might go one step
further and produce something better. I agree, that this requires an
additional effort, but so did the Anti-pishing tool and many other
things currently featured...our proposal isn't such a huge investment
really (my assumption). At last, I highly suggest to introduce a more
extensive mouse-over popup than "Authenticated by...".
Eddy Nigg (StartCom Ltd.)
> Eddy's suggestion which prompted your question did not relate to EV.
> However, I will answer the question anyway. The IE UI, at any rate,
> shows the jurisdiction (country).
> We are seeking comments on whether they achieve this goal.
/"Ideally, I would be able to give any feedback to
the editor before November 19th, after which there may be another vote
on adopting the updated specification."
/
We did request clarification and suggested changes in our first post
about certain issues, which will be hopefully included in your feedback
to the editor.
/"The Mozilla project as a whole needs to decide whether EV will make a
material difference to the reliability of information in certificates
and, if so, whether that warrants a different UI presentation for EV
certificates. It would also be good to have a more general discussion
about how we present security information to users."
/
Also here we made concrete suggestions about how to present security
information to the user in a better way. If the proposed change of the
UI behavior only satisfies the EV standard, which was developed in a
closed process (or can you point me to an open invitation or mailing
list, where the proposed standard could be influenced, shaped and
discussed?), than we'd suggest to keep the current status quo in
addition to an extended mouse-over-padlock in order to display
subscriber and issuer information better and faster.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
Eddy Nigg <http://www.startcom.org> <eddy...@startcom.org
<mailto:eddy...@startcom.org>>
StartCom Ltd. - StartCom CA - MediaHost (TM)
Gervase Markham
> Gervase Markham wrote:
>
>>> 1.) White address / tool bar and padlock ON for Domain / Email validated
>>> only (Class 1).
>>> 2.) Yellow address / tool bar and padlock ON for Identity / Business
>>> validated (Class 2 & 3).
>>> 3.) Green address / tool bar and padlock ON for EV certificates (Class
>>> 4).
>> What benefit is there to users of having a more complex system such as
>> this? EV _is_ Identity/Business validated.
>
> EV would be at best Class 3, Class 4 would be extensive background
> checks,
You've missed my point. My question is: "why do we need to expose more
than two levels of validation (EV and everything else) to the user?". I
understand the CA industry recognises more, although the precise
boundaries between classes are not defined. However, IMO there's no
point in exposing that.
Gerv
Gervase Markham
>> Absolutely - and quite right too. The vetting procedures which apply
>> to this middle ground are secret and proprietary, and have never been
>> audited.
> Well, I'm not sure if this a correct statement. Obviously CA policies
> and practices are no secrets and published in most cases. Most
> procedures are defined and disclosed publicly the same way the EV draft
> is now on show. The relevant CA's were also audited in that respect.
They were audited (if they had a WebTrust audit) to see how closely they
followed their procedures. No assessment was made as to the rigour or
quality of those procedures.
> Personally I think the proposed EV /UI changes solve only part of the
> problem. This is the high end of digital certification and I assume also
> an expensive one.
Why do you assume so? Has your CA done an assessment of what it might
cost for you to issue certificates to an EV level of validation?
> The majority of businesses will most likely refrain
> from EV certification for various reasons.
Can you be more specific than "various reasons", and explain the
reasoning behind your "most likely"?
> If a user must make a decision, if to trust a certain web site operator,
> it will help him, if he can easily get an indication about what type of
> verification the entity has undergone.
Indeed. And I submit that the user has two possible states in mind:
"enough" and "not enough".
> And since a change of the
> behavior of the UI is discussed right now, I think, we might go one step
> further and produce something better. I agree, that this requires an
> additional effort, but so did the Anti-pishing tool and many other
> things currently featured...our proposal isn't such a huge investment
> really (my assumption).
I am not arguing against your proposal on the grounds that it would be
additional effort.
> At last, I highly suggest to introduce a more
> extensive mouse-over popup than "Authenticated by...".
That may well be worth doing, but I don't see it as core to this
particular discussion.
Gerv
Gervase Markham
> Gervase Markham wrote:
>
>> fraudster needs to spend a disproportionate amount of time, money and
>> effort faking, spoofing or subverting all of the different data sources
>> used - such that they won't bother.
>
> No, you hope they won't do it, but given enough incentive to move away
> from non-https sites, and domain validated sites, there is enough people
> caught by these scams to more then make it worth their while.
Let's say that the EV guidelines required the person purchasing the
certificate to travel, at their own expense, to a facility in downtown
Boise, Idaho. There, they would be photographed (naked) from front and
back, fingerprinted, DNA-sampled and have their passport number taken.
All this information would then be made public as part of the certificate.
If that were the case, I suggest that no fraudster would ever attempt to
get an EV certificate. However, we probably wouldn't sell all that many
of them either.
Hence, we have to try and find a sweet spot where the amount of
validation required is do-able for a sensible price, and is not too
inconvenient for a genuine applicant, and yet is disproportionately hard
to spoof for a fraudster. Things like site visits are particularly hard
to spoof, and yet easy for a genuine company to submit to.
You are asserting, without proof, that no such sweet spot exists. I am
suggesting that the current EV guidelines are round about the right
place. I invite your comments as to why that might not be the case. You
might, for example, postulate a scenario where a fraudster could fake
out all of the required steps for a cost of, say, under $20,000, without
revealing very much information about himself. If you can do that, we
would certainly look at the loopholes you've found and try to close them
by strengthening the checks.
> You also indicated law enforcement agencies would hunt down and capture
> these perpetrators, which is another false assumption as most of the
> world has bigger problems then catching people stealing money from
> westerners.
Possibly so; but no system can make it safe to do business with a
website in a country which does not prosecute criminals. The only
solution is not to do business with sites based in that country. Hence
the country indicator.
Gerv
Gervase Markham
> There is no way you can raise the bar high enough to outweigh the scams
> while still allowing existing businesses to be able to afford it as
> well, and that is the crux of the issue,
You are asserting that this is so, but without engaging with the actual
steps laid out in the draft. How can a scammer get around what we have
suggested, for a cost commensurate with the return from a single
phishing expedition?
>> Don't "pet name tool bars etc" require education to use also?
>
> The level of education is minimal
So is "look for the green bar".
> Ian and others were pushing for UI changes for years to add CA branding,
> but of course he wasn't taken seriously... After all how do you really
> punish a CA if the end users don't know who or what you are doing...
I've refuted the arguments for CA branding at length in various forums;
it wouldn't be useful for me to repeat myself here.
> While you are pushing this particular variation of snake oil, and
> claiming if someone sees ebay drop from green to yellow, all panic will
> occur and a break down in society,
You weaken your own argument by setting up straw men.
Gerv
Gervase Markham
>> Eddy's suggestion which prompted your question did not relate to EV.
>> However, I will answer the question anyway. The IE UI, at any rate,
>> shows the jurisdiction (country).
> IE UI?
The User Interface in Internet Explorer 7.
> /"Ideally, I would be able to give any feedback to
> the editor before November 19th, after which there may be another vote
> on adopting the updated specification."
> /
> We did request clarification and suggested changes in our first post
> about certain issues, which will be hopefully included in your feedback
> to the editor.
Yes, indeed. Thank you for those.
Gerv
Gervase Markham
> Gervase Markham wrote:
>>
>> Yes. What's your point? There's no need for additional technical
>> protection; SSL is a good and secure techology. Technical protections
>> are not what CAs do; their entire job is "social" (in your terms).
>
> SSL is a good confidentiality technology. Most information submitted
> over SSL is completely reusable once received by the server.
I don't understand what you mean by "reusable" in this context.
> I don't see
> any benefit whatsoever for Mozilla users absent some concrete Mozilla
> policies, as dbaron suggests. Without those, it's just security theater.
The point of EV is that the browsers no longer have to play "CA Cop"; we
can outsource the auditing of CAs to a competent third party, who will
say whether their procedures meet the EV standard. Then, unless we have
evidence to the contrary, we can enable them for EV.
So, I would expect our policy to be that the list of EV-capable CAs in
Mozilla would be the same as the list of CAs who have passed the EV
audit. (We would, of course, retain the ability to change that status
for any CA if we thought it necessary.)
Gerv
Gervase Markham
> form would be indeed interesting.
That is currently being worked on, as I understand it.
> 2.) Under section C. 4. (a) Compliance:
>
> It is not fully clear to us, how approval by the CA/Browser Forum is
> preformed and how equivalent of the WebTrust programs are defined. In J.
> (a) 1) it says "/or a currently valid unqualified opinion indicating
> compliance with equivalent audit procedures approved by the CA/Browser
> Forum/", but this unqualified opinion is nowhere defined?
This is shorthand; it means "the opinion of an auditor qualified to
perform WebTrust audits". I will get that clarified.
> Also
> membership at the CA/Browser forum is currently an exclusive club of
> CA's,
...and open to any CA which has roots in major browsers and issues
certificates to the public.
> but we'd like to know if issuance of EV certificates is a
> requirement for membership or can there be membership without actively
> issuing EV certificates?
You do not have to issue EV certs to be a member. EV is not the only
issue the CA/Browser forum plans to tackle.
> It is regrettable, that there is explicitly
> the mentioning of "WebTrust" instead of "a neutral and competent 3rd
> party" or allow for alternatives such as ETSI. This monopoly isn't
> really healthy and doesn't reflect the Mozilla CA policy!
It does allow for alternatives; it says "or an equivalent for both (i)
and (ii) as approved by the CA/Browser Forum;". We can't just say "a
competent 3rd party"; that just begs the question as to who would define
"competent"?
If you would like particular alternatives explicitly named, we may be
able to do that. Please let me know exactly what.
> Additionally
> we'd suggest to make sure, that CA's approved and included by a minimum
> of one or two software vendor's software will be able to issue EV
> certificates (according to the guidelines) and accepted as such by the
> relevant software vendors - including the listing of the CA in CA/BF,
> even if a CA is not present in some of the (other) software vendors.
I don't quite understand your point here. But nothing in the guidelines
affects each browser maker's independent ability to decide which certs
and CAs it accepts or recognises.
> 3.) Under section C. 4. (c) Insurance:
>
> The draft mentions two different insurances with 2 million, resp
> 5 million US$ coverage. However it doesn't say, if this insurances are
> for all the CA business or only for the EV certificates.
4) c) 1) says "related to their respective performance and obligations
under these Guidelines"; so it's just for EV.
> 4.) Also not clear is, how the software vendor "knows" about, if a
> certificate is EV. We understand, that CA roots and Intermediate CA
> signer certificates can be marked as EV issuers, however Intermediate CA
> lifespan is usually lower than the root certificate of the CA, in our
> case valid for 5 years. Does software vendors have to manage a list of
> CA signer certificates which are EV issuers? How does Mozilla intend to
> handle/manage that?
EV certs will have a new policy OID to differentiate them from other
certs. I am not certain of the technical details; it's not my area. Of
course, any browser maker may override this for a particular CA if they
feel that CA does not, in fact, meet EV guidelines (for example, if they
fail an audit).
> Obviously a very small number of businesses will
> acquire EV certificates,
Why is this obvious?
> but somehow discriminates other properly
> verified and serious certificates issued, making them "less" valued,
> which we think is wrong! When the idea was first published, we expected,
> that certificates would be more divided into categories, such as Class 1
> - 4, or in other words:
>
> 1) Domain validated only,
> 2) Reasonable verification of the identity/business,
So is "reasonable" verification good enough for a user to hand over
their credit card details? If so, what's the point of level 3? If not,
what's the point of level 2?
> 3) Thorough verification if identity/verification,
> 4) Government authorized or issued, or similar to EV,
> reflecting the status by different colors. This would give the user more
> indications about the status of the certificate without being a PKI
> expert.
Except that they would have no clear guidance about what actions they
should take based on those colours. Should they, for example, only buy
from a merchant with a Level 2 certificate if they are feeling
particularly lucky that day?
Gerv
Gervase Markham
> On Wednesday 2006-11-01 22:54 +0000, Gervase Markham wrote:
>> The guidelines have been developed via a very long and drawn-out
>> process, including several face-to-face meetings with competing
>> specifications from different groups of CAs over the past two years.
>> Eventually and quite recently, a Microsoft employee synthesised a
>> unified specification, which has now been made available for public
>> comment. The latest draft of this document can be found here:
>> http://www.cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
>
> After skimming some parts of the draft, my biggest concern here is
> the tension between B.2.a.1 and B.2.c.3, and its implications on
> when certificates would be revoked.
>
> In particular, I think misrepresentation of identity within a Web
> site that uses an EV cert must be grounds for revocation.
I agree; does any part of the draft say otherwise?
> For example, suppose a company is formed called "Washington Banking,
> Inc.", and they apply for and obtain an EV cert under that name.
> They then write a Web site that uses the name and logo of Washington
> Mutual as part of a "phishing" attack. What percentage of consumers
> would know that the legal entities behind the bank they know as
> Washington Mutual are (based on the contents of
> http://www.wamu.com/personal/default.asp ) "Washington Mutual Bank",
> "Washington Mutual, Inc.", and other legal entities, but not
> "Washington Banking, Inc"?
Not many, I agree. However, in order to correctly spoof WAMU (at least
in the IE 7 UI) they would need to incorporate their fake company in the
US. And, if they did that, the information gathered during the EV
process could be used to track the applicant down and prosecute them.
> It seems like this spec overemphasizes the concept of "legal entity"
> when the real problem here is misrepresentation of identity. So
> shouldn't misrepresentation of identity, within any Web site served
> using an EV cert, be grounds for revocation of that cert? In other
> words, it seems to me that B.2.b.1 should be a primary purpose of EV
> certificates, and B.2.a.1 should be secondary.
>
>
> Also, what's the time scale of the average phishing attack? Are the
> revocation guarantees in the spec (G.26.a) actually useful, or will
> the attack be mostly over by the time anything is usefully revoked?
This was a matter much debated. G.26.a gives minimums; I would hope that
CAs would do substantially better in practice.
>> The Mozilla project as a whole needs to decide whether EV will make a
>> material difference to the reliability of information in certificates
>> and, if so, whether that warrants a different UI presentation for EV
>> certificates. It would also be good to have a more general discussion
>> about how we present security information to users.
>
> Presumably the idea here is that we would have a process for
> determining that root CAs on our list are also valid EV root CAs,
> and mark them as such?
The idea would be that, as an initial position, we would list all those
CAs which have passed an EV audit as valid. We would then track that,
diverging only when we had information that a particular CA was not
meeting its EV obligations between audits.
> Would we need a policy for determining which
> CAs should be so marked? I'd think we should have a clear policy
> for this, and for when we would *un*-mark a CA. And I think we
> should have that clearly defined before we start doing anything with
> EV certificates, and make it clear in advance that if CAs do any of
> the things that we said would make them be kicked out of our root CA
> list, we'd actually do it.
I would anticipate that the primary sanction would be removal of EV
status, rather than being completely kicked out of the root list. This
latter, nuclear, option has been theoretically available to us for
existing CAs under the current system, but we have never contemplated
using it - because removing e.g. Verisign would break half the SSL sites
on the web.
One of the advantages of EV is that it provides us with a meaningful yet
less nuclear sanction whereby the CA is the one that gets in hot water -
because their customers who forked out for EV certificates start
shouting at them because they are no longer displayed as EV in Firefox,
and their Firefox-using customers are ringing them up to ask why, and
whether they should carry on trusting their site.
Gerv
me...@comodogroup.com
Hi Everyone
My name is Melih, i am the CEO/Chief Security Architect of Comodo (guys
who give Verisign run for their money :))
I don't want to intrude as you all are doing an excellent job in asking
the right questions to Gerv :-)
However, there might be questions that you may want to ask directly to
a Certification Authority.
So pls feel free to ask any questions on the subject so that I can shed
light from Certification Authority point of view...
Melih
Eddy Nigg (StartCom Ltd.)
I try to summarize my response to your multiple replies, in order focus
on the important issues.
Gervase Markham wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>> Gervase Markham wrote:
>>> Eddy's suggestion which prompted your question did not relate to EV.
>>> However, I will answer the question anyway. The IE UI, at any rate,
>>> shows the jurisdiction (country).
>> IE UI?
>
> The User Interface in Internet Explorer 7.
What has the IE7 UI to do with Mozilla (Firefox)? We are interested in
how the Firefox UI is going to look and behave!
>> EV would be at best Class 3, Class 4 would be extensive background
>> checks,
> <snip>
>
> You've missed my point. My question is: "why do we need to expose more
> than two levels of validation (EV and everything else) to the user?".
> I understand the CA industry recognises more, although the precise
> boundaries between classes are not defined. However, IMO there's no
> point in exposing that.
As you agree, that the CA industry recognizes more than just one or two
levels and the subscriber is making a decision on one of these levels,
the relying party must know, what these levels are. Our proposal is, to
give to the user (relying part) a better way to judge that.
As you and others pointed out, there is nothing 100 %, not even in the
proposed EV certification. But what's important here is, that the user
knows the type of verification performed and make a decision if he/she
can risk / trust the information / amount or whatever is required to
share with the site operator. For example a user may find it sufficient
to risk a purchase of a small amount of money if the subscriber is
reasonable verified. But the same user would only risk a bigger amount
if the subscriber would have been thorough verified (EV). As domain
validated certificates should only be used for password login protection
and not for sharing critical personal information or money transfer,
today and in the future, the user will have no clue how to know about
it. Therefore our suggestion to improve this!
>
> The point of EV is that the browsers no longer have to play "CA Cop";
> we can outsource the auditing of CAs to a competent third party, who
> will say whether their procedures meet the EV standard. Then, unless
> we have evidence to the contrary, we can enable them for EV.
>
> So, I would expect our policy to be that the list of EV-capable CAs in
> Mozilla would be the same as the list of CAs who have passed the EV
> audit. (We would, of course, retain the ability to change that status
> for any CA if we thought it necessary.)
EV means Extended Validation! There might be CA's which will not issue
EV certificates, nevertheless they perform valuable verifications.
Obviously we can't support changing the Mozilla CA policy, if this
means, that only EV enabled CA's will be supported by Mozilla!
There are various other valid standards for CA's and nothing, but
nothing will change the role of the browser vendor in this respect. EV
is just another standard! Auditing was always a job of a third party and
I don't see anywhere in the current CA policy, that Mozilla is supposed
to do the auditing. Nothing will change in that respect!
> I would anticipate that the primary sanction would be removal of EV
> status, rather than being completely kicked out of the root list. This
> latter, nuclear, option has been theoretically available to us for
> existing CAs under the current system, but we have never contemplated
> using it - because removing e.g. Verisign would break half the SSL
> sites on the web.
Which would give Verisign or other similar CA's (all of them owned by
Verisign anyway) a license to do whatever they like! Your statement
above is extremely dangerous! Because you just said, that you are
willing to compromise half of the SSL enabled sites of the Internet,
because of their market share!?!?!
Robert Sayre
>
> The point of EV is
I understand what the goals are. I don't share them. I think telling our
users that EV cites are "more secure" is a mistake.
> So, I would expect our policy to be
I thought you were asking what our policy should be. Isn't that the
point of this thread?
- Rob
Eddy Nigg (StartCom Ltd.)
> They were audited (if they had a WebTrust audit) to see how closely
> they followed their procedures. No assessment was made as to the
> rigour or quality of those procedures.
procedures and controls in place. The policy and practices of the CA are
the basis of this assessment, which is publicly available! Therefor they
are not secret and proprietary, which was your original wrong statement!
And yes, the policy and practices define the quality of those procedures!
>> Personally I think the proposed EV /UI changes solve only part of the
>> problem. This is the high end of digital certification and I assume also
>> an expensive one.
>
> Why do you assume so? Has your CA done an assessment of what it might
> cost for you to issue certificates to an EV level of validation?
suggest high costs for the CA and therefore for the subscriber.
>> The majority of businesses will most likely refrain
>> from EV certification for various reasons.
>
> Can you be more specific than "various reasons", and explain the
> reasoning behind your "most likely"?
satisfy the requirements of the EV standard in addition to the most
likely high costs entailed with the extensive checking!
>> If a user must make a decision, if to trust a certain web site operator,
>> it will help him, if he can easily get an indication about what type of
>> verification the entity has undergone.
>
> Indeed. And I submit that the user has two possible states in mind:
> "enough" and "not enough".
something general, whereas enough for A, might be not enough for
performing B and otherwise. We suggest to give an indication HOW
rigorous a subscriber was verified. According to this indications a
relying party can make a proper decision if to proceed.
>> And since a change of the
>> behavior of the UI is discussed right now, I think, we might go one step
>> further and produce something better. I agree, that this requires an
>> additional effort, but so did the Anti-pishing tool and many other
>> things currently featured...our proposal isn't such a huge investment
>> really (my assumption).
>
> I am not arguing against your proposal on the grounds that it would be
> additional effort.
to give the most and best information to the user, about how a digital
certificate was processed. Your suggestion of enough or not enough is
just the padlock in another form! Not much is gained here...You might
just leave it as is!
>> At last, I highly suggest to introduce a more
>> extensive mouse-over popup than "Authenticated by...".
> That may well be worth doing, but I don't see it as core to this
> particular discussion.
as details about the subscriber, issuer and additional notes of the CA.
Displaying this information might help to prevent user mistakes and
provide indication about the certificates policy etc.
Eddy Nigg (StartCom Ltd.)
> I understand what the goals are. I don't share them. I think telling
> our users that EV cites are "more secure" is a mistake.
better judgment!
>
>> So, I would expect our policy to be
>
> I thought you were asking what our policy should be. Isn't that the
> point of this thread?
digital certificates!
L. David Baron
> L. David Baron wrote:
> >On Wednesday 2006-11-01 22:54 +0000, Gervase Markham wrote:
> >>The guidelines have been developed via a very long and drawn-out
> >>process, including several face-to-face meetings with competing
> >>specifications from different groups of CAs over the past two years.
> >>Eventually and quite recently, a Microsoft employee synthesised a
> >>unified specification, which has now been made available for public
> >>comment. The latest draft of this document can be found here:
> >>http://www.cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
> >
> >After skimming some parts of the draft, my biggest concern here is
> >the tension between B.2.a.1 and B.2.c.3, and its implications on
> >when certificates would be revoked.
> >
> >In particular, I think misrepresentation of identity within a Web
> >site that uses an EV cert must be grounds for revocation.
>
> I agree; does any part of the draft say otherwise?
First, that's the wrong question to ask, since unless the draft
explicitly says that it *should* be revoked, a CA is unlikely to do
so for fear of being sued or otherwise accused of violation of
contract by the company they're selling the cert to. If you think
that certificates should be revoked on these grounds, then the
section on revocation should say so explicitly.
Second, yes, it does. B.2.c says explicitly that: "an EV
certificate is *not* intended to provide any assurances, or
otherwise represent or warrant: (1) [...] (2) That the Subject named
in the EV Certificate complies with applicable laws; (3) That the
Subject named in the EV certificate is trustworthy, honest, or
reputable in its business dealings [...]"
> Not many, I agree. However, in order to correctly spoof WAMU (at least
> in the IE 7 UI) they would need to incorporate their fake company in the
> US. And, if they did that, the information gathered during the EV
> process could be used to track the applicant down and prosecute them.
I'm skeptical of whether law enforcement authorities care, or
whether victims of phishing care enough to yell at law enforcement
enough so that they care. The last time I tried to interest law
enforcement with investigating computer crime, they didn't. Then
again, that was about 10 years ago.
Criminal prosecution is a very expensive and complex process, and
only works as a disincentive if a high enough percentage of
criminals are prosecuted and convicted. Having simpler incentives
against crime (such as making the crime harder to commit or less
profitable) is vastly preferable when possible.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Gervase Markham
> I understand what the goals are. I don't share them. I think telling our
> users that EV cites are "more secure" is a mistake.
Presumably because you don't believe the additional vetting presents a
higher barrier to fraudsters? If so, could you elaborate on why it doesn't?
>> So, I would expect our policy to be
>
> I thought you were asking what our policy should be. Isn't that the
> point of this thread?
I had (perhaps erroneously) assumed that, were we to decide to support
EV, we would support it for those CAs and only those CAs who had passed
an EV audit. This stops us being in the impossible position of having to
manually audit every CA ourselves - which is one thing EV is trying to
avoid, compared to the current situation.
We could allow EV for all CAs, whether or not they had passed the audit
- however, that would negate any security benefits that EV had, and lull
our customers into a false sense of security.
Alternatively, we could allow EV for a subset of the audited CAs - which
is a possibility I mentioned might happen in exceptional circumstances -
but on what grounds (other than obvious disregard for the guidelines)
would we exclude CA A and include CA B?
However, perhaps I have missed something. If your position is that we
should support EV, but for a different set of CAs than the ones which
have passed the audit, please set out how you would decide which CAs we
should support.
Gerv
Robert Sayre
> Robert Sayre wrote:
>> I understand what the goals are. I don't share them. I think telling
>> our users that EV cites are "more secure" is a mistake.
>
> Presumably because you don't believe the additional vetting presents a
> higher barrier to fraudsters? If so, could you elaborate on why it doesn't?
>
I believe it presents a higher barrier. Since there is no technical
advantage to EV, I am not sure that will matter, once ways of
manipulating the EV system are discovered by criminals (does anyone
think they won't figure something out?). I don't think Mozilla should
jump in right away. This is unpleasant, because it would then appear
that IE has a "feature" we lack. So, I understand the desire to go ahead.
...
> Alternatively, we could allow EV for a subset of the audited CAs - which
> is a possibility I mentioned might happen in exceptional circumstances -
> but on what grounds (other than obvious disregard for the guidelines)
> would we exclude CA A and include CA B?
We will probably arrive at this state if we are at all serious. We need
to have a clear definition of "obvious disregard" and the consequences,
so the event doesn't become a negotiation.
- Rob
Eddy Nigg (StartCom Ltd.)
Thanks for this useful answers and clarifications. Most of it answered
our questions! Below some additional answers so...
>
> ...and open to any CA which has roots in major browsers and issues
> certificates to the public.
> You do not have to issue EV certs to be a member. EV is not the only
> issue the CA/Browser forum plans to tackle.
The StartCom CA has applied for membership. Thanks for your help on this...
>
>> It is regrettable, that there is explicitly
>> the mentioning of "WebTrust" instead of "a neutral and competent 3rd
>> party" or allow for alternatives such as ETSI. This monopoly isn't
>> really healthy and doesn't reflect the Mozilla CA policy!
>
> It does allow for alternatives; it says "or an equivalent for both (i)
> and (ii) as approved by the CA/Browser Forum;". We can't just say "a
> competent 3rd party"; that just begs the question as to who would
> define "competent"?
Who decides what equivalent means? Alternatives is a good thing as it
provides additional appropriate options and doesn't leave the whole
issue in the hands of ONE body. Personally I see various dangers, if
this would be the case! I suggest, that Mozilla stands for these
alternatives as its own CA policy defines and suggests! This is a very
important point in our view! Please make sure, that this actually happens!
>
> If you would like particular alternatives explicitly named, we may be
> able to do that. Please let me know exactly what.
For example Mozillas own CA policy would be a good start.
>
> 4) c) 1) says "related to their respective performance and obligations
> under these Guidelines"; so it's just for EV.
May I suggest to make that perhaps in relation to a ratio of issued
certificates, something like from 0-1000 issued certificates X
insurance, from 1001 - ....and so on...
>
>> Obviously a very small number of businesses will
>> acquire EV certificates,
>
> Why is this obvious?
Overhead operational costs and requirements such as physical check of
the premise will make this type of certification certainly expensive, so
expensive is a relative term...Additionally many businesses will have
difficulties complying to every criteria.
>
> So is "reasonable" verification good enough for a user to hand over
> their credit card details? If so, what's the point of level 3? If not,
> what's the point of level 2?
It depends on the user and not on your personal opinion. It depends
which information the user is going to share with the site operator and
what is the behavior of the user generally perhaps. People share this or
other information every day with a cab driver, restaurant, on-line shop
and who not...For user A reasonable verification might be enough whereas
for user B it's not. What do you know about a cab driver somewhere? Our
position is, to give the user enough information in order to make a
personal judgment, not deciding for the user what is good for him and
what not!
>
> Except that they would have no clear guidance about what actions they
> should take based on those colours. Should they, for example, only buy
> from a merchant with a Level 2 certificate if they are feeling
> particularly lucky that day?
That's the users judgment! The CA and browser vendor should provide the
information about it (which today is currently lacking anyway)
Heikki Toivonen
>> They were audited (if they had a WebTrust audit) to see how closely
>> they followed their procedures. No assessment was made as to the
>> rigour or quality of those procedures.
> WebTrust or not, is not a function here! But an audit confirms the
> procedures and controls in place. The policy and practices of the CA are
> the basis of this assessment, which is publicly available! Therefor they
> are not secret and proprietary, which was your original wrong statement!
> And yes, the policy and practices define the quality of those procedures!
I am under the impression that the policies and practices are actually
not publicly available. Can you provide links that document these for
some common CAs, to the level described in the EV cert draft?
--
Heikki Toivonen
Eddy Nigg (StartCom Ltd.)
Next try the Authorities Certificate store of your Firefox browser
And at last, try uncle Google...
BTW, it is common to place the CA policy in a prominent place on the CA
web site, after all, this is part of the legal contract between the CA -
subscriber and relying party. In theory a user (RP) should read the CA
policy of the issuing CA before trusting a certificate, otherwise how
should he know about the verifications performed or any other procedure
a CA promises? Obviously, this is not very practical, hence our
proposal for a simplified but improved UI change!
Hope this answers your question...
Duane
> I believe it presents a higher barrier. Since there is no technical
> advantage to EV, I am not sure that will matter, once ways of
> manipulating the EV system are discovered by criminals (does anyone
> think they won't figure something out?). I don't think Mozilla should
> jump in right away. This is unpleasant, because it would then appear
> that IE has a "feature" we lack. So, I understand the desire to go ahead.
As usually I've come to the conclusion that mozilla reps are asking for
feedback, but don't really care for answers as their minds are either
made up, or just don't care.
Until numerous conditions have been met forcing all sites doing some
form of business into using EV certificates (and paying through the nose
for it), people will continue to use cheap certs to operate, and
phishing sites will continue not to use certs at all, and so what is
gained unless you not only have an approach for how to issue EV certs
compared to enforcing their use?
This is going to be another click through popup, everyone will associate
yellow v green, as most sites I going to be yellow long after whatever
is passed by the powers that be, so everyone might as well keep going
with the connection to this site because we've become numb with
conditioning that yellow is good and the padlock is still there which
I've always been told to look for.
This is where the scammers will win, because to get the majority across
you would have to have a low price point, and that isn't going to happen.
What's really sad here is instead of leading security mozilla are happy
to follow like sheeple, instead of embracing university researchers in
ways of making browsing safe, they are embracing and extending
Verisign's bank balance.
As some have pointed out on the anti-fraud list (Gerv is also on that
list), identity isn't a good thing to make strong because then it only
leads to identity fraud, and what he fails to grasp is the fact that no
matter how strong or good he thinks this system is others will still
find loop holes *if* they even feel it's necessary.
Heikki Toivonen
>> The User Interface in Internet Explorer 7.
> What has the IE7 UI to do with Mozilla (Firefox)? We are interested in
> how the Firefox UI is going to look and behave!
Browser manufacturers are cooperating (or in some cases copying) user
interface elements on purpose to make it easier to educate people. The
padlock is basically the same in most browsers. A pretty recent
development is also the RSS icon that IE copied from Firefox. Since IE
has the first(?) UI for EV certs, other browser manufacturers have some
incentive to follow their lead unless they can think of something
obviously better.
> As you agree, that the CA industry recognizes more than just one or two
> levels and the subscriber is making a decision on one of these levels,
> the relying party must know, what these levels are. Our proposal is, to
> give to the user (relying part) a better way to judge that.
>
> As you and others pointed out, there is nothing 100 %, not even in the
> proposed EV certification. But what's important here is, that the user
> knows the type of verification performed and make a decision if he/she
> can risk / trust the information / amount or whatever is required to
> share with the site operator. For example a user may find it sufficient
> to risk a purchase of a small amount of money if the subscriber is
> reasonable verified. But the same user would only risk a bigger amount
> if the subscriber would have been thorough verified (EV). As domain
> validated certificates should only be used for password login protection
> and not for sharing critical personal information or money transfer,
> today and in the future, the user will have no clue how to know about
> it. Therefore our suggestion to improve this!
Even though I consider myself security savvy, I'd rather not deal with
multiple levels in the browser myself.
SSL or not would have been great, but it's too late now. The next best
thing is no SSL (everyone can snoop you), unknown validation SSL
(password can't be snooped but beyond that it is hard to know anything
else), and EV (more informative UI, have high(er) hopes of actually
being able to sue somebody if something goes wrong).
> EV means Extended Validation! There might be CA's which will not issue
> EV certificates, nevertheless they perform valuable verifications.
> Obviously we can't support changing the Mozilla CA policy, if this
> means, that only EV enabled CA's will be supported by Mozilla!
I haven't heard anyone say Mozilla would stop supporting non-EV
certificates. I'd also consider EV certificates an overkill for a
discussion forum, for example, where you mainly want to protect your
login and password from snooping, so I certainly think there will still
be a market for non-EV certificates.
> There are various other valid standards for CA's and nothing, but
> nothing will change the role of the browser vendor in this respect. EV
> is just another standard! Auditing was always a job of a third party and
> I don't see anywhere in the current CA policy, that Mozilla is supposed
> to do the auditing. Nothing will change in that respect!
You say that like standards have no value, and are all just useless
pieces of paper.
Sure, from browser vendors point of view there is not much difference.
For EV certs you look for proof of different auditing process, and flip
a different bit when adding the cert. But it (hopefully) can make a
significant difference in the user experience.
>> I would anticipate that the primary sanction would be removal of EV
>> status, rather than being completely kicked out of the root list. This
>> latter, nuclear, option has been theoretically available to us for
>> existing CAs under the current system, but we have never contemplated
>> using it - because removing e.g. Verisign would break half the SSL
>> sites on the web.
> Which would give Verisign or other similar CA's (all of them owned by
> Verisign anyway) a license to do whatever they like! Your statement
> above is extremely dangerous! Because you just said, that you are
> willing to compromise half of the SSL enabled sites of the Internet,
> because of their market share!?!?!
Have there been cases where a CA has been consistently so bad that it
should have warranted removal?
--
Heikki Toivonen
Heikki Toivonen
Thanks for the link, I knew about it but forgot... I'll scan some of the
docs. My guess would be that some policies and practices documents do
not describe things as detailed as the EV draft does, thereby leaving me
with questions even after reading them.
It is not very practical to require a user to read those specs,
especially considering those policies can be written in any language.
I have to disagree with you on some of your UI choices though. I think
everything the user needs to make a decision about trusting a site needs
to be visible by default. Requiring the user to mouse over a control
gets tedious quickly even for people who know about it, and those that
don't know may never discover it.
Also, the more levels of trust/security there are, the more confusing it
is for the user - hence I am in the camp of advocating as few levels as
possible (I think we need 3 - no SSL, current SSL, EV).
I haven't yet read the EV draft fully to see how closely it matches my
expectations, but commentary from other people seems to indicate it is
reasonable (barring some bugs and clarifications). I believe it will
improve the situation. I know it won't be 100% foolproof, but then again
I don't think anything can be.
--
Heikki Toivonen
Eddy Nigg (StartCom Ltd.)
> Since IE
> has the first(?) UI for EV certs, other browser manufacturers have some
> incentive to follow their lead unless they can think of something
> obviously better.
>
reason for our proposal...And what if Microsoft follows the lead of
Mozilla thereafter?
> Even though I consider myself security savvy, I'd rather not deal with
> multiple levels in the browser myself.
who have the knowledge, background and technical skills to deal with
that...Otherwise you'd rather not build a browser with SSL capabilities!
>
>> There are various other valid standards for CA's and nothing, but
>> nothing will change the role of the browser vendor in this respect. EV
>> is just another standard! Auditing was always a job of a third party and
>> I don't see anywhere in the current CA policy, that Mozilla is supposed
>> to do the auditing. Nothing will change in that respect!
>>
>
> You say that like standards have no value, and are all just useless
> pieces of paper.
>
>
>>> because removing e.g. Verisign would break half the SSL
>>> sites on the web.
>>>
>> Which would give Verisign or other similar CA's (all of them owned by
>> Verisign anyway) a license to do whatever they like! Your statement
>> above is extremely dangerous! Because you just said, that you are
>> willing to compromise half of the SSL enabled sites of the Internet,
>> because of their market share!?!?!
>>
>
> Have there been cases where a CA has been consistently so bad that it
> should have warranted removal?
>
card is the wrong message perhaps! Or do you want examples from me,
about the "CLICK TO CONTINUE" certs and issued wrongfully to "Microsoft,
Inc." by this very same CA? Obviously they didn't perform according to
their own policy, else this wouldn't have occurred!
Duane
> I haven't yet read the EV draft fully to see how closely it matches my
> expectations, but commentary from other people seems to indicate it is
> reasonable (barring some bugs and clarifications). I believe it will
> improve the situation. I know it won't be 100% foolproof, but then again
> I don't think anything can be.
How can it be considered reasonable if the number of businesses using EV
certificates will be relatively low? shouldn't Mozilla and other
interested parties that are supposed to be looking out for their users
actually be doing something that will work for all sites? Having a big
bank account doesn't equate to trust, look at the Enrons of the world.
This is of course where trust bar et al comes in, they don't require a
monetary barrier to entry, which isn't a barrier to entry for those
suitably motivated.
And no matter what Gerv says, the crux of the issue is this is all about
monetary barriers to entry because all it takes is enough money and any
of the barriers thought thus far up can be over come.
Heikki Toivonen
> Robert Sayre wrote:
>
>> I believe it presents a higher barrier. Since there is no technical
>> advantage to EV, I am not sure that will matter, once ways of
>> manipulating the EV system are discovered by criminals (does anyone
>> think they won't figure something out?). I don't think Mozilla should
>> jump in right away. This is unpleasant, because it would then appear
>> that IE has a "feature" we lack. So, I understand the desire to go ahead.
>
> As usually I've come to the conclusion that mozilla reps are asking for
> feedback, but don't really care for answers as their minds are either
> made up, or just don't care.
I fail to see this. What is not changeable? What do you propose instead?
> This is going to be another click through popup, everyone will associate
> yellow v green, as most sites I going to be yellow long after whatever
> is passed by the powers that be, so everyone might as well keep going
> with the connection to this site because we've become numb with
> conditioning that yellow is good and the padlock is still there which
> I've always been told to look for.
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.
> What's really sad here is instead of leading security mozilla are happy
> to follow like sheeple, instead of embracing university researchers in
> ways of making browsing safe, they are embracing and extending
> Verisign's bank balance.
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.
> As some have pointed out on the anti-fraud list (Gerv is also on that
> list), identity isn't a good thing to make strong because then it only
> leads to identity fraud, and what he fails to grasp is the fact that no
> matter how strong or good he thinks this system is others will still
> find loop holes *if* they even feel it's necessary.
I fail to find the logic in not letting me know the identity of the
website operators I want to do business with.
Everyone understands we cannot make anything 100% safe. But we can make
things safer than they are now.
--
Heikki Toivonen
Duane
> I fail to see this. What is not changeable? What do you propose instead?
Gerv is pretty adamant about supporting EV, and doesn't seem swayed at
all by any arguments and discounts everything everyone has said in the
past, yet so readily accepts Verisign's proposals...
> 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.
This might be good or bad, disabling click through might end up making
people disable SSL altogether, would that be better, perhaps at least
there wouldn't be an assumption of privacy, although even with SSL
things could be subverted by Governments.
> I fail to find the logic in not letting me know the identity of the
> website operators I want to do business with.
ok this is the crux of my argument, the problem I have isn't with the
proposal, it is with the assumptions being stated as fact surrounding
it, ie "This will make users safer" which is a load of crap, since most
people shopping online may or may not be in a position to sue, and law
enforcement may or may not be more willing to do anything about any
transgressions.
We can assume (with some certainty, anyone that has dealt with small
companies will know how much they can penny pinch) 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.
> 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.
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).
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.
What is needed is research into safer browsing, not assumptions by one
company designed to let it keep it's monopoly position in a market, this
doesn't benefit users (how can it when most certs won't be EV?).
I'm not saying trust bar et al are the answer, but at least the guys
making those proposals have at least conducted research into what end
users think when hitting sites and thinking out side of the whole PKI is
the only way to do this box.
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?
Eddy Nigg (StartCom Ltd.)
>> In theory a user (RP) should read the CA
>> policy of the issuing CA before trusting a certificate, otherwise how
>> should he know about the verifications performed or any other procedure
>> a CA promises? Obviously, this is not very practical, hence our
>> proposal for a simplified but improved UI change!
> especially considering those policies can be written in any language.
>
> I have to disagree with you on some of your UI choices though.
> I think
> everything the user needs to make a decision about trusting a site needs
> to be visible by default.
> Requiring the user to mouse over a control
> gets tedious quickly even for people who know about it, and those that
> don't know may never discover it.
>
by..." mouse over, according to your argument above...It might never be
seen by the user and requires to control the mouse...
>
> I haven't yet read the EV draft fully to see how closely it matches my
> expectations,
>
Eddy Nigg (StartCom Ltd.)
>
> 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.
>
> 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.
>
Other tools exists additionally. Digital certification is rarely used by
the 200,000 plus pishing sites, but digital certification solves
different problems, such as protection by encryption and identity
verification for sharing of information.
This thread is about, if and how the UI should be affected - if at all -
when encountering a EV certificate. EV certification is a new and under
development standard in addition to many others, including common
policies and practices of CA's. Currently I have seen opposition to this
from various sides.
> I fail to find the logic in not letting me know the identity of the
> website operators I want to do business with.
>
And I fail to understand, why you shouldn't know the identity of the web
site operator?
Eddy Nigg (StartCom Ltd.)
> We can assume (with some certainty, anyone that has dealt with small
> companies will know how much they can penny pinch) 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.
>
http://www.theregister.co.uk/2006/10/25/verisign_extended_validation/
Alaric Dailey
> Boris Zbarsky wrote:
>> No, he means "once all the reputable businesses have EV certs,
>> it'll be to the CA's financial advantage to introduce a new 'even
>> more trustworthy' type of cert (call it EEV), so they can sell all
>> those businesses EEV certs too".
>
> The CAs can't provide a business case for that unless the browsers
> agree to have yet another UI differentiator for these new EEV certs.
> And that's pretty unlikely, given that we want to reduce UI
> complexity and make security decisions easier. We'd have no motive
> to support EEV, even if they went off and invented it.
Uh yeah...
and we aren't talking about "Jumping to" because MS and Verisign
invented this new type of cert?
And aren't "High Assurance" certificates (as they exist now from
places like Comodo) supposed to be doing the same thing? More
assurances, and higher prices mean nothing, if the browsers don't
provide a UI for the users to validate the certs (and what those certs
mean) easily.
As someone who runs an SSL website, given a choice between the new EV
certs and the older certs (ignoring price), why bother? I get nothing
out of it, my users get nothing out of it (except maybe a green bar).
And it doesn't solve any issue that this (
http://www.wikidsystems.com/WiKIDBlog/categories/Mutual%20Authentication
) doesn't solve better.
Remember there are least 2 Free CAs listening and contributing on this
list, that means monetary barriers (assuming a steep price from
Verisign) won't be an issue for phishers.
<http://cert.startcom.org/?app=109>
Duane
> Remember there are least 2 Free CAs listening and contributing on this
> list, that means monetary barriers (assuming a steep price from
> Verisign) won't be an issue for phishers.
Since phishing exists happily with no SSL, why would they start using
SSL all of a sudden now that EV's are being discussed?
This will do very little for security for anyone as it fails to address
the real problems and tries to attack a niche situation that isn't under
attack...
I'm a little confused here, can someone please explain to me how this is
supposed to help the vast majority of users?
Alaric Dailey
> Alaric Dailey wrote:
>
>
>> Remember there are least 2 Free CAs listening and contributing on this
>> list, that means monetary barriers (assuming a steep price from
>> Verisign) won't be an issue for phishers.
>>
>
> Since phishing exists happily with no SSL, why would they start using
> SSL all of a sudden now that EV's are being discussed?
>
> This will do very little for security for anyone as it fails to address
> the real problems and tries to attack a niche situation that isn't under
> attack...
>
> I'm a little confused here, can someone please explain to me how this is
> supposed to help the vast majority of users?
>
>
I don't think EV certs are meaningful AT ALL.
So far I have seen nothing from the Spec that makes me think that anyone
would bother with them... short of IE refusing to use current
certificates, or possibly some dramatic improvement that I have yet to see.
<http://cert.startcom.org/?app=109>
Eddy Nigg (StartCom Ltd.)
> Since phishing exists happily with no SSL, why would they start using
> SSL all of a sudden now that EV's are being discussed?
>
perhaps partially a certification problem, not necessarily the pishing
problem.
> This will do very little for security for anyone as it fails to address
> the real problems and tries to attack a niche situation that isn't under
> attack...
>
> I'm a little confused here, can someone please explain to me how this is
> supposed to help the vast majority of users?
>
>
and issuer details. Maybe different colors (including green) isn't the
best way to go after all.
To Grev: We have some ideas and will put up those additional ideas and
proposals later today for consideration.
Gervase Markham
> I believe it presents a higher barrier. Since there is no technical
> advantage to EV, I am not sure that will matter, once ways of
> manipulating the EV system are discovered by criminals (does anyone
> think they won't figure something out?). I don't think Mozilla should
> jump in right away. This is unpleasant, because it would then appear
> that IE has a "feature" we lack. So, I understand the desire to go ahead.
I agree that it's possible that a loophole may be found; however, we
have mechanisms in place to update the standard when and if it is. (I
can't envisage a scenario where fraudsters are regularly getting hold of
EV certs and no-one notices; by the very nature of fraud, someone will
notice.) So I don't think the possibility of future problems should
prevent us from going ahead; after all, someone could break SSL
tomorrow, but we still use it for now.
I am not suggesting the implementation of EV to keep feature parity with
IE, I am suggesting it because I think that it provides what SSL should
have provided all along, and that something is something we want.
> We will probably arrive at this state if we are at all serious. We need
> to have a clear definition of "obvious disregard" and the consequences,
> so the event doesn't become a negotiation.
Well, it's never a negotiation, because we have unilateral power :-) If
you look at the current CA policy, you will see the words:
"We reserve the right to ... discontinue including a particular CA
certificate in our products, or to modify the "trust bits" for a
particular CA certificate included in our products, at any time and for
any reason."
It then goes on to give examples, but is careful to state that we are
not limited by them.
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
Gerv
Gervase Markham
> Gerv is pretty adamant about supporting EV, and doesn't seem swayed at
> all by any arguments and discounts everything everyone has said in the
> past, yet so readily accepts Verisign's proposals...
Your axe-grinding just makes you more likely to be ignored. These are
not "Verisign's proposals", spin via The Register notwithstanding.
> ok this is the crux of my argument, the problem I have isn't with the
> proposal, it is with the assumptions being stated as fact surrounding
> it, ie "This will make users safer" which is a load of crap, since most
> people shopping online may or may not be in a position to sue, and law
> enforcement may or may not be more willing to do anything about any
> transgressions.
If law enforcement is unwilling to prosecute fraud, then all that's left
is reputation. For reputation, you need to know who you are dealing
with. EV provides that - even on first contact.
> We can assume (with some certainty, anyone that has dealt with small
> companies will know how much they can penny pinch) 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%),
The worst-case scenarios presented by members of the CA Browser forum
(in the context of an argument where it was to their advantage to
minimise the numbers) was 20%.
> so we are left with a situation of EV certificates only covering 1%
> of business,
1% (or 20%) of businesses is definitely not the same as 1% (or 20%) of
_business_. Because not all businesses do an equal amount of business.
If only the top 10,000 retailers on the web adopted EV (and I hope it
will be much more widely adopted than that, in time), for a large number
of web users that would be every site they use.
> 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).
Indeed they have, in the real world. However, there are various things
about the real world which have no online analog. Primarily, if I visit
132, Church Street in London to a particular shop, I have numerous cluse
from the location and appearance of the shop as to its age and
trustworthiness. If I buy something from a shop, and it turns out to be
defective, I am pretty certain of finding that shop again if I return to
the same address.
Neither of these things are true online. A business set up an hour ago
can look like one which has been trading for ten years; and a business
at one address today can be gone tomorrow.
Therefore, the "people have been creating relationships for a long time"
argument does not translate directly from the real world to the online one.
> 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.
I am happy to say that preventing another Enron is out of scope for EV.
Gerv
Gervase Markham
> http://www.theregister.co.uk/2006/10/25/verisign_extended_validation/
That article is mostly rubbish. Even the people quoted in it have said
they were taken out of context.
http://blogs.verisign.com/ssl-blog/2006/10/my_badly_worded_offhand_statem.html
Gerv
Gervase Markham
> suggest high costs for the CA and therefore for the subscriber.
Higher, certainly.
>> Can you be more specific than "various reasons", and explain the
>> reasoning behind your "most likely"?
> Many companies, specially smaller ones, will have various problems to
> satisfy the requirements of the EV standard in addition to the most
> likely high costs entailed with the extensive checking!
Which requirements do you think are particularly burdensome?
(Please also remember that work is being done to extend the EV
guidelines to make it possible for individuals to get certs.)
>> Indeed. And I submit that the user has two possible states in mind:
>> "enough" and "not enough".
> This depends on the level of risk involved! Enough and not enough is not
> something general, whereas enough for A, might be not enough for
> performing B and otherwise. We suggest to give an indication HOW
> rigorous a subscriber was verified. According to this indications a
> relying party can make a proper decision if to proceed.
Can you talk me through the thought processes of someone trying to make
that decision, if the UI is as you state?
"OK, that's a purple bar. Now purple is one step above white and one
below green. That means, let me think, it's OK for me to make purchases
up to $500, as long as I use a credit card with payment protection, but
it's probably not safe for my debit card."
?
I suggest that there's only really one level - "safe for my credit card
number".
> Good! Therefore we should focus on how the UI can be improved properly
> to give the most and best information to the user,
I completely disagree that we should focus on how to give the *most*
information to the user. *Best*, certainly.
> about how a digital
> certificate was processed. Your suggestion of enough or not enough is
> just the padlock in another form! Not much is gained here...You might
> just leave it as is!
It is certainly theoretically possible that we could choose to make the
padlock the EV indicator. However, I suggest that the practical effects
of that would cause great confusion, as initially the lock would
disappear on a lot of sites.
> Because valuable information is included in a digital certificates, such
> as details about the subscriber, issuer and additional notes of the CA.
> Displaying this information might help to prevent user mistakes and
> provide indication about the certificates policy etc.
Given that we have difficulty educating users even to look for a padlock
(although admittedly this has not been pushed hard, at least by us, due
to the lack of a standard underlying the padlock), I suggest that
presenting more information is not going to help.
Usability suggests that we need to present the minimum information
necessary for the user to make the decision at hand. The decision we are
thinking about is "can I put my credit card number into this site?".
This is a yes/no question, and so a yes/no indicator is most
appropriate. Most users do not have the understanding or tools to make
this decision based on raw certificate data.
Gerv
Gervase Markham
> Heikki Toivonen wrote:
>
>> I haven't yet read the EV draft fully to see how closely it matches my
>> expectations, but commentary from other people seems to indicate it is
>> reasonable (barring some bugs and clarifications). I believe it will
>> improve the situation. I know it won't be 100% foolproof, but then again
>> I don't think anything can be.
>
> How can it be considered reasonable if the number of businesses using EV
> certificates will be relatively low? shouldn't Mozilla and other
> interested parties that are supposed to be looking out for their users
> actually be doing something that will work for all sites? Having a big
> bank account doesn't equate to trust, look at the Enrons of the world.
Number of businesses != number of transactions, as I've pointed out
earlier. And you need to produce some evidence for your assertion that
very few businesses will want EV. That depends on a number of factors -
price, difficulty of obtaining one, and the publicity campaign
surrounding it. The latter is pretty important. If banks, browser
makers, CAs, consumer advocacy groups and online shops are all saying
"Look for the green bar", we can a) persuade users to look for it, and
b) persuade merchants to want it.
We can't have such a campaign around the lock because there's no
standard behind it; it would be building on sand. But if we have
something with a standard, which can be improved and reinforced if holes
are found, we have a rock on which to build a campaign to improve public
safety on the net.
> And no matter what Gerv says, the crux of the issue is this is all about
> monetary barriers to entry because all it takes is enough money and any
> of the barriers thought thus far up can be over come.
Of course they can. But no jeweller buys a $10,000 diamond for $100,000.
If it costs more to get over the barriers than you can reap from the
resulting phishing expedition, criminals won't bother. They are
businesses, just the same as Amazon or Google. They are looking to turn
a profit too.
Gerv
Gervase Markham
> As usually I've come to the conclusion that mozilla reps are asking for
> feedback, but don't really care for answers as their minds are either
> made up, or just don't care.
I certainly care for answers. Of course, I'm not going to be the one
doing the implementing; I suspect that the decision will be taken by Dan
Veditz (security) and Mike Beltzner (UI), in consultation with others.
> Until numerous conditions have been met forcing all sites doing some
> form of business into using EV certificates (and paying through the nose
> for it), people will continue to use cheap certs to operate, and
> phishing sites will continue not to use certs at all, and so what is
> gained unless you not only have an approach for how to issue EV certs
> compared to enforcing their use?
If phishing sites continue to use no certs, and people continue to be
fooled, then yes, EV does not help. As I've said before, it's hard to
protect the guy who types his CC number into any form which asks for it.
Some amount of user education is inevitable - that is true even if EV
didn't exist.
On the other hand, if you want to spoof PayPal and PayPal has an EV
certificate, one might hope that the fact that there's been a green bar
every time before, combined with Paypal's regular reminders on various
pages to "check for the green bar", might make people pause for thought
if the bar is not there. It's a lot more obvious than the lock, after all.
> This is where the scammers will win, because to get the majority across
> you would have to have a low price point, and that isn't going to happen.
I don't think that's necessarily true. And anyway, neither you or I have
a good idea what sort of price point these certificates are going to
come out at. Given that there is competition in the CA market, I'm
hoping the prices will be reasonable. And, as the green bar becomes
synonymous with a degree of safety, more sites will want it.
> What's really sad here is instead of leading security mozilla are happy
> to follow like sheeple, instead of embracing university researchers in
> ways of making browsing safe, they are embracing and extending
> Verisign's bank balance.
Now is not the time to again bring up my personal issues with various
proposals which have been made in the past; but I would comment in
general that often, while proposals have a good understanding of
security, they have a less than perfect understanding of usability.
Gerv
Gervase Markham
> and we aren't talking about "Jumping to" because MS and Verisign
> invented this new type of cert?
No, they didn't. It was invented by a consortium of CAs and major
browser vendors.
> And aren't "High Assurance" certificates (as they exist now from
> places like Comodo) supposed to be doing the same thing?
Supposedly. However, as Comodo won't tell you exactly what they do to
make it "High Assurance", you can't tell.
> More
> assurances, and higher prices mean nothing, if the browsers don't
> provide a UI for the users to validate the certs (and what those certs
> mean) easily.
What do you mean by "a UI to validate the certs"? What would such a UI do?
> As someone who runs an SSL website, given a choice between the new EV
> certs and the older certs (ignoring price), why bother? I get nothing
> out of it, my users get nothing out of it (except maybe a green bar).
It depends what you are doing on your SSL website. If you need people to
find your site via a search engine and then immediately trust you with
their credit card number, it may well be what you want. If you don't, it
may not.
> Remember there are least 2 Free CAs listening and contributing on this
> list, that means monetary barriers (assuming a steep price from
> Verisign) won't be an issue for phishers.
EV is not designed to exclude phishers by high monetary prices. Whatever
the price is, it's a side-effect of the need to do additional validation
- which is the barrier. A phisher either has to give away information
about himself, of expend a lot of money spoofing the various indicators
and sources that the CA uses to cross-check. If he does the former, he
can be arrested. If he does the latter, he won't get a return on his
"investment".
Gerv
Gervase Markham
> Since phishing exists happily with no SSL, why would they start using
> SSL all of a sudden now that EV's are being discussed?
The use of SSL in phishing is on the increase.
Additionally, one reason why phishers haven't been using SSL is because
browser makers and others aren't screaming "look for the lock"; and the
reason they aren't doing that is because they know phishers will then
start getting domain-validated certs and we'll be no further forward.
If we are going to try and educate the public to look for a trust
indicator, we need a trust indicator which is worthy of the name.
Gerv
Gervase Markham
>> able to do that. Please let me know exactly what.
>
> For example Mozillas own CA policy would be a good start.
No, I mean particular alternative audit scheme (such as ETSI). Did you
have one in mind?
>> 4) c) 1) says "related to their respective performance and obligations
>> under these Guidelines"; so it's just for EV.
> May I suggest to make that perhaps in relation to a ratio of issued
> certificates, something like from 0-1000 issued certificates X
> insurance, from 1001 - ....and so on...
I don't understand what you are asking for here. The insurance
requirements apply only to EV. So it's irrelevant how many certs of any
other type the CA issues. And you need the same level of insurance
whether you are issuing 1 EV cert or 10,000. However, your premium may
be different if you issue more, I don't know.
>>> Obviously a very small number of businesses will
>>> acquire EV certificates,
>> Why is this obvious?
> Overhead operational costs and requirements such as physical check of
> the premise will make this type of certification certainly expensive, so
> expensive is a relative term...Additionally many businesses will have
> difficulties complying to every criteria.
Which criteria do you think are particularly difficult, and how would
you change them?
>> So is "reasonable" verification good enough for a user to hand over
>> their credit card details? If so, what's the point of level 3? If not,
>> what's the point of level 2?
> It depends on the user and not on your personal opinion. It depends
> which information the user is going to share with the site operator and
> what is the behavior of the user generally perhaps. People share this or
> other information every day with a cab driver, restaurant, on-line shop
> and who not...For user A reasonable verification might be enough whereas
> for user B it's not. What do you know about a cab driver somewhere? Our
> position is, to give the user enough information in order to make a
> personal judgment, not deciding for the user what is good for him and
> what not!
But a user does not have any basis on which to make that judgement.
Take my mother. She comes to a website where she wants to buy $100 worth
of clothes. (Let's say, for simplicity, that she knows how much stuff
she wants to buy before she even starts, which is unusual.) Should she
accept "reasonable verification" or not? How should she decide? What
information should she use, and in what way should she process that
information to arrive at a decision?
Gerv
Gervase Markham
> First, that's the wrong question to ask, since unless the draft
> explicitly says that it *should* be revoked, a CA is unlikely to do
> so for fear of being sued or otherwise accused of violation of
> contract by the company they're selling the cert to. If you think
> that certificates should be revoked on these grounds, then the
> section on revocation should say so explicitly.
Fair enough.
> Second, yes, it does. B.2.c says explicitly that: "an EV
> certificate is *not* intended to provide any assurances, or
> otherwise represent or warrant: (1) [...] (2) That the Subject named
> in the EV Certificate complies with applicable laws; (3) That the
> Subject named in the EV certificate is trustworthy, honest, or
> reputable in its business dealings [...]"
Indeed. But you can be dishonest without misrepresenting your identity.
I believe this is in there to cover the situation where a user tries to
hold a CA responsible because they paid a firm for something over the
web and it turns out that the director took all the money and ran off to
Tahiti.
But I will seek clarification on this point. Thank you for raising it.
>> Not many, I agree. However, in order to correctly spoof WAMU (at least
>> in the IE 7 UI) they would need to incorporate their fake company in the
>> US. And, if they did that, the information gathered during the EV
>> process could be used to track the applicant down and prosecute them.
>
> I'm skeptical of whether law enforcement authorities care, or
> whether victims of phishing care enough to yell at law enforcement
> enough so that they care. The last time I tried to interest law
> enforcement with investigating computer crime, they didn't. Then
> again, that was about 10 years ago.
I suspect things have changed a bit since then; however, you are right,
we cannot be certain that a prosecution will always result.
> Criminal prosecution is a very expensive and complex process, and
> only works as a disincentive if a high enough percentage of
> criminals are prosecuted and convicted. Having simpler incentives
> against crime (such as making the crime harder to commit or less
> profitable) is vastly preferable when possible.
Indeed. And I hope that EV does make the crime harder to commit by
requiring a lot of information, and less profitable by requiring OCSP.
Gerv
Gervase Markham
>> Since IE
>> has the first(?) UI for EV certs, other browser manufacturers have some
>> incentive to follow their lead unless they can think of something
>> obviously better.
>>
> As someone else pointed out, Mozilla should lead, not follow. That's the
> reason for our proposal...And what if Microsoft follows the lead of
> Mozilla thereafter?
But we should only lead where we think a particular innovation is
actually better. We should not be different just for the sake of being
different.
>> Even though I consider myself security savvy, I'd rather not deal with
>> multiple levels in the browser myself.
> Nobody asked you to do this. There are very capable people at Mozilla
> who have the knowledge, background and technical skills to deal with
> that...Otherwise you'd rather not build a browser with SSL capabilities!
He means as a user, he would rather not deal with multiple levels in the
UI. And Heikki is, as it happens, one of the "capable people at Mozilla
who have... etc.".
>>> There are various other valid standards for CA's and nothing, but
>>> nothing will change the role of the browser vendor in this respect. EV
>>> is just another standard! Auditing was always a job of a third party and
>>> I don't see anywhere in the current CA policy, that Mozilla is supposed
>>> to do the auditing. Nothing will change in that respect!
>>>
>> You say that like standards have no value, and are all just useless
>> pieces of paper.
>>
> What did I say?
To rephrase him: "You are speaking as if standards have no value, and
are all just useless pieces of paper."
> I don't know, but because of market share giving a certain CA a green
> card is the wrong message perhaps! Or do you want examples from me,
> about the "CLICK TO CONTINUE" certs and issued wrongfully to "Microsoft,
> Inc." by this very same CA? Obviously they didn't perform according to
> their own policy, else this wouldn't have occurred!
So you would be happy for your own CA to be held to a 100% correct
issuance standard? That is, if you issued one certificate incorrectly,
you would be immediately and permanently removed from all browsers
everywhere?
Gerv
Robert Sayre
>
> I agree that it's possible that a loophole may be found; however, we
> have mechanisms in place to update the standard when and if it is.
Will happen. Just a matter of time.
> (I
> can't envisage a scenario where fraudsters are regularly getting hold of
> EV certs and no-one notices; by the very nature of fraud, someone will
> notice.)
Calling them fraudsters makes them sound unsophisticated. I can
certainly envision criminals regularly exploiting EV certs. That is the
status quo with normal certs, and it doesn't seem to bother the CAs much.
> So I don't think the possibility of future problems should
> prevent us from going ahead; after all, someone could break SSL
> tomorrow, but we still use it for now.
I think it should stop us from covering our UI in green bars and locks
that are trivial to spoof in content. We know users aren't very good at
distinguishing chrome from content in the first place, and even my bank
site looks like a scam--it's got some corny lock gif right there next to
the form.
I think it's safe to say you're not going to convince me. I do hope we
treat this initiative with a little more skepticism as we explore it
further, and it bothers me that I don't see an incentive for the CAs to
prevent EV certs from becoming as much of a joke as normal certs. I
wonder if I can pay cash for those at 7-11.
-Rob
Alaric Dailey
> Alaric Dailey wrote:
>> and we aren't talking about "Jumping to" because MS and Verisign
>> invented this new type of cert?
>
> No, they didn't. It was invented by a consortium of CAs and major
> browser vendors.
>
>> And aren't "High Assurance" certificates (as they exist now from
>> places like Comodo) supposed to be doing the same thing?
>
> Supposedly. However, as Comodo won't tell you exactly what they do to
> make it "High Assurance", you can't tell.
>
>> More
>> assurances, and higher prices mean nothing, if the browsers don't
>> provide a UI for the users to validate the certs (and what those certs
>> mean) easily.
>
> What do you mean by "a UI to validate the certs"? What would such a UI
> do?
to be ignored just like the lock.
>
>> As someone who runs an SSL website, given a choice between the new EV
>> certs and the older certs (ignoring price), why bother? I get nothing
>> out of it, my users get nothing out of it (except maybe a green bar).
>
> It depends what you are doing on your SSL website. If you need people
> to find your site via a search engine and then immediately trust you
> with their credit card number, it may well be what you want. If you
> don't, it may not.
>
>> Remember there are least 2 Free CAs listening and contributing on this
>> list, that means monetary barriers (assuming a steep price from
>> Verisign) won't be an issue for phishers.
>
> EV is not designed to exclude phishers by high monetary prices.
> Whatever the price is, it's a side-effect of the need to do additional
> validation - which is the barrier. A phisher either has to give away
> information about himself, of expend a lot of money spoofing the
> various indicators and sources that the CA uses to cross-check. If he
> does the former, he can be arrested. If he does the latter, he won't
> get a return on his "investment".
So what you are telling me is that any class 3 server cert from CAcert
is just as good, if not better than, an EV certificate because the
person (ignoring weaknesses in the system, like paying off Assurers)
went thru the trouble of getting validated in Person, by a minimum of 2
people?
Maybe CAs that follow such rules should get an Aquamarine bar, to
differentiate them.
Ka-Ping Yee
> If phishing sites continue to use no certs, and people continue to be
> fooled, then yes, EV does not help. As I've said before, it's hard to
> protect the guy who types his CC number into any form which asks for it.
Indeed -- but that particular straw-user isn't the only type that will
remain phishable after deployment of EV. There are many kinds of users:
A. Users who don't click on bank website links in e-mail (and instead
navigate by bookmark or URL)
B. Users who can distinguish the chrome from the page and look for
padlocks in the chrome, ignoring padlocks in the page
C. Users who can distinguish the chrome from the page and look for
a yellow URL bar in the chrome, ignoring URL bars in the page
D. Users who can distinguish the chrome from the page and look for
'https' in the URL bar in the chrome, ignoring URL bars in the page
E. Users who can distinguish the chrome from the page and don't notice
the 'https', the yellow bar, or the padlock in chrome now, but
would notice a green bar in the chrome
F. Users who can reliably tell whether SSL is enabled, but could be
socially engineered into ignoring it ("sorry, encryption is down
today; certificate will be updated soon; please proceed anyway")
G. Users who can't tell the difference between the chrome and the
page (and e.g. would be fooled by a picture-in-picture attack)
H. Users who type their username and password into a form whenever
the page surrounding it looks familiar
This is just off the top of my head -- the above is surely incomplete.
Anyway, my point is: none of these seven types of users can be
casually dismissed as "stupid". But it is instructive to do this
kind of breakdown and analysis, because it gives you an upper bound
on the impact of an anti-phishing measure. The only type that will
be helped by the introduction of EV is group E. How big is group E?
We don't know exactly how many users are in each group. Group A
describes many people i know -- but all those people are immune to
phishing attacks, so that clearly doesn't represent everyone.
Research shows that lots of people are in groups G and H. [1]
And i'd be willing to bet a lot more of us are in group F than might
like to admit. My guess would be, that has to do with our perception
of the level of technical security competence at these bank websites,
which is quite low, and our perception of the level of difficulty of
certificate administration, which is somewhat high.
> On the other hand, if you want to spoof PayPal and PayPal has an EV
> certificate, one might hope that the fact that there's been a green bar
> every time before, combined with Paypal's regular reminders on various
> pages to "check for the green bar", might make people pause for thought
> if the bar is not there. It's a lot more obvious than the lock, after all.
This is precisely the sort of thing that should be user-tested before
a standard recommended UI is specified. Your claim of "more obvious"
sounds plausible, but (alas) real user behaviour doesn't always
reflect what sounds plausible.
Given that Microsoft (as far as i know) is the only browser vendor so
far to implement an EV UI, have they run user studies on it? Does
Mozilla have plans to run user studies on the EV UI in Firefox?
-- ?!ng
[1] http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf
Ka-Ping Yee
> browser makers and others aren't screaming "look for the lock"; and the
> reason they aren't doing that is because they know phishers will then
> start getting domain-validated certs and we'll be no further forward.
How sure can we be that this is the reason phishers don't use SSL?
Lots of websites encourage their users to look for the lock, and
the fact that they put all these stupid lock icons on their pages
(sometimes even with popups instructing users not to worry about
the lack of a padlock in the URL bar *headdesk*) shows that it
clearly means something to the people who run these websites.
> If we are going to try and educate the public to look for a trust
> indicator, we need a trust indicator which is worthy of the name.
Careful! EV is NOT a "trust indicator", as you have been pointing
out, and as the EV guidelines emphasize. This is more like a
"legally suable entity indicator" (if i understand right -- i
encourage you to find a name for it that is both accurate and less
awkward than mine!)
-- ?!ng
Heikki Toivonen
>> 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.
> Interesting! Can you be more specific on what you propose here?
It's not my proposal, and has in fact been discussed by people for
years. The basic idea is that if you go to a site and there is an SSL
error (expired cert, wrong host error, whatever), instead of a dialog
box with an OK button you are treated with an error page. There is no
way to click OK. You can simply not get to the site. This takes the
likely uninformed user out of the picture.
>> I fail to find the logic in not letting me know the identity of the
>> website operators I want to do business with.
>>
> And I fail to understand, why you shouldn't know the identity of the web
> site operator?
I am not sure I understand your question.
Here's my usage scenario I was thinking about:
I want to buy some new gadget. It is expensive, so I want to do some
research to find the cheapest place to buy it. Using various search
engines I arrive at site that has it in a price range I like. Being
conscious about security, I check that they support SSL on the shopping
page. However, this is a site I have never visited before.
Now, what is there to help me make a decision about the trustworthiness
of the site, and the possibility of getting law enforcement involved if
I feel wronged? Just to list some things I could do: check how
professional the site looks, look at whois information, search for
opinions from other shoppers, and so on. For new sites there won't be
much available.
Then there's the certificate. But with today's domain validation only
certificates that is not much help. If they were using EV certificate, I
would be more confident that they are a real company at least, and I
could get their real contact information in case of problems.
--
Heikki Toivonen
Heikki Toivonen
>> everything the user needs to make a decision about trusting a site needs
>> to be visible by default.
> So you agree with me? ;-)
On the principle, but perhaps we want different things present by default.
>> Requiring the user to mouse over a control
>> gets tedious quickly even for people who know about it, and those that
>> don't know may never discover it.
>>
> Well, if this is the case, then lets remove also the "Authenticated
> by..." mouse over, according to your argument above...It might never be
> seen by the user and requires to control the mouse...
I am not against having optional features that show additional
information on mouse over. I think "Authenticated by" is optional, and
means nothing to most users.
--
Heikki Toivonen
Eddy Nigg (StartCom Ltd.)
from you and as promised make some suggestions. This will be a somewhat
lengthy reply because of this. Sorry for this!
Gervase Markham wrote:
>> As someone else pointed out, Mozilla should lead, not follow. That's the
>> reason for our proposal...And what if Microsoft follows the lead of
>> Mozilla thereafter?
>
> But we should only lead where we think a particular innovation is
> actually better. We should not be different just for the sake of being
> different.
I absolutely agree with you! I really think, there is a chance to make
certain things actually better.
>> What did I say?
>
> To rephrase him: "You are speaking as if standards have no value, and
> are all just useless pieces of paper."
Oh no, absolutely not! Standards are good, but it mostly depends on the
purpose and the problem the standard is solving.
>
>> I don't know, but because of market share giving a certain CA a green
>> card is the wrong message perhaps!
>
> So you would be happy for your own CA to be held to a 100% correct
> issuance standard? That is, if you issued one certificate incorrectly,
> you would be immediately and permanently removed from all browsers
> everywhere?
No! But you don't answer on what I said...did you realize what you
actually proposed? Sincerely? You actually suggested, that StartCom (or
other smaller CA's) could be kicked out for a mistake, but Verisign will
stay there, no matter what, because of market share. Except that, the
StartCom CA strifes for 100 % adherence to the CA policy (which is the
promise we give to the subscriber and relying party) and beyond!
>
>> For example Mozillas own CA policy would be a good start.
>
> No, I mean particular alternative audit scheme (such as ETSI). Did you
> have one in mind?
There can be various audit schemes, however I would like to see
alternatives to the WebTrust auditors which is in my opinion an
expensive monopoly. There are valuable alternatives and perhaps
definitions available, which would create also some competition in this
field!
>
> I don't understand what you are asking for here. The insurance
> requirements apply only to EV. So it's irrelevant how many certs of
> any other type the CA issues. And you need the same level of insurance
> whether you are issuing 1 EV cert or 10,000. However, your premium may
> be different if you issue more, I don't know.
I understood, that this is for EV only. Based on the knowledge we have
(for example how much we pay for our insurance), it might be quite
expensive (of course a relative term). We'd like to see a way to lower
that cost perhaps.
>
>> Overhead operational costs and requirements such as physical check of
>> the premise will make this type of certification certainly expensive, so
>> expensive is a relative term...Additionally many businesses will have
>> difficulties complying to every criteria.
>
> Which criteria do you think are particularly difficult, and how would
> you change them?
For example: _16. Verification of Applicant’s Physical Existence_ might
be problematic, specially a visit at the premise from the CA point of view.
>
>
> Additionally, one reason why phishers haven't been using SSL is
> because browser makers and others aren't screaming "look for the
> lock"; and the reason they aren't doing that is because they know
> phishers will then start getting domain-validated certs and we'll be
> no further forward.
>
> If we are going to try and educate the public to look for a trust
> indicator, we need a trust indicator which is worthy of the name.
Which in your opinion a green address bar is?
> Alaric Dailey wrote:
>> and we aren't talking about "Jumping to" because MS and Verisign
>> invented this new type of cert?
>
> No, they didn't. It was invented by a consortium of CAs and major
> browser vendors.
>
>> And aren't "High Assurance" certificates (as they exist now from
>> places like Comodo) supposed to be doing the same thing?
>
> Supposedly. However, as Comodo won't tell you exactly what they do to
> make it "High Assurance", you can't tell.
Can Melih from Comodo speak up on this?
>> This depends on the level of risk involved! Enough and not enough is not
>> something general, whereas enough for A, might be not enough for
>> performing B and otherwise. We suggest to give an indication HOW
>> rigorous a subscriber was verified. According to this indications a
>> relying party can make a proper decision if to proceed.
>
> Can you talk me through the thought processes of someone trying to
> make that decision, if the UI is as you state?
Yes! A new idea for this would be, on a first visit at an SSL enabled
site to present the user with a window with important and informative
details. Not a warning popup, but a friendly message, displaying the
most critical information the CA has bothered to include in the
certificate. Otherwise why should a CA bother to include this and other
information, if you have to click through 5 buttons in order to get a
clue about the subscriber. This is currently specially ridiculous,
because so much weight is put on the subject line (including EV), when
the average user, who after all knows how to handle a mouse, never ever
will actually see it! Think about it!
>
> "OK, that's a purple bar. Now purple is one step above white and one
> below green. That means, let me think, it's OK for me to make
> purchases up to $500, as long as I use a credit card with payment
> protection, but it's probably not safe for my debit card."
I'm not necessary promoting different colors at all! Actually I'd prefer
to supply the information, the user needs to know in an equal way, being
it for domain validated or EV and everything in between. Yellow has
served us well and people got used to it in addition to the small
padlock in the address and status bar. However the needed information,
in order to make a decision, is buried far away, not readily available!
This is my point here!
> I suggest that there's only really one level - "safe for my credit
> card number".
No! Because YOU can't decide what's safe for ME and any other user.
Otherwise if this is what you are saying, I can sue YOU, if you are
going to take the decision for ME and something happens! YOU (the
browser vendor) should display the relevant information the CA has
bothered to include in a digital certificate, in order to allow ME make
a decision what to do with the information I received.
>
> I completely disagree that we should focus on how to give the *most*
> information to the user. *Best*, certainly.
Agreed! Actually there is not so much information included in a digital
certificate anyway, so MOST in this case might be also BEST. However
this is minor issue, once we agree, that information has to be
displayed, instead of painting nice colors!
>> Because valuable information is included in a digital certificates, such
>> as details about the subscriber, issuer and additional notes of the CA.
>> Displaying this information might help to prevent user mistakes and
>> provide indication about the certificates policy etc.
>
> Given that we have difficulty educating users even to look for a
> padlock (although admittedly this has not been pushed hard, at least
> by us, due to the lack of a standard underlying the padlock), I
> suggest that presenting more information is not going to help.
Of course it will! Just by showing the domain name, organization,
locality, state, country and additional notes the CA has included in the
subject line, will help the user and draw attention to it. He might
perhaps receive a pretty good initial indication, if he wants to make
business with this side. Otherwise why include this information in the
first place, if you are going to hide it away!? I didn't say overloaded
information, but currently the Firefox browser isn't providing ANY
information. What does it help to popup "Authenticated by StartCom Ltd."
when hovering over the padlock! Does the casual user know, who StartCom
is? Or Comodo? Or Geotrust? Or...
I want to know who the site operator is, in which country and city he is
registered in. What's he's official name and at last, what kind of
verification he has undergone! This is the important information, not
"Authenticated by...."
>
> Usability suggests that we need to present the minimum information
> necessary for the user to make the decision at hand. The decision we
> are thinking about is "can I put my credit card number into this
> site?". This is a yes/no question, and so a yes/no indicator is most
> appropriate. _Most users do not have the understanding or tools to
> make this decision based on raw certificate data._
>
Exactly! That's why I'm promoting a much better way of displaying the
certificate and issuer details! BTW, EV status might be part of this
information...
> Duane wrote:
>> As usually I've come to the conclusion that mozilla reps are asking for
>> feedback, but don't really care for answers as their minds are either
>> made up, or just don't care.
>
> I certainly care for answers. Of course, I'm not going to be the one
> doing the implementing; I suspect that the decision will be taken by
> Dan Veditz (security) and Mike Beltzner (UI), in consultation with others.
Huuu? So why are the decision makers not involved in this discussion? I
mean, we spend time and effort in order to help and shape an important
part of a security related component (mainly policy wise), if after all
any of our inputs aren't being considered seriously?!? Can you clarify
the decision making process and use of this thread perhaps?
Eddy Nigg (StartCom Ltd.)
>
> On the principle, but perhaps we want different things present by default.
>
for you, than we disagree...
>
> I am not against having optional features that show additional
> information on mouse over. I think "Authenticated by" is optional, and
> means nothing to most users.
>
> It's not my proposal, and has in fact been discussed by people for
> years. The basic idea is that if you go to a site and there is an SSL
> error (expired cert, wrong host error, whatever), instead of a dialog
> box with an OK button you are treated with an error page. There is no
> way to click OK. You can simply not get to the site. This takes the
> likely uninformed user out of the picture.
>
I think this should be considered!
>
> Now, what is there to help me make a decision about the trustworthiness
> of the site, and the possibility of getting law enforcement involved if
> I feel wronged? Just to list some things I could do: check how
> professional the site looks, look at whois information, search for
> opinions from other shoppers, and so on. For new sites there won't be
> much available.
>
Which is not what a casual user would do anyway....none of this!
> Then there's the certificate.
Yes? How should the casual user know ANYTHING about the certificate?
> But with today's domain validation only
> certificates that is not much help.
If you would know, that it's domain validated, than you would KNOW much
more! Or for that matter, any other type of verification performed - and
you'd know about it - would help!
> If they were using EV certificate, I
> would be more confident that they are a real company at least, and I
> could get their real contact information in case of problems.
>
>
Sure, but since you are a casual user (just pretending for a minute) you
would know NOTHING, except that the address bar is green....WOW...
Ka-Ping Yee
> > We will probably arrive at this state if we are at all serious. We need
> > to have a clear definition of "obvious disregard" and the consequences,
> > so the event doesn't become a negotiation.
>
> Well, it's never a negotiation, because we have unilateral power :-)
I wish CAs believed that were the case! I think some of the skepticism
you are encountering in this discussion is skepticism that Verisign and
other CAs will actually feel any pressure. Right now, they have most of
the power and Mozilla has very little, because Verisign has a monopoly
and Mozilla does not. If Mozilla removed Verisign from its root CA list,
its users would probably switch to IE.
When Verisign issues a bogus certificate -- as it has in several cases --
it should suffer real consequences: legal action, financial penalties,
temporary decertification. Users should be made aware if they are
relying on certificates signed by an incompetent CA (e.g. "Warning: the
agency that certifies this site is known to have issued misleading
certificates.") An effective revocation mechanism, temporary or
permanent, for CAs and for individual certificates, would probably help
to some degree.
But, as i said, right now Mozilla doesn't seem to have the power to hold
Verisign accountable for its errors. It would be good to find ways
to hold CAs more accountable. Part of the problem is that the structure
of PKI strengthens monopolies: as a web user, you don't have the option
to choose which CAs you trust. When you go to a bank website, you only
get a signature from a single CA -- take it or leave it. In that
position, you can't exert any competitive pressure on CAs. The power
balance might be different if the SSL protocol turned this around:
browsers and browser users select the CAs they trust, then the browser
tells the website what CAs it will accept and the website must present an
acceptable certificate. This would encourage websites to get certificates
from many CAs, hoping to meet the standards set by the users.
-- ?!ng
Eddy Nigg (StartCom Ltd.)
> But, as i said, right now Mozilla doesn't seem to have the power to hold
> Verisign accountable for its errors. It would be good to find ways
> to hold CAs more accountable. Part of the problem is that the structure
> of PKI strengthens monopolies: as a web user, you don't have the option
> to choose which CAs you trust. When you go to a bank website, you only
> get a signature from a single CA -- take it or leave it. In that
> position, you can't exert any competitive pressure on CAs. The power
> balance might be different if the SSL protocol turned this around:
> browsers and browser users select the CAs they trust, then the browser
> tells the website what CAs it will accept and the website must present an
> acceptable certificate. This would encourage websites to get certificates
> from many CAs, hoping to meet the standards set by the users.
>
>
>
Duane
> The use of SSL in phishing is on the increase.
Where's the proof of your statement? or is this another thought exercise?
Eddy Nigg (StartCom Ltd.)
Here a proposal for this current thread. Anything below is assumed by me
and please correct me if I'm wrong!
As it seems, there isn't an overwhelming support for the green address
bar proposal for EV certificates at this mailing list. The suggestions
and replies are from outright hostility, to severe skepticism to some
lukewarm support the most. Most responses seem to be negative, for
various reasons. In order to improve this situation, I thought to come
up with this proposal:
I assume, that implementation of the greenish thing is meant for Firefox
3, since only bugs and security fixes are performed in between releases.
This give us perhaps some time for the following:
1.) Wait for the CA/ Browser Forum to actually confirm the EV
Guidelines. We are currently discussing a draft which might be changed
still.
2.) Organize a "task group" of interested individuals and parties, which
should discuss and make recommendations and offer various options on
how digital certificates should be presented in the future. Up for
discussion might be every proposal and the groups responsibility would
be to make its recommendation until a certain date.
I could imagine proposals for this group, such as the address bar,
display of information, saving of fingerprints (ssh like), error
behavior and more.
3.) After the dust settles on this discussion and the group would make
its recommendation a decision would be taken also about the EV proposal
(obvious) and an improvement of presentation and handling of digital
certificates in general. The group might consult with the various
developers for feasibility, specially if it would require changes of
the NSS module and of course the UI.
Is this something useful, which might get us a step further?
Duane
> Number of businesses != number of transactions, as I've pointed out
You can point out the same thing over and over, but where is the proof
of your statement?
Sure the top 1% will have a lot of transactions, but the other 99% will
have combined a lot of transactions as well.
> Of course they can. But no jeweller buys a $10,000 diamond for $100,000.
Apples and oranges, if it costs a phisher $10,000 to obtain a EV cert,
and he still makes $100k, then the cost of doing business in this manner
is still worth it.
You aren't dealing with one transaction here, you are dealing with
multiple, so if the dealer buys 1 diamond for $100k, and sells it to
1000 for $10k, he's still in front...
Heikki Toivonen
>> On the principle, but perhaps we want different things present by default.
>>
> Well, obviously, if a green address bar is enough default information
> for you, than we disagree...
I've never said what exactly I want in the UI. Green bar alone is not
enough.
>> If they were using EV certificate, I
>> would be more confident that they are a real company at least, and I
>> could get their real contact information in case of problems.
>>
> Sure, but since you are a casual user (just pretending for a minute) you
> would know NOTHING, except that the address bar is green....WOW...
Green bar alone is not enough, and I don't think anyone has claimed that
alone is enough. I believe even IE7 displays some additional information
(country? company name?), but I haven't actually tried IE7 myself yet so
I don't know for sure.
--
Heikki Toivonen
Duane
> I think it should stop us from covering our UI in green bars and locks
> that are trivial to spoof in content. We know users aren't very good at
> distinguishing chrome from content in the first place, and even my bank
> site looks like a scam--it's got some corny lock gif right there next to
> the form.
What I find amusing is the fact that even after attacks in the wild that
hides the status bar in MSIE and shows an image which fakes the status
bar and lock, they still want a uniform interface to make it easier for
fraudsters to fake in future.
Duane
> Your axe-grinding just makes you more likely to be ignored. These are
> not "Verisign's proposals", spin via The Register notwithstanding.
Just like your axe grinding against Ian?
> If law enforcement is unwilling to prosecute fraud, then all that's left
> is reputation. For reputation, you need to know who you are dealing
> with. EV provides that - even on first contact.
Actually there is a number of high profile examples where reputations
have suffered and the company in question didn't have a certificate at
all, because they outsourced their payment gateway.
Obviously the information already exists and banks and other payment
gateways will handle the payments on behalf of others for a long time to
come.
> 1% (or 20%) of businesses is definitely not the same as 1% (or 20%) of
> _business_. Because not all businesses do an equal amount of business.
proof of these assertions?
> Indeed they have, in the real world. However, there are various things
> about the real world which have no online analog. Primarily, if I visit
> 132, Church Street in London to a particular shop, I have numerous cluse
> from the location and appearance of the shop as to its age and
> trustworthiness. If I buy something from a shop, and it turns out to be
> defective, I am pretty certain of finding that shop again if I return to
> the same address.
So that's where the term fly by nighter comes from...
> Neither of these things are true online. A business set up an hour ago
> can look like one which has been trading for ten years; and a business
> at one address today can be gone tomorrow.
Yes that doesn't happen in the real world at all...
> I am happy to say that preventing another Enron is out of scope for EV.
But you keep mentioning how trustworthy entities with EV certs are,
which is it?
Duane
> surrounding it. The latter is pretty important. If banks, browser
> makers, CAs, consumer advocacy groups and online shops are all saying
Banks... maybe, although they already brand with verisign to try and
convey some kind of trust, but that's mostly a joke because the browser
doesn't show the same imagery.
As for consumer groups, wonder how they feel about small business
discrimination due to price, I know you mentioned price in another
email, however the article you keep rubbishing, and may be out of
context for some things, I think the numbers given are probably a fair
assessment give the criteria etc, 150% more then what verisign currently
charge, I'll assume there is a hefty mark up in there as well, but
still, ~1500 * 1.5 = ~2300$... per year I assume, have to make sure they
are the same company, although with Verisign's position they can
probably skimp, and still charge the same amount...
Robert Sayre
>
> An effective revocation mechanism, temporary or
> permanent, for CAs and for individual certificates, would probably help
> to some degree.
That is a good idea. Perhaps the policy should be to revoke 10,000
individual certificates issued immediately before and after a
known-bogus one. The sites in question will have plenty of warning,
thanks to our open process, and it will bite the CA in the pocket book.
- Rob
Eddy Nigg (StartCom Ltd.)
>> Well, obviously, if a green address bar is enough default information
>> for you, than we disagree...
>>
>
> I've never said what exactly I want in the UI. Green bar alone is not
> enough.
>
>
> Green bar alone is not enough, and I don't think anyone has claimed that
> alone is enough.
> I believe even IE7 displays some additional information
> (country? company name?), but I haven't actually tried IE7 myself yet so
> I don't know for sure.
>
have FF2, so why use IE7 ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
Eddy Nigg <http://www.startcom.org> <eddy...@startcom.org
<mailto:eddy...@startcom.org>>
StartCom Ltd. - StartCom CA - MediaHost (TM)
Duane
> Now is not the time to again bring up my personal issues with various
> proposals which have been made in the past; but I would comment in
> general that often, while proposals have a good understanding of
> security, they have a less than perfect understanding of usability.
My point is, MF isn't willing to work with these groups to come up with
leading security that will benefit everyone, instead MF is more then
willing to work with Verisign.
I saw someone else ask this as well, but my question seems to have been
overlooked by accident, so I'll ask it again.
How many studies, or research is behind the EV proposal so that it
doesn't end up another situation that people associate yellow as being
as good as green in the long term if only a small number of sites
support EV certificates?
Eddy Nigg (StartCom Ltd.)
the CA. Not feasible.
Heikki Toivonen
> For example: _16. Verification of Applicant’s Physical Existence_ might
> be problematic, specially a visit at the premise from the CA point of view.
I actually want the CA to do this check on my behalf. There may be ways
for the CAs to give this task to some local agent to lower the travel
costs. In any case, I would expect the applicant to reimburse the costs
to the CA. It certainly makes the certification more expensive, but I
don't see any ways around that.
> Yes! A new idea for this would be, on a first visit at an SSL enabled
> site to present the user with a window with important and informative
> details. Not a warning popup, but a friendly message, displaying the
> most critical information the CA has bothered to include in the
> certificate. Otherwise why should a CA bother to include this and other
> information, if you have to click through 5 buttons in order to get a
> clue about the subscriber. This is currently specially ridiculous,
> because so much weight is put on the subject line (including EV), when
> the average user, who after all knows how to handle a mouse, never ever
> will actually see it! Think about it!
I am somewhat wary of first-time-only messages, as they are so easily
bypassed/forgotten.
I certainly like to see more information, but I don't know how/where
that information should be presented, nor am I sure how much should be
presented. I think I'd like the full name and address (physical and
web), with a country flag, to be at least partially visible all the time.
>> I suggest that there's only really one level - "safe for my credit
>> card number".
> No! Because YOU can't decide what's safe for ME and any other user.
I think we have to agree to disagree on that. I agree with Gerv that
multiple levels (or no levels at all but presenting the user with all
the information for them to effectively make up their own levels) is too
hard on the users. We (CAs, browser vendors) need to agree on a level
that we think most users will find acceptable for all purposes.
Still, I would like it if the full certificate information was also
available in a more readable format and with fewer mouse clicks than
currently.
One idea that I had, but probably isn't feasible, was to have an SSL
information bar (like the popup blocker) on SSL (or maybe just EV) sites
that would have the company name and address with country flag, and an
advanced button which would display all of the certificate information.
Additional indicators could still be the green bar, with domain name
bolded, the padlock, etc. The obvious problem here is that company name
and address can be really long and not fit...
--
Heikki Toivonen
Gervase Markham
> and we aren't talking about "Jumping to" because MS and Verisign
> invented this new type of cert?
No, they didn't. It was invented by a consortium of CAs and major
browser vendors.
> And aren't "High Assurance" certificates (as they exist now from
> places like Comodo) supposed to be doing the same thing?
Supposedly. However, as Comodo won't tell you exactly what they do to
make it "High Assurance", you can't tell.
> More
> assurances, and higher prices mean nothing, if the browsers don't
> provide a UI for the users to validate the certs (and what those certs
> mean) easily.
What do you mean by "a UI to validate the certs"? What would such a UI do?
> As someone who runs an SSL website, given a choice between the new EV
> certs and the older certs (ignoring price), why bother? I get nothing
> out of it, my users get nothing out of it (except maybe a green bar).
It depends what you are doing on your SSL website. If you need people to
find your site via a search engine and then immediately trust you with
their credit card number, it may well be what you want. If you don't, it
may not.
> Remember there are least 2 Free CAs listening and contributing on this
> list, that means monetary barriers (assuming a steep price from
> Verisign) won't be an issue for phishers.
EV is not designed to exclude phishers by high monetary prices. Whatever
the price is, it's a side-effect of the need to do additional validation
- which is the barrier. A phisher either has to give away information
about himself, of expend a lot of money spoofing the various indicators
and sources that the CA uses to cross-check. If he does the former, he
can be arrested. If he does the latter, he won't get a return on his
"investment".
Gerv
Robert Sayre
>
> An effective revocation mechanism, temporary or
> permanent, for CAs and for individual certificates, would probably help
> to some degree.
That is a good idea. Perhaps the policy should be to revoke 10,000
individual certificates issued immediately before and after a
known-bogus one. The sites in question will have plenty of warning,
thanks to our open process, and it will bite the CA in the pocket book.
- Rob
Ka-Ping Yee
> What I find amusing is the fact that even after attacks in the wild that
> hides the status bar in MSIE and shows an image which fakes the status
> bar and lock, they still want a uniform interface to make it easier for
> fraudsters to fake in future.
I think some degree of uniformity in the user interface is good.
For example, users need to be able to distinguish trustworthy UI
(chrome) from untrustworthy UI (content), and ideally we should
standardize on a task that they only have to learn once.
This is not to say the UIs have to look identical -- as Passpet shows,
i think personalization can play a big part in trustworthy UI -- but
the user shouldn't have to learn lots of different schemes.
At a more general level, though, i agree with you: my intuition is
that the chrome problem (a.k.a. "trusted path") is probably more
significant than the certificate verification problem, and needs
some more attention.
-- ?!ng
Ka-Ping Yee
> An effective revocation mechanism, temporary or permanent, for CAs
> and for individual certificates, would probably help to some degree.
On Tue, 7 Nov 2006, Eddy Nigg (StartCom Ltd.) wrote:
> I'm afraid, but this isn't something the browser vendor controls, only
> the CA. Not feasible.
But if certificate revocation is going to work, doesn't it have to be
implemented by the browser? Couldn't there be a role for Mozilla to
play here?
-- ?!ng