EV guidelines
Ben Bucksch
Basics: SSL certificates are supposed to ensure the identity of the one you talk to. One reason is to make the crypto meaningful (a MITM attack is still possible with SSL, if the middleman uses his own cert and the client accepts it as real). The other reason is to connect online business to real world business - if you buy at a store, and give your credit card data, you want to know it's not going to Russia, but to a real company, and that you can sue them, if they don't deliver.
Note that SSL certificates say nothing about the trustworthiness or similar, just verify identity.
Problem: GeoTrust and a few other companies started selling cheap certificates which are issued automatically (no human involved) and only check whether the applicant has control over the domain (or email address) that the certificate is to be issued for. These are called "domain control verification" or DV certs. The "holder's name" field in the certificate does not get verified *at all* and is thus useless with these certs - it either equals domain name or can be simply lying, despite being signed by the CA. Given that, these new cert types pose a significant problem to business on the web, and make phisher's life easy (if phishers even bother with SSL or certs).
EV solution by the "CA/Browser Forum": A bunch of CAs came up with a proposal of a new cert standard. Mainly, it mandates the checks that the CA has to do to verify the certificate holder. They are intended to be sold to high-profile sites like eBay.com, and cost $1000/year upwards. So, one obvious reason for EV is that CAs want to charge more money from the customers that make a lot of money on the web. It does increase the level of vetting substantially, and it's definitely a huge improvement over status quo. So, browser and browser users also gain from it. For Microsoft, it's actually part of an anti-phishing initiate, MSIE was supposed to make the URLbar green for some sites, and EV was one mandatory criteria for that (there are other criteria as well, e.g. anti-phishing blacklists etc.).
The "CA/Browser Forum" consists out of all major browser vendors, including Microsoft, Mozilla Foundation, KDE (Konqueror), and Opera (Apple is missing). Most of the big Cas are on it as well.
The current guidelines are at <http://www.cabforum.org/EV_Certificate_Guidelines.pdf>. It's 70-100 pages in lawyer language.
My comments:
Don't be followed by the language and length, though. "Qualified Independent Information Sources" could probably simply be a phonebook, and a "site audit" is a clerk looking at the sign on the street and peeking in the lobby. That's not what *I* would call an "audit".
The "phone number verification" happens by calling the number and seeing who answers (Me at 0900-123456: "Microsoft, how can I help you?") (16(b)(2)(A)+(C)). So, I could apply as Microsoft, supply them my number, answer as Microsoft, and that's the verification. To top it, this number can then be used to verify the signature, with "a response from someone who identifies themselves as such person confirming that he/she did sign the applicable document". Maybe I have overlooked something, but I could give them the address of eBay, or my address with an eBay sign, and *my* phone number, sign the doc, and then when they call me, greet with "Ben Bucksch of eBay speaking" and confirm that I am a "Contract Signer" who is allowed to represent eBay and I did indeed sign the doc. huh?
This whole thing has lots of loopholes. Given the experience and market pressures, we have to assume that the CAs use the absolute minimum and cheapest standards that still pass the guidelines, and they'll automate as much as possible.
Also, there are really heavy statements in there, e.g. the liability (37(a); see also <https://financialcryptography.com/mt/archives/000862.html>: If the CA followes the EV guidelines and the user gets ripped off, the CA is not liable at all - be it due to hole in the guidelines or other reasons. Even worse, though, if the CA *fails* to follow the guidelines, and the user gets ripped of *because of that*, the liability of the CA is limited to $2000 - not even per case, per cert/CA customer. Even a single normal phishing incident is easily higher than that. That's particularly sobering considering that a cert *costs* $1000-2000 - that means I could set up a CA and sell certs to everybody including the mafia and not verify certs *at all*, and even pay all liability (per EV guideline doc) and still make a profit for my few valid customers. Sorry, how does that help users *at all*? IMHO, this should be backed by $10-100 million insurances - per incident. Even an average $100 UPS comes with $100,000 insurances.
My alternative proposal:
(most important part of posting)
We need to connect online business with real world business. I want to have somebody to sue - who won't vanish when poked at. And I want that the info in the cert is actually correct.
I really thing that every CA-issued certificate must be verified using the following steps:
- Using the official state register of companies to verify company name and representing natural person
- Acquiring written signature (original) of that person
- Checking the signature against the ID card / passport of that person
It should be cheap enough, *esp.* so for $1000/year EV certs. In Germany, if you want to mail-rent (Netflix-alike) 18+ movies (including Van Helsing), you have to pass harder verification steps than EV. You actually have to walk to the post office, which has a service to verify your identity card and send the result back to the requester. It costs 10 Eur, once. In fact, my grocery store not only asks for my signature for every purchase, they even double-check the signature against my ID card every time! (Apart from the people who already know me.) If a grocery store clerk can do it for a $10 purchase, a CA can do it for a $1000/year cert which is backing up $ x00 million business for tens of thousands of users.
People have said that not every US citizen has a passport. But they can get one. This is about ensuring something to users, after all.
Note that I think that natural persons and small companies should also be able to get an EV cert, from the start.
UI proposal:
We could e.g. then show the cert holder name next to the domain name in the urlbar, so that the real world name is a trust root, in addition to the domain.
That would be something most users can more easily relate to than the domain name system, which is logical, but literally backwards.
However, the real world company name may then be just as much a phishing target as the domain name is now. We'll not only have international character sets (compare IDN), which we can't easily escape from as we did with domains, but there'll be another class of attack of similar seeming company names, e.g. is Shell Books a subsidary of Shell Oil Company or not or is "e Bay Auctioners, Inc." a part of eBay?
UI: Green urlbar, as maybe done by MSIE:
http://it.slashdot.org/article.pl?sid=07/01/26/1325228
"Stanford University and Microsoft Research have published a study that claims that the new Extended Validation SSL Certificates in IE7 are ineffective (PDF). The study, based on user testing, found that EV certificates don't improve users' ability to detect attacks, that the interface can be spoofed, and that training users actually decreases their ability to detect attacks. The study will be presented at Usable Security 2007 next month, which is a little late now that the new certificates are already being issued."
Study done in Sept 2006 and I found the setup (training etc.) highly questionable, but the only conclusion one can draw is that the green bar increased people's trust in websites - ironically real and fraudulent alike! (no matter if green bar or not)
So, if one can believe the study, the green bar is a really bad idea.
-- When responding via mail, please remove the ".news" from the email address.
Ben Bucksch
to make CAs liable for any business that goes wrong and it cannot be
sorted out with the cert holder, either because he cannot be reached or
sued or the company cannot pay the money that the court ordered it to.
Then, suddenly, the CAs have very strong incentive to be checking very
well, including financial records, and are able to balance the checking
costs vs. damage themselves. In *that* case, it would actually make
sense to also show the CAs name to the user, because the CA provides
actual value/security for the user.
If the goal is to really improve the reputation of online business
substantially, we could go even further.
Heikki Toivonen
> People have said that not every US citizen has a passport. But they can
> get one. This is about ensuring something to users, after all.
Actually, several million US citizens can not get a passport. I can't
find the actual article I read, but I saw it linked from reddit or digg
or some such in the last week or so. However, one example I found was if
you are more than $5000 behind in child support payments:
http://www.metnews.com/articles/euni022502.htm. I am pretty sure these
people can still start companies.
--
Heikki Toivonen
Ben Bucksch
> Actually, several million US citizens can not get a passport. I can't
> find the actual article I read, but I saw it linked from reddit or digg
> or some such in the last week or so. However, one example I found was if
> you are more than $5000 behind in child support payments:
> http://www.metnews.com/articles/euni022502.htm. I am pretty sure these
> people can still start companies.
Are that people we want to give high assurance certs to?
Somebody being convicted for refusing to sing the national hymn in
school and then not being allowed to get a passport due to being a
"criminal" is one thing (I don't think that happens in the US, even
former criminals can get a passport). But somebody not fulfilling
financial duties is another, that actually is kind-of relevant.
And it's not like we'll require EV to set up a website or something.
Again, we need to ensure something to users. If people didn't bother to
get passports, and now can't get one due to some strange US laws, and
now want to be the CEO of a company, and want to get EV, they may be out
of luck. Note that it's only the CEO *or* other registered
representative (and maybe admin, depends on scheme) who needs to provide
the passport.
Gervase Markham
Some comments on your post. Please understand that I'm not being
defensive about EV, or claiming that it's perfect - I just want to test
your arguments a little bit.
Ben Bucksch wrote:
> EV solution by the "CA/Browser Forum": A bunch of CAs came up with a
> proposal of a new cert standard. Mainly, it mandates the checks that the
> CA has to do to verify the certificate holder. They are intended to be
> sold to high-profile sites like eBay.com, and cost $1000/year upwards.
Just to be clear: They are not _intended_ to cost $1000/year upwards;
the CAB Forum had no discussions on and makes no mandates about pricing.
(That would fall foul of antitrust law.) However, that seems to have
been the average price at which CAs have launched the new certs.
> Don't be followed by the language and length, though. "Qualified
> Independent Information Sources" could probably simply be a phonebook,
> and a "site audit" is a clerk looking at the sign on the street and
> peeking in the lobby. That's not what *I* would call an "audit".
Right. But how many phishers have an office with a street sign saying
"eBay" and a lobby?
> The "phone number verification" happens by calling the number and seeing
> who answers (Me at 0900-123456: "Microsoft, how can I help you?")
> (16(b)(2)(A)+(C)). So, I could apply as Microsoft, supply them my
> number, answer as Microsoft, and that's the verification.
Except you can't, because there won't be any information sources which
confirm that your number belongs to Microsoft. Because it doesn't.
> To top it,
> this number can then be used to verify the signature, with "a response
> from someone who identifies themselves as such person confirming that
> he/she did sign the applicable document".
I think you misunderstand the purpose of this step. It's to make sure
that a rogue employee doesn't apply for a certificate using the name of
someone else at the company who would be authorised to make the
application.
> Maybe I have overlooked
> something, but I could give them the address of eBay, or my address with
> an eBay sign,
I don't think any information source would confirm that your address
belonged to eBay.
> This whole thing has lots of loopholes. Given the experience and market
> pressures, we have to assume that the CAs use the absolute minimum and
> cheapest standards that still pass the guidelines, and they'll automate
> as much as possible.
That's certainly true. However, it's also true that the advantage of a
written standard is that it can be updated in response to new threats.
So if, for example, someone gets an EV cert and uses it for phishing, we
can analyse how they did it and tighten up the guidelines to close the
loophole. With the previous, different-with-every-CA, ad-hoc procedures,
that sort of thing wouldn't have been possible.
> Also, there are really heavy statements in there, e.g. the liability
> (37(a); see also
> <https://financialcryptography.com/mt/archives/000862.html>: If the CA
> followes the EV guidelines and the user gets ripped off, the CA is not
> liable at all - be it due to hole in the guidelines or other reasons.
Is this a change from how things work currently?
> Even worse, though, if the CA *fails* to follow the guidelines, and the
> user gets ripped of *because of that*, the liability of the CA is
> limited to $2000 - not even per case, per cert/CA customer.
it says "$2000 per Subscriber or Relying Party per EV Certificate". This
means that if ten people are ripped off, they can claim $2000 each.
However, I agree that this is a little bit low.
> Even a
> single normal phishing incident is easily higher than that. That's
> particularly sobering considering that a cert *costs* $1000-2000 - that
> means I could set up a CA and sell certs to everybody including the
> mafia and not verify certs *at all*,
Except that you wouldn't pass the Webtrust EV audit and no browsers
would EV-enable your root (if it even got in in the first place).
> We need to connect online business with real world business. I want to
> have somebody to sue - who won't vanish when poked at. And I want that
> the info in the cert is actually correct.
>
> I really thing that every CA-issued certificate must be verified using
> the following steps:
Just to check: you mean _every_ CA-issued certificate? If so, you need
to propose a way to get from where we are now to the place you want to be.
Say we wrote our own guidelines, and said to all the CAs "unless every
cert you issue meets these, we'll yank your root". Who do you think
would blink first?
> 1. Using the official state register of companies to verify company
> name and representing natural person
What about issuing certs to people or organisations which aren't companies?
What about countries where there is no such register, or it's unreliable?
> 2. Acquiring written signature (original) of that person
> 3. Checking the signature against the ID card / passport of that person
One draft of a precursor document to the EV guidelines included a
requirement for a site visit, and that you had to meet up with the
applicant and take a photo of them with their government issued ID, and
record the number thereon. I still think this was a great idea, but
unfortunately I was not in a majority.
> This, and pretty much only this, will ensure that the card holder really
> is who he claims to be, in real life, as seen by the government and
> courts. Thus, before EV, I assumed that the above is performed for the
> $100/year certs.
Really? There's no way any CA could make money doing this at $100 a
cert. In the US, there are networks of companies which will do site
visits and this sort of verification for you, but in other countries,
there aren't. Such a visit would cost several hundred dollars to have
performed.
> Note that I think that natural persons and small companies should also
> be able to get an EV cert, from the start.
But then how can your step 1), above, work?
> We could e.g. then show the cert holder name next to the domain name in
> the urlbar, so that the real world name is a trust root, in addition to
> the domain.
Their legal business name? Or their "trading as" name? Or the real name
of the person at the company who made the application?
> However, the real world company name may then be just as much a phishing
> target as the domain name is now. We'll not only have international
> character sets (compare IDN), which we can't easily escape from as we
> did with domains, but there'll be another class of attack of similar
> seeming company names, e.g. is Shell Books a subsidary of Shell Oil
> Company or not or is "e Bay Auctioners, Inc." a part of eBay?
Indeed. There's no substitute for a pair of human eyes on each
application - which I believe EV requires (section 24).
Gerv
Florian Weimer
> We need to connect online business with real world business. I want to
> have somebody to sue - who won't vanish when poked at. And I want that
> the info in the cert is actually correct.
>
> I really thing that every CA-issued certificate must be verified using
> the following steps:
>
> 1. Using the official state register of companies to verify company
> name and representing natural person
I don't think the register of companies is useful for this purpose.
Anyone can get on it.
> 2. Acquiring written signature (original) of that person
Not very useful in itself.
> 3. Checking the signature against the ID card / passport of that person
Good fake passports are usually cheaper than government-issued ones.
> This, and pretty much only this, will ensure that the card holder
> really is who he claims to be, in real life, as seen by the government
> and courts. Thus, before EV, I assumed that the above is performed for
> the $100/year certs.
Part of the reason for the price drop was that there were so few
impersonation attacks against CAs. Experience tells that there is
close to zero risk for the CA, so it does not make sense to spend
money on better checks. There is simply no liability you need to
shift. I don't see why this is going to change with EV certificates.
And since there are so few attacks, we haven't got a good threat
model, either.
Personally, I think that in order to make a difference, EV
certificates must verify not only that the certificate holder is in
control of embedded domain names (the usual EV CPS is basically
equivalent to domain-control certificates in this area), but also that
the certificate holder has got all the relevant trademark rights.
Wildcard certificates would probably have to go, too.
Duane
> Personally, I think that in order to make a difference, EV
> certificates must verify not only that the certificate holder is in
> control of embedded domain names (the usual EV CPS is basically
> equivalent to domain-control certificates in this area), but also that
> the certificate holder has got all the relevant trademark rights.
> Wildcard certificates would probably have to go, too.
Certificates with subjectAltName extensions should be able to replace
wild card certificates, the question is what checks should be applied to
hostnames?
Most banks and other large entities have a list of hostnames as long as
my arm for load balancing and other valid reasons, most often look
deceptive in my opinion, and almost phishing like in some cases.
--
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."
Ben Bucksch
> Some comments on your post. Please understand that I'm not being
> defensive about EV, or claiming that it's perfect - I just want to
> test your arguments a little bit.
OK. My thought is that we don't have many chances to push things like
that and have users consider it. If we make them aware of it, it better
be bulletproof, or we should not bother them with it, just treat it as
little better SSL cert, no special treatment.
> Right. But how many phishers have an office with a street sign saying
> "eBay" and a lobby?
> ...
> Except you can't, because there won't be any information sources which
> confirm that your number belongs to Microsoft. Because it doesn't.
> ...
> I don't think any information source would confirm that your address
> belonged to eBay.
Reliable sources like the phonebook or a random commercial database?
You are, and the CAs writing the guidelines are, not assuming that the
procedures are specifically gamed, things so arranged that the malicious
applicant would pass them, including renting a fake office with sign,
putting up fake phone numbers and listening them for a few days or
weeks, or specifically targetting the commercial database(s) that the CA
uses to get your bad info in there. Esp. the latter is probably
trivially easy, because the commercial databases are not security shops,
just providing contact info for initiating business. Esp. so in the US,
from what I've heard.
Whole subject of social engineering. Compare how easy it was (and still
is!) to get a random person's phone records from their own telco, if you
simply call the telco and claim to be police, father, whatever.
Similarly, I can just call my telco (from any number) and change the
bank account, billing name (!) and address, almost any data.
The CAs and guidelines (and you) don't take social engineering and
similar into account. Big error. That's what I'm pointing out.
That's why there needs to be something that can't be faked, or has a
very well-known and established risk (even when considering fraud), e.g.
a hand-written signature that has been checked.
>> To top it, this number can then be used to verify the signature, with
>> "a response from someone who identifies themselves as such person
>> confirming that he/she did sign the applicable document".
>
> I think you misunderstand the purpose of this step. It's to make sure
> that a rogue employee doesn't apply for a certificate using the name
> of someone else at the company who would be authorised to make the
> application.
I don't know how you read that out "confirming that he/she did sign the
applicable document".
>> If the CA followes the EV guidelines and the user gets ripped off,
>> the CA is not liable at all - be it due to hole in the guidelines or
>> other reasons.
One example: Let's say the guideline requires checking the signature.
The CA has a record saying that they checked it. But the signature was
still faked, and quite obviously so. Who's to blame? With this rule: the
browser user. Although clearly the CA is to blame, and needs to take
responsibility for its own failure.
Thus: the CA needs to take liability, if they issue bad certs, no matter
which procedure they followed, no matter the situation. Then they
actually have financial incentive to check thoroughly, instead of
checking as little as possible to sell as much as possible.
> So if, for example, someone gets an EV cert and uses it for phishing,
> we can analyse how they did it and tighten up the guidelines to close
> the loophole.
You think this will happen, and implemented, timely (days to weeks, not
months)? I don't think so.
>> I really thing that every CA-issued certificate must be verified
>> using the following steps:
>
> Just to check: you mean _every_ CA-issued certificate?
Yes. Or rather, every CA customer. The CEO can delegate to one or more
managers or admins, and that admin can then get a digital signature, and
with that the admin can create new certs on the fly automatically
without any paperwork, issued immediately.
> Say we wrote our own guidelines, and said to all the CAs "unless every
> cert you issue meets these, we'll yank your root". Who do you think
> would blink first?
Given that nothing breaks anymore, we have no need to blink.
And I don't think we can put up US banks as good example for users
either, so we don't even need to care about them being "approved".
>> 1. Using the official state register of companies to verify company
>> name and representing natural person
>
> What about issuing certs to people or organisations which aren't
> companies?
See below. Natural persons have a passport and can get a cert in their
own name.
Organisations which have no legal body or no money backing won't get
one, because they can't uphold "when poked at". If this is about
organisations like open source projects, or tiny business like mine, the
project leader would need to get one in his own name. FWIW, I am legally
required to publish my name, address and phone number on my website
anyways (German law for professional publishing, for accountability -
no, private blogs and co don't fall under that).
> What about countries where there is no such register, or it's unreliable?
Example?
I guess we'd have to see how things work there, how they can be made
reliably based on their customs. In a few countries, Africa maybe, this
may not be possible, but we don't want the Nigerian scammer to get an EV
cert, do we?
>> 2. Acquiring written signature (original) of that person
>> 3. Checking the signature against the ID card / passport of that
>> person
>
> One draft of a precursor document to the EV guidelines included a
> requirement for a site visit, and that you had to meet up with the
> applicant and take a photo of them with their government issued ID,
> and record the number thereon. I still think this was a great idea,
> but unfortunately I was not in a majority.
Right!
Well, who cares about majority when we're facing 25 CAs? You said we
effectively have a veto right, so...
why blink? :-)
:-) still smiling, not blinking.
>> This, and pretty much only this, will ensure that the card holder
>> really is who he claims to be, in real life, as seen by the
>> government and courts. Thus, before EV, I assumed that the above is
>> performed for the $100/year certs.
>
> Really? There's no way any CA could make money doing this at $100 a cert.
Nonsense. Sorry, that's just CA margin-improving nonsense.
First, they make $100 (per year, per cert) for that action (once, per
customer). And it's $1000 now with EV.
As I said, exactly this is offered as service in Germany for 10 Eur,
one-time fee. If they can make a site visit, they can also look at a
personal ID card and check a signature. My grocery store does it! What
gives?
> In the US, there are networks of companies which will do site visits
> and this sort of verification for you, but in other countries, there
> aren't. Such a visit would cost several hundred dollars to have performed.
Nobody's forcing them to have a flat world-wide fee. In fact, lots of
things will be different in many countries, out of necessity, even with
EV as-is.
>> Note that I think that natural persons and small companies should
>> also be able to get an EV cert, from the start.
>
> But then how can your step 1), above, work?
Well, it would of course not be necessary to associate applying company
with a natural person, because we already have a natural person with
signature and papers.
>> We could e.g. then show the cert holder name next to the domain name
>> in the urlbar, so that the real world name is a trust root, in
>> addition to the domain.
>
> Their legal business name? Or their "trading as" name? Or the real
> name of the person at the company who made the application?
I don't know. I'd say the legal business name - "trading as" would be a
different field.
I'm not familiar with the differentiation, because it does not exist in
Germany, or rather is not important. I am 'trading as' "Beonex", but I
am legally "Ben Bucksch", and I *have* to say the latter in any official
communication. Beonex is just a nickname. In my case, the cert for
Beonex would need to say "Ben Bucksch", because that's the only legal
entity that exists. You cannot sue Beonex, only me.
Thanks,
Ben
Ben Bucksch
> I don't think the register of companies is useful for this purpose.
> Anyone can get on it.
>
Sure you can get on it, but under which name? You can't incorporate
"eBay GmbH" in Germany, because there's already a company in that name,
nor "eBay Internet Services GmbH" or whatever you make up.
> Good fake passports are usually cheaper than government-issued ones.
>
For German passports? Please tell me suppliers :).
(Beloved government agency of any kind: This was a joke, or rather
purely out of interest.)
> Experience tells that there is
> close to zero risk for the CA, so it does not make sense to spend
> money on better checks.
Fine, if they think so, let them bet their money on it. *Their* money,
not that of others.
> And since there are so few attacks, we haven't got a good threat
> model, either.
>
I posted a threat model a year or longer ago on n.p.m.crypto. S/MIME is
pretty much useless due to the free, automatically issued certs. Read
there for details.
> Personally, I think that in order to make a difference, EV
> certificates must verify not only that the certificate holder is in
> control of embedded domain names (the usual EV CPS is basically
> equivalent to domain-control certificates in this area), but also that
> the certificate holder has got all the relevant trademark rights.
>
Makes sense. Add fair checks to the requirements as you want, but those
3 I mentioned are the minimum, IMHO.
Boris Zbarsky
> See below. Natural persons have a passport
As pointed out several times now, this is not strictly true.
Unless by "passport" you mean "some sort of government-issued ID".
A "passport" is a "government-issued ID that allows you to leave the country no
questions asked", which is why some people cannot get one. ;)
-Boris
Florian Weimer
> replace wild card certificates, the question is what checks should
> be applied to hostnames?
>
> Most banks and other large entities have a list of hostnames as long
> as my arm for load balancing and other valid reasons, most often
> look deceptive in my opinion, and almost phishing like in some
> cases.
Host names like c1d3q2 are fine, but you shouldn't be allowed to use a
well-known or registered trademark. If I read the Verisign CPS
correctly, I would be able to obtain a EV certificate for
citibank.enyo.de if I incorporated. Given that it's not too hard to
set up a phony company, this undermines the purpose of EV
certificates, doesn't it? After all, it's not about validation, it's
about identification.
Ben Bucksch
> Host names like c1d3q2 are fine, but you shouldn't be allowed to use a
> well-known or registered trademark. If I read the Verisign CPS
> correctly, I would be able to obtain a EV certificate for
> citibank.enyo.de if I incorporated.
Right, that's the current phishing approach. It's not trivial to stop,
though. There are phoney generic trademarks, too, so you'd basically
shrink the namespace for (readable) hostnames to almost null.
> Given that it's not too hard to
> set up a phony company, this undermines the purpose of EV
> certificates, doesn't it? After all, it's not about validation, it's
> about identification.
Well, the cert would say "Enyo GmbH". Assuming the user looks at that
(we should not discuss UI here, but let's say it's shown in or near the
URLbar). But you're right, a typical phishing victim could just as
easily confused, given that they happily enter their bank login at
http://64.246.35.72/phase3/citibank.html
Florian Weimer
> Huuu? Got this dropped? It used to be in the guidelines!? Well, if
> this is the case, then it's not even worth considering the EV certs
> anything else than Class 2. The site visit was also the major expense
> for the CA I predicted....
According to my reading of Verisign's CPS, the site visit is not
required if the applicant can prove that it's incorporated at the
given address.
Ben Bucksch
> There is something I'm missing here...
Indeed. The link to the published EV guidelines in my original post.
(Did I mention they are *public* now? For everybody!)
Florian Weimer
>> According to my reading of Verisign's CPS, the site visit is not
>> required if the applicant can prove that it's incorporated at the
>> given address.
> Mmmhh, may I ask, what exactly has the Verisign CPS to do with the EV
> guidelines?
I was under the impression that the EV appndexi of the Verisign CPS
implements the EV guidelines.
Ben Bucksch
> Ben Bucksch wrote:
>> See below. Natural persons have a passport
>
> As pointed out several times now, this is not strictly true.
I argued that
* the difference is not serious in this case. It may actually be
relevant (if you don't pay for your children, you don't fulfill
your financial duties and probably shouldn't get EV), and it has
workarounds (only *new* passports won't be issued, and there may
be a vice president or whatever registered as representative which
can jump in).
* we *need* it to make the identification secure enough.
> Unless by "passport" you mean "some sort of government-issued ID".
Some *secure* government-issued ID, yes. That's what I meant with
"passport". German ID cards count, German driver's licenses don't, and
US driver's licenses don't.
And the rules may have to be adapted somewhat per country anyways,
because things may be different in some country. Just like there's a US
speciality to deny people a passport, there may be completely different
specialities (related to different points in EV) in other countries.
Ben Bucksch
SSL / use-cases", I should state that:
I consider only the use-case of webshops and normal business for EV.
That's why I emphasize "can sue" so much. I do not consider private
communication (email, chat, forum), because I don't think the notion of
real world identity is even significant (see the other post for reasons).
Florian Weimer
> if the EV guidelines require a site visit
They don't, as far as I can tell. Evidence provided by a Qualified
Indepedent Information Source (QIIS) is usually sufficent. Verisign
seems to have copied this part of the guidelines verbatim.
Now the interesting question is how much wiggle room there is in the
definition of a QIIS. Looks like a lot to me, and I wouldn't be
surprised if anyone had problems to say with certainty if certain
WHOIS operators can serve as a QIIS.
By the way, much of this could be sidestepped if CAs were required to
publish all the evidence they have gathered together with the EV
certificates they issue (in a complete list of certificates, not just
those certificates that are actually used on popular sites). This
way, everyone could review the strength of each CA's EV process. The
peer pressure should be sufficient to ensure that everyone keeps their
backyards clean.
> EV is already flawed by the biggest certification authority
Is the current certificate on https://www.verisign.com/ an EV
certificate? It lacks a physical address, which is required by (my
reading of) the guidelines.
Florian Weimer
>> Is the current certificate on https://www.verisign.com/ an EV
>> certificate? It lacks a physical address, which is required by (my
>> reading of) the guidelines.
>>
> Good catch!
Hmm, street address seems to be optional after all. But I don't quite
understand why the certificate says both Wilmington and Mountain View.
> More than that, it was signed and issued long before the EV
> guidelines were approved (How could they know what the guidelines
> will be?).
Have they been approved yet? The cabforum.org web site is unclear.
> And even more disturbing is the fact, that the certificate is valid
> for a period of _two_ years, whereas the guidelines speak strictly
> about _ONE_ year only!!!!
Uhm, a maximum of 27 months is permitted.
> And now to all the EV supporters:
> Isn't EV already flawed by the biggest certification authority?
My question to the EV opponents: Can't you continue to offer
domain-validated certificates? 8-)
Florian Weimer
> Certain is good....hasn't Verisign its own domain registry department?
> Conflict of interest?
The guidelines explicitly forbids that they use themselves as a QIIS.
(Which makes it kind of interesting how you issue your own
certificate.)
But everyone else could still use Verisign-provided WHOIS information
as a QIIS, I guess.
Ben Bucksch
> The guidelines explicitly forbids that they use themselves as a QIIS.
> (Which makes it kind of interesting how you issue your own
> certificate.)
>
I guess you have to look yourself up in the phonebook. (And discover how
outdated/wrong it is.)
Ben Bucksch
> The guidelines explicitly forbids that they use themselves as a QIIS.
> (Which makes it kind of interesting how you issue your own
> certificate.)
>
I guess you have to look yourself up in the phonebook. (And discover how
outdated/wrong it is.)
--
Gervase Markham
> OK. My thought is that we don't have many chances to push things like
> that and have users consider it. If we make them aware of it, it better
> be bulletproof, or we should not bother them with it, just treat it as
> little better SSL cert, no special treatment.
You're absolutely right. Educating users is an enormous effort. That's
why I think whatever UI we choose (green bar, not green bar, whatever)
should be decoupled from the underlying enabling technology (EV, DNSSec,
phishing blacklist, whatever) we use to run it. That way, we only have
to educate users once.
>> Right. But how many phishers have an office with a street sign saying
>> "eBay" and a lobby?
>> ...
>> Except you can't, because there won't be any information sources which
>> confirm that your number belongs to Microsoft. Because it doesn't.
>> ...
>> I don't think any information source would confirm that your address
>> belonged to eBay.
>
> Reliable sources like the phonebook or a random commercial database?
Do you have access to change either of those to associate your address
with eBay?
Remember, of course, the phisher does not know which sources the CA is
going to use. Those are (reasonably enough) kept confidential.
> You are, and the CAs writing the guidelines are, not assuming that the
> procedures are specifically gamed, things so arranged that the malicious
> applicant would pass them, including renting a fake office with sign,
> putting up fake phone numbers and listening them for a few days or
> weeks, or specifically targetting the commercial database(s) that the CA
> uses to get your bad info in there. Esp. the latter is probably
> trivially easy, because the commercial databases are not security shops,
> just providing contact info for initiating business. Esp. so in the US,
> from what I've heard.
Yes, what you say about renting a fake office is possible. But think for
a moment - if everyone who wanted to set up a phishing site had to do
that, how much less phishing would there be?
People who rent offices leave a paper trail - they have to show their
face, leave deposits and bank details, people remember them. You can't
do all of this anonymously from Russia any more.
> The CAs and guidelines (and you) don't take social engineering and
> similar into account. Big error. That's what I'm pointing out.
I think they do - that's why there are lots of different checks and they
all have to come back consistent with each other.
But let me turn the question around: if "social engineering" means you
can't trust what anyone says about anything, how do you establish
anything to be true?
> That's why there needs to be something that can't be faked, or has a
> very well-known and established risk (even when considering fraud), e.g.
> a hand-written signature that has been checked.
Checked against what? Couldn't that thing have been "socially
engineered" too? :-)
>>> To top it, this number can then be used to verify the signature, with
>>> "a response from someone who identifies themselves as such person
>>> confirming that he/she did sign the applicable document".
>>
>> I think you misunderstand the purpose of this step. It's to make sure
>> that a rogue employee doesn't apply for a certificate using the name
>> of someone else at the company who would be authorised to make the
>> application.
>
> I don't know how you read that out "confirming that he/she did sign the
> applicable document".
Joe Bloggs in the mail room at BigCorp has been bribed by a phisher to
intercept a few bits of mail so he can get an EV cert to spoof BigCorp.
However, Joe Bloggs isn't authorised to apply for EV certs under the
rules, so the phisher fakes the request as being from Fred Smith, their
CIO. The request is filed, and Joe intercepts the relevant mail.
However, Foo CA rings BigCorp, talks to Fred Smith and finds he never
signed the application, so it's rejected.
Something like that. Basically, you need to make sure that the person
who signed the application actually exists and did sign the application.
I can't quite see how you object to that check :-) It doesn't help with
the problems you are particularly concerned about, but it's not meant to.
> One example: Let's say the guideline requires checking the signature.
> The CA has a record saying that they checked it. But the signature was
> still faked, and quite obviously so. Who's to blame? With this rule: the
> browser user.
Well, presumably a court would decide that. But it could be that a
higher level of liability is needed to make it cost-effective to go
through the courts.
> Thus: the CA needs to take liability, if they issue bad certs, no matter
> which procedure they followed, no matter the situation.
What do you mean by "bad certs"? Do you mean "certs subsequently used
for fraud"?
An EV cert does not speak to the trustworthiness of the person who owns
it. (We've been through this before.) It just means we know enough about
the person to collar them if they use it for fraud.
Say a business is legitimate, gets an EV cert, then six months later
goes rogue and starts ripping people off. Is the CA responsible? What if
it's two months? Or two days?
>> So if, for example, someone gets an EV cert and uses it for phishing,
>> we can analyse how they did it and tighten up the guidelines to close
>> the loophole.
>
> You think this will happen, and implemented, timely (days to weeks, not
> months)? I don't think so.
That's part of the point of having a standard. It might take weeks or
months to update the standard, but I suspect CAs will be "unofficially"
looking out for the same tricks immediately. They don't want to be
landed with the liability and bad publicity.
Unqualified scepticism without rationale isn't really very helpful in
moving forward the discussion.
>>> I really thing that every CA-issued certificate must be verified
>>> using the following steps:
>>
>> Just to check: you mean _every_ CA-issued certificate?
>
> Yes. Or rather, every CA customer. The CEO can delegate to one or more
> managers or admins, and that admin can then get a digital signature, and
> with that the admin can create new certs on the fly automatically
> without any paperwork, issued immediately.
To be even more explicit: you definitely mean "every CA-issued
certificate", rather than "every *EV* certificate"?
Sadly, I don't think we can single-handedly transform the workings of
the certificate market merely by decreeing that it be so.
>> Say we wrote our own guidelines, and said to all the CAs "unless every
>> cert you issue meets these, we'll yank your root". Who do you think
>> would blink first?
>
> Given that nothing breaks anymore, we have no need to blink.
What do you mean by "nothing breaks"? If we are talking about *every*
certificate, then for non-EV ones, all we can do if they tell us to get
stuffed is to yank roots. And then lots of things break.
>> What about countries where there is no such register, or it's unreliable?
>
> Example?
Well, the US has no country-wide business register, as far as I am
aware. States have them, but there is a variation in quality,
completeness etc.
> I guess we'd have to see how things work there, how they can be made
> reliably based on their customs. In a few countries, Africa maybe, this
> may not be possible, but we don't want the Nigerian scammer to get an EV
> cert, do we?
Not all Nigerians are scammers.
> Well, who cares about majority when we're facing 25 CAs? You said we
> effectively have a veto right, so...
Well, not quite. The voting rules are such that two Nos causes a vote to
fail.
>>> This, and pretty much only this, will ensure that the card holder
>>> really is who he claims to be, in real life, as seen by the
>>> government and courts. Thus, before EV, I assumed that the above is
>>> performed for the $100/year certs.
>>
>> Really? There's no way any CA could make money doing this at $100 a cert.
>
> Nonsense. Sorry, that's just CA margin-improving nonsense.
It's not. You can't do the sort of checks you are suggesting for $100.
> First, they make $100 (per year, per cert) for that action (once, per
> customer). And it's $1000 now with EV.
You said above you were talking about all certs, not just EV.
> As I said, exactly this is offered as service in Germany for 10 Eur,
> one-time fee. If they can make a site visit, they can also look at a
> personal ID card and check a signature. My grocery store does it! What
> gives?
Germany is not the rest of the world.
Surely you can see the massive differences between the grocery store
situation and the cert situation? They are not even vaguely comparable.
You are present at your grocery store, you are making a one-time
purchase of a small amount of goods, and you can give them an ID card. I
want to get a cert from Verisign. Do I have to go round their building
in Mountain View to present my ID? And when I've done that, they still
have to check I'm the same Gervase Markham who owns the domain I'm
asking for a cert for.
I'm not saying that there shouldn't necessarily be tighter checks on the
applicant; I am, however, saying that it's a far more complicated
problem than you seem to think.
>> In the US, there are networks of companies which will do site visits
>> and this sort of verification for you, but in other countries, there
>> aren't. Such a visit would cost several hundred dollars to have
>> performed.
>
> Nobody's forcing them to have a flat world-wide fee. In fact, lots of
> things will be different in many countries, out of necessity, even with
> EV as-is.
Indeed, no one is forcing them to have a flat fee. Although if they
aren't flat, some people (not me) may consider it discriminatory.
Anyway, I point this out merely for information. It's not cheap to get
site visits done.
>> Their legal business name? Or their "trading as" name? Or the real
>> name of the person at the company who made the application?
>
> I don't know. I'd say the legal business name - "trading as" would be a
> different field.
But then you'd have certs with O fields with names no-one had ever heard
of. If you go to what you think is Sony's site, and it says "Sonii
Corporation" (one possible official romanisation of their Japanese
name), that would make you really suspicious, wouldn't it? It should.
That's exactly the sort of thing phishers do, after all - have a name
that's similar but not quite the same.
I mention this merely to show that it's not an easy problem to solve.
Gerv
Gervase Markham
>>
>> Just to be clear: They are not _intended_ to cost $1000/year upwards;
>
> mostly a marketing ploy, since the EV procedures can be performed with
> or without a CA/Browser forum. I guess, the prices will rather go up, if
> Mozilla goes along with the green carrot...
Whatever you may think of the CA market, there is competition. Anyone
who artificially inflates the price of their EV certificates is going to
lose business to companies which don't.
Gerv
Gervase Markham
> By the way, much of this could be sidestepped if CAs were required to
> publish all the evidence they have gathered together with the EV
> certificates they issue (in a complete list of certificates, not just
> those certificates that are actually used on popular sites). This
> way, everyone could review the strength of each CA's EV process. The
> peer pressure should be sufficient to ensure that everyone keeps their
> backyards clean.
An interesting idea; but wouldn't there be confidentiality problems?
Some of the things CAs might need to check might be things which a
company quite reasonably does not want to be made public.
Gerv
Gervase Markham
>>
>> They don't, as far as I can tell. Evidence provided by a Qualified
>> Indepedent Information Source (QIIS) is usually sufficent. Verisign
>> seems to have copied this part of the guidelines verbatim.
>>
Eddy,
You are continually damaging your credibility in this discussion by
throwing around unnecessarily barbed comments and wild accusations of
conspiracy and wrongdoing.
I can state with certainty that Verisign did not "write most of the EV
guidelines". I know, because I watched the drafting process.
>> Is the current certificate on https://www.verisign.com/ an EV
>> certificate? It lacks a physical address, which is required by (my
>> reading of) the guidelines.
>>
> Good catch! More than that, it was signed and issued long before the EV
> guidelines were approved (How could they know what the guidelines will
> be?).
The issue date of the certificate is the 7th of December 2006, which is
after draft 11 was published. No version of the EV guidelines have yet
been approved by the Forum, as you know. Verisign's certificate
presumably is part of Microsoft's EV program.
> And even more disturbing is the fact, that the certificate is
> valid for a period of _two_ years, whereas the guidelines speak strictly
> about _ONE_ year only!!!!
That just isn't true. Section 8 a) of the EV Certificate Guidelines
gives the maximum validity period as 27 months. It recommends 12, but
that is only a recommendation.
Gerv
Gervase Markham
impropriety, are you?
Eddy Nigg (StartCom Ltd.) wrote:
> OK! However the most important thing about this certificate is the fact,
> that it was issued:
>
> 1) More or less at the same day the EV guidelines were approved...
Except that they haven't been approved yet.
> 2) Verisign hardly could have undergone an EV audit at that stage as
> required. Such an audit takes up to a few month.
The audit criteria are up on the cabforum.org website; all you need is a
suitable auditor willing to audit you. Given that several CAs are
offering EV certs now, they must have had the audits done. Therefore
your assertion is clearly wrong.
Gerv
Gervase Markham
> Florian Weimer wrote:
>> Host names like c1d3q2 are fine, but you shouldn't be allowed to use a
>> well-known or registered trademark. If I read the Verisign CPS
>> correctly, I would be able to obtain a EV certificate for
>> citibank.enyo.de if I incorporated.
>
> Right, that's the current phishing approach.
We are currently looking into the feasibility of using the new effective
TLD service to change the URL bar so it would read (where CAPS indicates
emphasis:
www.citibank.ENYO.DE
www.CITIBANK.COM
which makes the distinction between the two quite a bit more obvious.
> Well, the cert would say "Enyo GmbH". Assuming the user looks at that
> (we should not discuss UI here, but let's say it's shown in or near the
> URLbar). But you're right, a typical phishing victim could just as
> easily confused, given that they happily enter their bank login at
> http://64.246.35.72/phase3/citibank.html
Indeed. And I agree, as long as people are happy to do that, there's not
all that much browser makers can do to protect them. Just the same as if
people don't wear seatbelts, there's not all that much you can do to
help by making the windscreen a bit more padded ;-)
Gerv
Ben Bucksch
That's true. But look at spam. Most spam originates at the US, and
spammers keep normal businesses, yet the US completely fails to stop the
problem. One or two law suits, that's it, no impact.
> But let me turn the question around: if "social engineering" means you
> can't trust what anyone says about anything, how do you establish
> anything to be true?
The government takes are of that, registering people when they are born,
issueing passports and ID cards for them. And we can check the
signatures against that.
That's the base of my argument, put shortly: Everything else is hearsay.
> [cut]
> The request is filed, and Joe intercepts the relevant mail. However,
> Foo CA rings BigCorp, talks to Fred Smith and finds he never signed
> the application, so it's rejected.
If you can intercept all mail, you can probably drag a phone call to you
as well.
> Something like that. Basically, you need to make sure that the person
> who signed the application actually exists and did sign the
> application. I can't quite see how you object to that check :-) It
> doesn't help with the problems you are particularly concerned about,
> but it's not meant to.
This and the weak phone number verification is in the critical path to
verify the request is authorized, there's no signature (and check of it)
necessary, that's the problem.
> What do you mean by "bad certs"?
Cert saying I'm A Corp although I'm B Corp. CA failing on checks.
> I suspect CAs will be "unofficially" looking out for the same tricks
> immediately. They don't want to be landed with the liability
They disclaim any liability!
> Unqualified scepticism without rationale
Well, I think history has shown us that scepticism beyond all common
sense is necessary when it comes to big CAs.
> To be even more explicit: you definitely mean "every CA-issued
> certificate", rather than "every *EV* certificate"?
No, I'm talking only about EV here.
>> Given that nothing breaks anymore, we have no need to blink.
>
> What do you mean by "nothing breaks"? If we are talking about *every*
> certificate, then for non-EV ones, all we can do if they tell us to
> get stuffed is to yank roots. And then lots of things break.
I mean nothing forces us to treat EV (or any SSL certs for that matter)
as verified or secure. We can let the user go there, but pretend it's a
normal, unsecured HTTP site. Details are UI.
>> As I said, exactly this is offered as service in Germany for 10 Eur,
>> one-time fee. If they can make a site visit, they can also look at a
>> personal ID card and check a signature. My grocery store does it!
>> What gives?
>
> Germany is not the rest of the world.
This was just an example that it is possible, quite so, and to give an
idea about the effort / money required, to add some facts, instead of a
blank "too expensive".
> Surely you can see the massive differences between the grocery store
> situation and the cert situation? ... You are present at your grocery
> store
Correct, but the ID card verification service by the post office, used
by movie mail-rent and a variety of other purposes, *is* comparable.
Or, if you want another example: Delivery of a delivery-confirmed
letter. I'm sure that exists in the US. The postman wants your paper
signature that you received the letter. He usually doesn't check the
signature against any papers / ID cards, but the expensive part is the
visiting. And it costs $5-10.
> It's not cheap to get site visits done.
Right. It may cost them $10. Or maybe even $20! Yikes!
>> I don't know. I'd say the legal business name - "trading as" would be
>> a different field.
>
> But then you'd have certs with O fields with names no-one had ever
> heard of. If you go to what you think is Sony's site, and it says
> "Sonii Corporation" (one possible official romanisation of their
> Japanese name), that would make you really suspicious, wouldn't it? It
> should. That's exactly the sort of thing phishers do, after all - have
> a name that's similar but not quite the same.
>
> I mention this merely to show that it's not an easy problem to solve.
If the real name is all useless, what do you put in the cert and display
to the user? The "trading as" name? (Sorry, havn't read the spec on
that.) If so, how do you verify that it doesn't overlap with another
company? Company names and trademarks, potentially world-wide?
Ben
Florian Weimer
> We are currently looking into the feasibility of using the new
> effective TLD service to change the URL bar so it would read (where
> CAPS indicates emphasis:
>
> www.citibank.ENYO.DE
> www.CITIBANK.COM
>
> which makes the distinction between the two quite a bit more obvious.
*grr*
Before this makes sense, you need to truncate the host part of long
URLs from the left, and not from the right. And you must make the URL
bar mandatory by default (dom.disable_window_open_feature.location is
still false in the shipped configuration).
Ben Bucksch
> Ben Bucksch wrote:
>> OK. My thought is that we don't have many chances to push things like
>> that and have users consider it. If we make them aware of it, it
>> better be bulletproof, or we should not bother them with it, just
>> treat it as little better SSL cert, no special treatment.
> You're absolutely right. Educating users is an enormous effort. That's
> why I think whatever UI we choose (green bar, not green bar, whatever)
> should be decoupled from the underlying enabling technology (EV,
> DNSSec, phishing blacklist, whatever) we use to run it. That way, we
> only have to educate users once.
One more comment. I don't know whether you think that solves it. It does
not.
Even if we have generic UI (like green bar), it does not help us, if we
have nothing to back it up. We should not show "Good" unless we're sure
the site is *trustworthy* - not just verified address/identity, not on
blacklist, etc., but really a site that we can recommend.
Or in other words: If EV is not bulletproof, it adds nothing, and does
not add anything. If we show it, and the checks were not performed
properly by the CA, and the CA disclaims liability, the users will be
mad at us or the Internet as a whole.
Similarly, if we show "green", "good" or whatever for PayPal, and PayPal
decides to freeze their account for no good reason (as they often do),
or their account gets robbed without their fault and PayPal does nothing
(as they always do), the user will understandably be *extremely* mad,
and we'll get part of the blame for showing "good", and the Internet as
a whole will be blamed. The fact that VeriSign verified the street
address of PayPal changes actually nothing.
So, unless we change the scope of CAs a lot, all that EV can give us, in
the way it's currently designed, is a verification of identity and
address, and all we can do is show that. That's actually what I'd like
to do, if we can make the displayed name meaningful and phishing-safe.
If not even *that* is reliable, we should not even show it. Which means
EV does not change anything in UI or for the user, all it does is making
CAs operate a little bit more like they should have from the beginning.
(But they'd still be below what I *expected* them to do for their money,
namely checking /beyond all doubts/ that the identity is correct, in the
way I proposed.)
Heikki Toivonen
> Even if we have generic UI (like green bar), it does not help us, if we
> have nothing to back it up. We should not show "Good" unless we're sure
> the site is *trustworthy* - not just verified address/identity, not on
> blacklist, etc., but really a site that we can recommend.
It has been said many times that EV is not about trustworthiness.
--
Heikki Toivonen
Heikki Toivonen
>> It's not cheap to get site visits done.
>
> Right. It may cost them $10. Or maybe even $20! Yikes!
I don't understand how you can claim such ridiculously low costs. There
will be travel costs that can be in the hundreds of dollars, possibly
thousands of dollars in some cases (flights, rental cars, parking, cab
fairs, meals, hotels, chauffers, guides, body guards, porters, tips, ...).
You have to pay for the auditioners time, which will almost certainly be
more than hour for the whole thing (you may need to pay for travel
time). And I wouldn't expect an auditioner to earn minimum wage.
If your business happens to be in a peaceful city where a CA has agents
available, you might squeeze a site visit for under a $100.
--
Heikki Toivonen
Michael Lefevre
If EV contributes nothing to a measure of "trustworthiness", then what is
the point of it? What the user actually wants to know is whether a site
is trustworthy, and they will be making that decision based on their
understanding of what the site and UI says, and the UI indications will be
(at least partly) based on whether a site has an EV certificate.
It may be impossible for EV to indicate trustworthiness in itself, but
the result of it is part of how the user determines what to trust, so
there is a connection.
--
Michael
Gervase Markham
> Gervase Markham wrote:
>> People who rent offices leave a paper trail - they have to show their
>> face, leave deposits and bank details, people remember them. You can't
>> do all of this anonymously from Russia any more.
>
> That's true. But look at spam. Most spam originates at the US, and
> spammers keep normal businesses, yet the US completely fails to stop the
> problem. One or two law suits, that's it, no impact.
That analogy fails because while spam is only sort-of illegal, stealing
thousands of dollars through fraud is extremely illegal. The authorities
have a much greater motivation to put a stop to phishing.
>> But let me turn the question around: if "social engineering" means you
>> can't trust what anyone says about anything, how do you establish
>> anything to be true?
>
> The government takes are of that, registering people when they are born,
> issueing passports and ID cards for them. And we can check the
> signatures against that.
>
> That's the base of my argument, put shortly: Everything else is hearsay.
And this is why I am gently trying to suggest that not everywhere else
in the world is like Germany. You are quite happy with "the government
registers everybody when they are born"; in other countries, that
doesn't happen as people see it as an infringement of civil liberties.
Or, they just don't have the infrastructure.
What can I tell you to convince you that the problem is not as simple as
you think it is? The CAB Forum does have a reasonable number of people
working on the problem. Now, either they are all blithering idiots, or
it's actually quite complicated to make this work worldwide. All I can
do is say that, from my point of view, it's the latter rather than the
former.
>> [cut]
>> The request is filed, and Joe intercepts the relevant mail. However,
>> Foo CA rings BigCorp, talks to Fred Smith and finds he never signed
>> the application, so it's rejected.
>
> If you can intercept all mail, you can probably drag a phone call to you
> as well.
I don't think that follows; certainly not in my scenario. You'd need to
bribe at least one, and possibly all the receptionists. This is starting
to look expensive and complicated to set up just one phishing site.
I really think we are getting into the range where phishers would take
one look at all this effort, and go rob an old lady instead.
>> Something like that. Basically, you need to make sure that the person
>> who signed the application actually exists and did sign the
>> application. I can't quite see how you object to that check :-) It
>> doesn't help with the problems you are particularly concerned about,
>> but it's not meant to.
>
> This and the weak phone number verification is in the critical path to
> verify the request is authorized, there's no signature (and check of it)
> necessary, that's the problem.
How would this check you speak of work?
The CA has a signature, claiming to be that of "Fred Bloggs". They want
to confirm that Fred Bloggs works for the company and signed the paper.
So they ring the company, ask for Fred Bloggs, and confirm he signed it.
Now you have argued that there's a weakness in the part where they find
out the phone number (although I don't really see it; the CAs are using
the mechanisms everyone else uses to find phone numbers). But if we
leave that aside, how could that signature be any more verified?
Getting someone to drive out to Foo Corp in person, ring the bell, find
Fred Bloggs, and ask him the question in person rather than over the
phone doesn't seem to me to be any more secure.
>> I suspect CAs will be "unofficially" looking out for the same tricks
>> immediately. They don't want to be landed with the liability
>
> They disclaim any liability!
Not any liability.
>> Unqualified scepticism without rationale
>
> Well, I think history has shown us that scepticism beyond all common
> sense is necessary when it comes to big CAs.
I don't agree. Despite the fact that Duane and crew continually bring up
Verisign's little accident from ten years ago, I really don't see this
"obvious" pattern of terrible CA behaviour that people seem to think exists.
> Or, if you want another example: Delivery of a delivery-confirmed
> letter. I'm sure that exists in the US. The postman wants your paper
> signature that you received the letter. He usually doesn't check the
> signature against any papers / ID cards, but the expensive part is the
> visiting. And it costs $5-10.
Yes, but sadly the USPS does not sell on their signature checking services.
>> It's not cheap to get site visits done.
>
> Right. It may cost them $10. Or maybe even $20! Yikes!
No. It costs hundreds of dollars in Europe. I am not just making this
up. Members of the CABF (who were in favour of site visits) did
investigations, contacted companies and obtained estimates.
> If the real name is all useless, what do you put in the cert and display
> to the user? The "trading as" name? (Sorry, havn't read the spec on
> that.)
I believe we are doing either:
Foo Boot and Shoe Corp dba. Clark's Shoes
(with dba standing for Doing Business As)
or
Clark's Shoes, xxx Foo Boot and Shoe Corp.
(with xxx standing for some abbreviation which means the reverse of dba).
I'm not quite sure where we are with this. But the point is that both
are in there.
> If so, how do you verify that it doesn't overlap with another
> company? Company names and trademarks, potentially world-wide?
Your UI needs also to display the country. (The IE UI does.)
Gerv
Gervase Markham
> Even if we have generic UI (like green bar), it does not help us, if we
> have nothing to back it up. We should not show "Good" unless we're sure
> the site is *trustworthy* - not just verified address/identity, not on
> blacklist, etc., but really a site that we can recommend.
We can't determine that.
It's not what certs are about, it's not what EV is about. It's what the
Better Business Bureau or reputation systems or word of mouth are all
about. And we don't integrate with any of those.
Determining whether someone is _actually_ trustworthy is really, really
hard. How do you know I'm trustworthy? Just because I have been so far
doesn't mean I will be in the future. I could be gaining your trust to
rip you off.
It is far easier to keep people honest by saying "I know where you live"
than to try and assess their actual honesty with no comeback if you are
wrong. So EV does the former, not the latter.
> Or in other words: If EV is not bulletproof, it adds nothing, and does
> not add anything.
That's the fallacy of unattainable perfection.
> If we show it, and the checks were not performed
> properly by the CA, and the CA disclaims liability, the users will be
> mad at us or the Internet as a whole.
If the checks were not performed properly by the CA, the CA is liable.
And we and the user will be mad at them, because we can't catch the bad
guys because the CA has duff information.
> Similarly, if we show "green", "good" or whatever for PayPal, and PayPal
> decides to freeze their account for no good reason (as they often do),
> or their account gets robbed without their fault and PayPal does nothing
> (as they always do), the user will understandably be *extremely* mad,
> and we'll get part of the blame for showing "good", and the Internet as
> a whole will be blamed. The fact that VeriSign verified the street
> address of PayPal changes actually nothing.
This is why Beltzner keeps insisting that whatever UI we show, we can't
associate it with "trustworthy". We can't _do_ "trustworthy" as an
indicator.
> So, unless we change the scope of CAs a lot, all that EV can give us, in
> the way it's currently designed, is a verification of identity and
> address, and all we can do is show that. That's actually what I'd like
> to do, if we can make the displayed name meaningful and phishing-safe.
We seem to be in violent agreement. I don't quite know why you continue
to argue this as if someone disagrees with you :-)
Gerv
Gervase Markham
> If EV contributes nothing to a measure of "trustworthiness", then what is
> the point of it?
It keeps people honest.
That's not a contradiction.
Say I'm an old and mostly-blind professor. I meet you for the very first
time, take you into my house, and leave you in my front room next to an
open suitcase containing $50,000. I then go and have a nap.
Now, imagine the same scenario where, before I go for my nap, my
eagle-eyed assistant photographs you from all angles in high detail,
takes your fingerprints and a DNA sample, and copies down your passport
number.
In which scenario are you more likely to act dishonestly and run off
with the suitcase?
Your trustworthiness hasn't changed - nothing has changed about you.
No-one has attempted to measure your trustworthiness. But in the second
scenario, you are more likely to behave in an honest manner, because the
consequences are different.
EV is like the second scenario. The more we know about the applicant,
the more likely it is that they will behave honestly - or rather,
applicants with dishonest intent won't apply.
Gerv
Gervase Markham
>
> Before this makes sense, you need to truncate the host part of long
> URLs from the left, and not from the right. And you must make the URL
> bar mandatory by default (dom.disable_window_open_feature.location is
> still false in the shipped configuration).
Why is it when you suggest a security improvement, people respond by
telling you about different ones you should make? *grr* ;-)
Yes, this is not a magic bullet on its own, and yes, it doesn't work if
the user can't see the information. Happy? :-)
Gerv
Ben Bucksch
>>> But let me turn the question around: if "social engineering" means
>>> you can't trust what anyone says about anything, how do you
>>> establish anything to be true?
>>
>> The government takes are of that, registering people when they are
>> born, issueing passports and ID cards for them. And we can check the
>> signatures against that.
>>
>> That's the base of my argument, put shortly: Everything else is hearsay.
>
> And this is why I am gently trying to suggest that not everywhere else
> in the world is like Germany. You are quite happy with "the government
> registers everybody when they are born"; in other countries, that
> doesn't happen as people see it as an infringement of civil liberties.
*sigh* We had that. I just knew people would pick on that sentence. Yes,
I understand the political dimension. I just don't *know* how the US
ensures that passports are not issued to the wrong person or with wrong
names, but I'm pretty sure the DHS *does* make sure of that. So, either
use ID cards, which a lot of countries have and can be used easily and
safely, or the passport, which is not usually considered a threat to
civil liberties, and exists *everywhere* in the world. (And I think we
discussed enough the fact that a some US people don't have one.)
Or some other reliable way, depending on the country. Basically, you
need a signature that will hold up in court. Do ***what. ever*** is
appropriate in your country.
>> there's no signature (and check of it) necessary, that's the problem.
>
> How would this check you speak of work?
*sigh*! That's the starting post of this thread.
> ask him the question in person rather than over the phone doesn't seem
> to me to be any more secure.
While "in person" certainly helps, that was not the point, rather the
verified signature. There are a number of weaknesses in using the phone:
* How to get the phone number (discussed enough)
* Intercepting calls. The whole SSL thing is about preventing
interception of communication. How can you claim it's not a significant
threat, esp. during the most important - and one time - verification
phase, I don't know. Intercepting phone may or may not be harder than
Internet, but intercepting VoIP (which many people and companies and
whole countries are using or starting to use) is probably even *easier*
than intercepting email, due to more indirections and channels.
* Social engineering, like imitating voices, calling the reception from
outside, claiming to be Fred on travel, and asking to have all calls
routed to some other number.
The list goes on.
> I really don't see this "obvious" pattern of terrible CA behaviour
> that people seem to think exists.
Well, what made us talk about EV in the first place?
Why is the 'cert holder' field complete crap in current certs?
> I believe we are doing either:
>
> Foo Boot and Shoe Corp dba. Clark's Shoes
> (with dba standing for Doing Business As)
> or
> Clark's Shoes, xxx Foo Boot and Shoe Corp.
> (with xxx standing for some abbreviation which means the reverse of dba).
They should definitely be separate fields. Both for general format
design, and because the "dba" won't be understood *at all* by non-US/UK
people, and probably not even the concept. I would have thought "dba" is
a form of corporation like "Inc." or "GmbH", so not even looked it up. I
was very confused first time I saw it, even though I had context.
Ben Bucksch
> and copies down your passport number.
Has somebody said "passport" there? I really thought I heard somebody
saying passport.
Ben Bucksch
> Ben Bucksch wrote:
>> Even if we have generic UI (like green bar), it does not help us, if
>> we have nothing to back it up. We should not show "Good" unless we're
>> sure the site is *trustworthy* - not just verified address/identity,
>> not on blacklist, etc., but really a site that we can recommend.
>
> We can't determine that.
That was my point! Thus, we cannot use a "generic UI" (like "green" or
"good") as you suggested.
>> If we show it, and the checks were not performed properly by the CA,
>> and the CA disclaims liability, the users will be mad at us or the
>> Internet as a whole.
>
> If the checks were not performed properly by the CA, the CA is liable.
No. If they follow the guidelines, they disclaim liability. If the
checks failed, because they were carried out in an obviously sloppy and
insufficient way, but meet the guidelines in *letter*, they are not
liable (per guidelines).
> We seem to be in violent agreement. I don't quite know why you continue
> to argue this as if someone disagrees with you :-)
hehe. Maybe.
Same goes with you, BTW. You said you would have liked to see
signatures, but you keep arguing against it. Just because somebody said
it will cost hundreds of dollars?
Gervase Markham
> *sigh* We had that. I just knew people would pick on that sentence. Yes,
> I understand the political dimension. I just don't *know* how the US
> ensures that passports are not issued to the wrong person or with wrong
> names, but I'm pretty sure the DHS *does* make sure of that. So, either
> use ID cards, which a lot of countries have and can be used easily and
> safely, or the passport, which is not usually considered a threat to
> civil liberties, and exists *everywhere* in the world. (And I think we
> discussed enough the fact that a some US people don't have one.)
>
> Or some other reliable way, depending on the country. Basically, you
> need a signature that will hold up in court. Do ***what. ever*** is
> appropriate in your country.
And for vetting individuals, I'm sure something like this will be done.
But it's not appropriate for businesses and corporations. Why should
some poor person at Microsoft have to have his personal details encoded
into all their certificates? And he's not going to be the responsible
one anyway. There are laws which make corporations into virtual persons
for a reason.
>> ask him the question in person rather than over the phone doesn't seem
>> to me to be any more secure.
>
> While "in person" certainly helps, that was not the point, rather the
> verified signature. There are a number of weaknesses in using the phone:
> * How to get the phone number (discussed enough)
> * Intercepting calls. The whole SSL thing is about preventing
> interception of communication. How can you claim it's not a significant
> threat, esp. during the most important - and one time - verification
> phase, I don't know. Intercepting phone may or may not be harder than
> Internet, but intercepting VoIP (which many people and companies and
> whole countries are using or starting to use) is probably even *easier*
> than intercepting email, due to more indirections and channels.
But you have to know exactly when the CA is going to call.
> * Social engineering, like imitating voices, calling the reception from
> outside, claiming to be Fred on travel, and asking to have all calls
> routed to some other number.
Again, you have to know when the CA is going to call.
And intercepting VoIP may be "easy", but it's yet another thing you have
to set up and do manually per cert you are trying to obtain. Where have
we got to so far? You need to bribe the mail boy, set up a VoIP tap, ...
>> I really don't see this "obvious" pattern of terrible CA behaviour
>> that people seem to think exists.
>
> Well, what made us talk about EV in the first place?
> Why is the 'cert holder' field complete crap in current certs?
The Cert holder field is unverified in many current certs due to market
forces. If I'd been running a CA, I'd probably have done the same. EV is
a way to use market forces to drive things in the right direction.
>> I believe we are doing either:
>>
>> Foo Boot and Shoe Corp dba. Clark's Shoes
>> (with dba standing for Doing Business As)
>> or
>> Clark's Shoes, xxx Foo Boot and Shoe Corp.
>> (with xxx standing for some abbreviation which means the reverse of dba).
>
> They should definitely be separate fields.
I think there may be technical issues with that. But we can suggest it.
> Both for general format
> design, and because the "dba" won't be understood *at all* by non-US/UK
> people, and probably not even the concept. I would have thought "dba" is
> a form of corporation like "Inc." or "GmbH", so not even looked it up. I
> was very confused first time I saw it, even though I had context.
They might be using brackets. Again, I'd need to check the document.
Gerv
Gervase Markham
> information at users...there is no need to display anything about the
> certificate, since details in the certificate will be only looked up and
> used, in case of fraud happens...(quoting Gerv from a previous thread).
I don't believe I said that about _all_ the details.
If you look at the IE UI, it displays the O field (Organisation) and the
C field (Country). I personally think this is good. We are talking about
the format of the O field.
Gerv
Gervase Markham
Or Government-issued ID.
Gerv
Gervase Markham
> That was my point! Thus, we cannot use a "generic UI" (like "green" or
> "good") as you suggested.
I haven't suggested any UI. I use the green bar as an example regularly
because that's UI that actually exists, and it's much easier to talk in
concrete rather than abstract terms.
The discussion of what UI we might use, if any, is going to happen in
mozilla.dev.apps.firefox.
>>> If we show it, and the checks were not performed properly by the CA,
>>> and the CA disclaims liability, the users will be mad at us or the
>>> Internet as a whole.
>>
>> If the checks were not performed properly by the CA, the CA is liable.
>
> No. If they follow the guidelines, they disclaim liability.
Then the checks have been performed properly. You can't have it both
ways. The CA can't both "not perform the checks properly" and "follow
the guidelines".
> Same goes with you, BTW. You said you would have liked to see
> signatures, but you keep arguing against it. Just because somebody said
> it will cost hundreds of dollars?
You mean site visits? They are in there for some circumstances, but not all.
Gerv
Ben Bucksch
>> Basically, you need a signature that will hold up in court. Do
>> ***what. ever*** is appropriate in your country.
> And for vetting individuals, I'm sure something like this will be done.
Good. If it can be done for individuals, it can also be done for CEOs.
> But it's not appropriate for businesses and corporations. Why should
> some poor person at Microsoft have to have his personal details
> encoded into all their certificates?
I think you misunderstood me. They don't. This is only to verify the
signature that the CA gets, to ensure that the who gets the certs is
actually allowed to make decisions for the company, or is authorized by
such a person.
> But you have to know exactly when the CA is going to call.
No, not necessarily. Caller ID. Reroute all calls coming from CA.
> EV is a way to use market forces to drive things in the right direction.
No. It states a bar, but not a direction. The direction will still be
weaker checks, until you reach the absolute minimum, or lower if you
don't get caught. It would change the *direction*, if it would include
liability.
>> [dba] They should definitely be separate fields.
>
> I think there may be technical issues with that.
I can't see any, given that new fields / formats are being defined,
technically.
> But we can suggest it.
Thanks.
Thanks for the responses,
Ben
Ben Bucksch
>>> If the checks were not performed properly by the CA, the CA is liable.
>>
>> No. If they follow the guidelines, they disclaim liability.
>
> Then the checks have been performed properly. You can't have it both
> ways. The CA can't both "not perform the checks properly" and "follow
> the guidelines".
They can, if
1) the guidelines are too weak
2) the guidelines only require a check to be *performed*, but it's not
performed *properly*.
2) a) You "check" data A by looking at it, and it's obviously wrong, but
you let it pass the check, because the clerk who did it is an untrained
monkey for $5/h who doesn't care a bit, and nobody holds him accountable
2) b) Or you check the address, but the source where you checked it
again was wrong, and you *know* it's a weak, but cheap/convenient source.
>> Same goes with you, BTW. You said you would have liked to see
>> signatures, but you keep arguing against it. Just because somebody
>> said it will cost hundreds of dollars?
>
> You mean site visits? They are in there for some circumstances, but
> not all.
Well, I have not asked to require site visits, only signature checks,
against the passport.
Dan Veditz
> basic information about the certificate to the user in a most convenient
> way (such as mouseover and/or one-click action) should the user be
> interested in it. Additionally by making the padlock area more prominent
> , by displaying the organization name, locality and country and some
> highlight color perhaps, it would draw the attention of the user to it.
> In this way the browser might help the user provide the important
> information better....
Part of the Firefox 3 plan is to revamp the security indicators. The
current UI is created (I won't say "designed") by software developers, the
new UI will be designed by folks trained to design UI. Don't know what
they'll come up with, but I'm looking forward to it.
Can we stop arguing about it now? Or at least wait until we have a design
proposal to argue about?
> You also insist in keeping
> it this way, by providing a distinctive color for EV and nothing else!
> No improvement of other shortcomings!
Who keeps insisting that? Certainly not Gerv whom you've been addressing.
The Mozilla folks have been rather insistent we are NOT going with a "Green
for Go!" strategy, but other than that the design is still unspecified. If
we're not going with a green bar it will quite obviously have to have
something else, which is quite the opposite of nothing.
Gervase Markham
>> But you have to know exactly when the CA is going to call.
>
> No, not necessarily. Caller ID. Reroute all calls coming from CA.
We're in fantasy land now. If I can get control of all phone calls
coming into and going out of a company, I wouldn't use a CA. I'd pick
some larger company and make a killing on the stock market using insider
information.
Gerv
Gervase Markham
> Gervase Markham wrote:
>>>> If the checks were not performed properly by the CA, the CA is liable.
>>>
>>> No. If they follow the guidelines, they disclaim liability.
>>
>> Then the checks have been performed properly. You can't have it both
>> ways. The CA can't both "not perform the checks properly" and "follow
>> the guidelines".
>
> They can, if
> 1) the guidelines are too weak
No. Even if the guidelines are "too weak" (by Ben Bucksch's definition),
if they are following them then they are by definition performing the
checks properly.
> 2) the guidelines only require a check to be *performed*, but it's not
> performed *properly*.
What court of law would make that distinction? "Yes, Mr CA, we are going
to let you off because you performed all the checks and then ignored the
results, which is technically allowed by the standard."
> 2) a) You "check" data A by looking at it, and it's obviously wrong, but
> you let it pass the check, because the clerk who did it is an untrained
> monkey for $5/h who doesn't care a bit, and nobody holds him accountable
See above.
> 2) b) Or you check the address, but the source where you checked it
> again was wrong, and you *know* it's a weak, but cheap/convenient source.
They are still performing the checks properly and following the guidelines.
But this is a pointless semantic discussion. Either the guidelines are
binding or they aren't. If they are binding, the CA will follow them or
be liable. If they are not, then what makes them not binding? After all,
all the CAs are writing them into their CPSes.
Gerv
Gervase Markham
> but outright dismissed my suggestions! It seems now, that for whatever
> reasons (because IE has it (???)), that you seem to come to a similar
> understanding...
I don't really agree with you, I'm afraid. :-) We should not display
this information for non-EV certificates (as I believe you wanted)
because we can't guarantee it's correct.
I think it's a good idea not because IE does it (Opera does it as well)
but because one of the key points of EV is to make the data in that
field more reliable, such that it can be displayed to users with confidence.
As you keep saying, EV means "we know who you are", not "you are
trustworthy". Therefore, it makes sense to display that knowledge.
Gerv
beltzner
> Part of the Firefox 3 plan is to revamp the security indicators. The
> current UI is created (I won't say "designed") by software developers, the
> new UI will be designed by folks trained to design UI. Don't know what
> they'll come up with, but I'm looking forward to it.
As am I. And, just to put something to rest, let me say this: as the
owner of ui-review on the /browser module, and speaking for myself and
mconnor (module owner of /browser), I can assure you that Firefox will
*not* support a UI where the presence of an EV certificate alone[1]
generates a message of "This website is safe" or even "This website is
trustworthy." That's the padlock mistake, and we're *not* going to
make it again.
I should also mention that this area has been seen as important enough
to result in the hiring of Johnathan Nightingale (formal announcement
to appear next week when he officially starts, but you can read his
announcement on his blog:
http://blog.johnath.com/index.php/2007/02/08/transition/
So yeah, we're taking this seriously, and will look at the UI with
care and due attention.
> Can we stop arguing about it now? Or at least wait until we have a design
> proposal to argue about?
There *is* something I'd like to go back to arguing, which is: do we
feel like these guidelines for audit and acceptance are solid? are
there changes we want to propose to the CA/B Forum?
So far I've heard reasonable arguments for:
- linking a form of government ID to the application (proposed, but
dropped, but we can repropose it)
- increasing the liability exposure for CAs found to be lax in their
applications of the guidelines
- formalising the set of third-party identity providers to verify
business information
- a whole slew of noise about whether or not this is a conspiracy by
Kelvin Yiu and Phillip Hallam Baker to make a few extra bucks on the
side
I'm really only interested in points like the first three. If it's a
market conspiracy, you can bet your bippy that the market will decide.
cheers,
mike
[1]: In fact, I don't think that in the timeframe of Firefox 3 there
will be any set of metadata which we'd use to declare "This website is
safe", but I'm willing to be proven wrong so I don't want to overstate
my position.
--
/ mike beltzner / phenomenologist / mozilla corporation /
Florian Weimer
>> *grr*
>> Before this makes sense, you need to truncate the host part of long
>> URLs from the left, and not from the right. And you must make the URL
>> bar mandatory by default (dom.disable_window_open_feature.location is
>> still false in the shipped configuration).
>
> Why is it when you suggest a security improvement, people respond by
> telling you about different ones you should make? *grr* ;-)
Because you've been ignoring the second sugesstion *for* *years*, and
phishing sites begin to pop up (pun intended) which exploit this to
display the expected indicators to the user.
> Yes, this is not a magic bullet on its own, and yes, it doesn't work
> if the user can't see the information. Happy? :-)
I would feel better if you actually fixed the location bar bug. IE7
introduced this behavior to the audience and should have absorbed the
call center costs (or will so in a few more month, if you are that
scared of this change).
beltzner
> I would feel better if you actually fixed the location bar bug. IE7
> introduced this behavior to the audience and should have absorbed the
> call center costs (or will so in a few more month, if you are that
> scared of this change).
Have you seen LocationBar^2
(https://addons.mozilla.org/firefox/4014/)? I'm considering something
a lot like that for Firefox 3 ...
cheers,
mike
Duane
> - increasing the liability exposure for CAs found to be lax in their
> applications of the guidelines
The problem here is businesses tend to do whatever is cheapest, if
paying out $2k is cheaper then due diligence then without any other
external forces increased or excessive liability is the only option to
keep companies doing the right thing.
As someone else pointed out they get more insurance sending parcels or
if your UPS devices fail to protect equipment.
> I'm really only interested in points like the first three. If it's a
> market conspiracy, you can bet your bippy that the market will decide.
Just like it did with PKI already? :)
> [1]: In fact, I don't think that in the timeframe of Firefox 3 there
> will be any set of metadata which we'd use to declare "This website is
> safe", but I'm willing to be proven wrong so I don't want to overstate
> my position.
Will you take an interest in the security researchers that were trying
to help Mozilla out in the past (but mostly ignored or worst given the
run around)?
--
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."
beltzner
> beltzner wrote:
> > - increasing the liability exposure for CAs found to be lax in their
> > applications of the guidelines
>
> The problem here is businesses tend to do whatever is cheapest, if
> paying out $2k is cheaper then due diligence then without any other
> external forces increased or excessive liability is the only option to
> keep companies doing the right thing.
Well, that and brand loyalty. I think we need to make the CAs more
publically accountable for their assertions and actions. Those CAs
that aren't holding up to their end of the EV bargain should be either
stripped of their ability to issue EV certs, or suffer brand
affiliation consequences.
But I think we're agreeing: the guidelines need teeth.
> As someone else pointed out they get more insurance sending parcels or
> if your UPS devices fail to protect equipment.
>
> > I'm really only interested in points like the first three. If it's a
> > market conspiracy, you can bet your bippy that the market will decide.
>
> Just like it did with PKI already? :)
Sure. Which is why we're at $10 certs. The market decided that the CAs
weren't offering a service, and so they devalued the cost of that
service. I don't think such devaluation was a CA-inspired conspiracy!
:)
> > [1]: In fact, I don't think that in the timeframe of Firefox 3 there
> > will be any set of metadata which we'd use to declare "This website is
> > safe", but I'm willing to be proven wrong so I don't want to overstate
> > my position.
>
> Will you take an interest in the security researchers that were trying
> to help Mozilla out in the past (but mostly ignored or worst given the
> run around)?
Not only will I, but I have been. I'm a member of the W3C Web Security
Context Working Group, the Anti Phishing Working Group, and while I'm
not planning to attend SOUPS this year, I know the lion's share of
people who are presenting there and have made contact with them all.
I'm not familiar with CACert or the "runaround" that you're
describing. Amir Hertzberg complained to me once that he didn't get
support from Mozilla, but when I asked him to describe what support he
asked for and from whom, he didn't respond. I'd like to unblock that
if I can, but that's for another thread.
Duane
> Well, that and brand loyalty. I think we need to make the CAs more
> publically accountable for their assertions and actions. Those CAs
> that aren't holding up to their end of the EV bargain should be either
> stripped of their ability to issue EV certs, or suffer brand
> affiliation consequences.
I don't think brand suffering is a big enough of a threat to some
companies to keep them honest, take all the problems Sony has been
involved with last year and they didn't suffer noticibly.
I don't know what the liability should be, but a flat rate fee isn't the
answer either, some kind of liability based on income would be the best
way to handle things since a rich company won't be "hurt" as much as a
small company kind of thing.
> Sure. Which is why we're at $10 certs. The market decided that the CAs
> weren't offering a service, and so they devalued the cost of that
> service. I don't think such devaluation was a CA-inspired conspiracy!
> :)
I didn't mean it was any kind of conspiracy, just the market self
balancing to an extent.
> I'm not familiar with CACert or the "runaround" that you're
In this case I didn't mean to imply anything about CAcert.
beltzner
> The conspiracy is a different one...Now that prices are down to the
> bottom, the "commercial" CAs had to reinvent themselves in order to
> revive the once lucrative business. But how to do that? Define a new
> standard and get the browsers to do some extra work...True, there is
> some marketing effort to do...but now there is a good reason to charge
> again 1,000 US$ for it...Excellent!
For the record, VeriSign's 128-bit DV certs cost $1270 today. Is that
part of the conspiracy? No, they just manage to convince people to pay
more.
If StartCom can follow the EV guidelines for cheaper, they stand to
make a killing. I don't get what upsets you about this, Eddy. The
market will adjust. Believe in it. It's just that now the market will
be guided by standard guidelines for how to do validation and offer
repudiation, revocation and let users find the actual certificate
holder.
So let's work on making those guidelines tenable for all players, and
stop talking about how one CA plans on selling it for what you feel is
too much money. I don't care about VeriSign's business model, I care
about making sure that the EV specification actually accomplishes its
goal of providing a validated identity for the certificate holder.
> One problem...when this fantastic idea came up first, the "market share"
> of the new Mozilla browser was barely a few percents anywhere and would
> it have stayed like that, EV would be a fact today...but
> ooopps...something changed....Firefox has taken the lead at some places
> already (Notably in Germany, but also here
> http://www.boingboing.net/stats/#browsers ). Now they are obviously
> counting on it, that Mozilla plays nicely and is not going to upset the
> party...Well, some FUD about Firefox not being secure and loosing the
> "browser market" might help... (
> http://www.theregister.co.uk/2006/10/25/verisign_extended_validation/ )...
One hopes you're not serious with this. I quote from the article itself:
"A Firefox implementation of extended validation can only be a matter
of time, since the Mozilla Foundation knows in order to compete it
cannot afford for its browser to be just as good as IE7; it has to be
better."
We will implement EV. We will also implement better UI for EV. We will
be better. That's what we're saying. The green bar is not better. The
lock is already bad. Let's get to the process of fixing it with the
tools we have at hand.
Duane
> One hopes you're not serious with this. I quote from the article itself:
Several people have tried to make claims the quotes were taken out of
context and the Verisign in question even issued a "correction" on his
blog, but the fact remains that Versigin was really pushing it's FUD
campaign at the time to push through its new business model as quickly
as possible with as little input from the wider community to limit
criticism from people.
In fact up until the last stages of the process most people were pretty
hush hush about the whole thing, and as Eddy points out only big
commercial entities and browsers were invited and in turn large chunks
of the internet community has been excluded (like sole proprietors,
partnerships etc, and I do believe there was murmurings that
Universities were also excluded under the current policies).
How can this be a good thing if only large enterprises are elligible for
certificates, and if Verisign and MS are so gun hoe to implement EV
without fixing the current discrepancies?
Florian Weimer
> On 2/13/07, Florian Weimer <f...@deneb.enyo.de> wrote:
>> I would feel better if you actually fixed the location bar bug. IE7
>> introduced this behavior to the audience and should have absorbed the
>> call center costs (or will so in a few more month, if you are that
>> scared of this change).
>
> Have you seen LocationBar^2
> (https://addons.mozilla.org/firefox/4014/)?
Personally, I simply tweak the configuration on my installations (and
selectively enable JavaScript anyway).
It's about the default, really.
Gervase Markham
> Well, that and brand loyalty. I think we need to make the CAs more
> publically accountable for their assertions and actions.
While this would be great in theory, I continue to have reservations
about the ideas which have so far been suggested to put it into
practice. (Perhaps you and Jonathan have better ones :-)
In order for the CAs to be accountable, there have to be negative
consequences of their bad actions which they would want to avoid. We,
the browser makers, can provide negative consequences by removing their
roots (which also has negative consequences for our users) or by
revoking their EV status (which has negative consequences for that CA's
direct customers, the websites, which is a great improvement on
root-yanking, because the CAs will get yelled at rather than us).
However, such negative consequences are provided without too much of the
"publically" from your sentence above. "Publically accountable" has, at
least in the past, been associated with putting CA names in the chrome.
I don't know if that's what you mean, but I find it difficult to imagine
a world where the average Internet user has brain space to know about
and store reputation information for 20 or 30 CAs - and to modify their
behaviour based on that information.
In other words, for CA public accountability to work in this scenario,
the following has to happen: user shops at site Foo Corp. User spends
half an hour filling their basket. User goes to the checkout, and finds
that it's secured by Snake Oil CA. User has a strong enough
understanding that Snake Oil CA has a bad reputation that they throw
away their basket and go and shop elsewhere.
I can't see that happening.
> Those CAs
> that aren't holding up to their end of the EV bargain should be either
> stripped of their ability to issue EV certs, or suffer brand
> affiliation consequences.
Stripped of their ability, certainly.
Gerv
Ian G
> Ian G, 14.02.2007 00:40:
>> But, that's blue sky. About the only thing that you could
>> do right now is say:
>>
>> CA TrustMeDoc claims BillyBlue is behind http://BB.com/
>>
>> I don't know where "safe" or "trustworthy" fits in ...
>
> Well, as you know SSL is not only checking the authenticity but also
> provides confidentiality. So the "safe" just refers to the latter, that
> the line is encrypted, and nobody else but the correspondent can read it.
If you can get the user to accept that definition of safe,
this works. If not, not. Has the user ever been asked?
(To clarify, I'm not saying "ask the user...," I'm just
pointing out that unless you asked the user, you won't be
able to support that the user accepts the definition, and
therefore the definition is useless...)
> That's why i think, that the padlock was only a mistake in terms that it
> has been misunderstood. It just tells me, that the _line_ is safe, not the
> correspondent.
Right.
There is a tendency to go from purely technical statements
and then to rewrite them so as to be easily understood by
the consumer. Normal marketing, really.
To the extent that the consumer is educated and is
responsible, this is ok.
For example, a driver of a car is responsible. That's what
the driver's licence is about. In this regime there is no
problem telling a potential car driver that the car goes
faster than a racing car ... because no matter what, the
driver *is* responsible.
To the extent that there is *no danger*, then it's also
plausible to make silly claims.
Etc, etc.
The problem that arose in the certificate area is that it
was common practice from the early days to state that secure
browsing was safe, and you were safe to enter your credit
card details.
In this case, it failed on three counts:
1. the user was not competent to take on that
responsibility by objective standards,
2. there was some danger, and
3. the statements were wrong at some level.
All of which was fine for the first decade of the web,
because the "danger" was originally low, and then only
became high, e.g., phishing, around 2003.
Hence, some of us have been warning the CAs to take off
*all* claims of vagueness such as Trust, Safety, Secure,
etc. This has been going on since around 2003, and I
vaguelly recall that Verisign did in fact come to this
conclusion as well, and removed claims from its website.
> I would like to have both information presented seperately:
> 1. is the line encryped?
> 2. who tells me what about the correspondant node?
That's reasonable, yes. The browser can make a fairly
definate statement on those two questions, as written.
> How to present these two things with the least potential of
> misunderstanding (also for Alices and Grandmas) I have no clue, and is
> most probably a tough task.
A fun project :)
> (Maybe a symbol for a "whisper"-mode, which also shows an "ID field" which
> content is left to the user to check? But then you can also keep the
> padlock as a whisper-symbol and complement it with such an ID field.)
Yes, the Firefox UI project ... will be quite interesting to
see how they do that.
For our part, we can establish some principles:
1. the browser is an authority on the encryption.
2. the cert is an authority on the name "identity".
3. the cert is a proxy for the CA which is the real
authority.
4. any statement made without authority raises liability.
5. any material info hidden from the user raises liability.
6. any excessive info forced on the user causes rejection.
etc etc. The firefox team get to solve it :)
iang
Gervase Markham
> If StartCom can follow the EV guidelines for cheaper, they stand to
> make a killing. I don't get what upsets you about this, Eddy. The
> market will adjust. Believe in it. It's just that now the market will
> be guided by standard guidelines for how to do validation and offer
> repudiation, revocation and let users find the actual certificate
> holder.
Just to be clear: Eddy can't offer EV certificates because a Webtrust
audit is a condition of membership for the CA/Browser Forum, and
Startcom doesn't have one. (The Mozilla CA Certificate Policy accepts
various equivalents to a Webtrust audit, which is how Startcom is
included in our root store.)
Even if he had a Webtrust audit, he would also need a Webtrust EV audit
to audit his EV procedures, which would also cost money. But this is a
cost borne by all CAs who wish to offer EV.
I point these things out to make the situation clear, not because I
necessarily think they are unfair. However, it would certainly be
possible for the Mozilla Foundation to lobby for a change in the
CA/Browser Forum membership rules, should it choose to do so. I wouldn't
be able to comment on the likelihood of our succeeding.
Gerv
Gervase Markham
> So far I've heard reasonable arguments for:
This is a very helpful list.
> - linking a form of government ID to the application (proposed, but
> dropped, but we can repropose it)
>
> - increasing the liability exposure for CAs found to be lax in their
> applications of the guidelines
>
> - formalising the set of third-party identity providers to verify
> business information
I'm not sure that's feasible (if I understand the point correctly),
given the large number of countries and jurisdictions in which EV has to
operate. Currently, the standard defines a "QIIS" (Qualified Independent
Information Source) as having to have particular qualities to be
suitable for use in EV validation. I think this is probably the only
workable approach - although we might want to suggest modifications to
the criteria.
Gerv
Boris Zbarsky
> However, such negative consequences are provided without too much of the
> "publically" from your sentence above. "Publically accountable" has, at
> least in the past, been associated with putting CA names in the chrome.
Could we push the accountability onto websites here as well (coming back to the
idea of "who are the CA's customers?")?
> In other words, for CA public accountability to work in this scenario,
> the following has to happen: user shops at site Foo Corp. User spends
> half an hour filling their basket. User goes to the checkout, and finds
> that it's secured by Snake Oil CA. User has a strong enough
> understanding that Snake Oil CA has a bad reputation that they throw
> away their basket and go and shop elsewhere.
So an alternate proposal is the user gets to the checkout, and gets a nice
message from the browser saying,
"The organization which says this site is safe to shop at is known
to lie. Sending this site money could be very dangerous."
Still sucks for the user, but once the site discovers this is happening they'll
be either banning browsers or switching CAs pronto. Question is which. ;)
-Boris
Gervase Markham
> So an alternate proposal is the user gets to the checkout, and gets a
> nice message from the browser saying,
>
> "The organization which says this site is safe to shop at is known
> to lie. Sending this site money could be very dangerous."
But if we knew that, why didn't we just yank the cert anyway?
The advocates for a "CA reputation" system are suggesting that it would
work in absence of sufficient evidence for a browser to yank a cert.
Either that, or they believe that the browsers should just include the
certs of anyone who asks no matter what their behaviour, and let the
users sort it out - i.e. that we shouldn't be making judgements about CA
quality.
Gerv
Boris Zbarsky
> But if we knew that, why didn't we just yank the cert anyway?
Good question.
If we had a message along the lines of what I wrote for yanked certs (as opposed
to never-added certs, where the message would need to be different), instead of
our current goobledygook, I'd be happier yanking certs.
As things stand, if we yank a cert all users see is an unintelligible alert.
-Boris
Ben Bucksch
> If it's a market conspiracy, you can bet your bippy that the market
> will decide.
I bet my clippy <http://ars.userfriendly.org/cartoons/?id=20070211>
> [1]: In fact, I don't think that in the timeframe of Firefox 3 there
> will be any set of metadata which we'd use to declare "This website is
> safe", but I'm willing to be proven wrong so I don't want to overstate
> my position.
In fact, I'm not sure there *can* be that kind of metadata. Anything
that declares AOL or PayPal as "safe" is failure of the system :). I'm
totally serious.
Ben Bucksch
> If it's a market conspiracy, you can bet your bippy that the market
> will decide.
I bet my clippy <http://ars.userfriendly.org/cartoons/?id=20070211>
> [1]: In fact, I don't think that in the timeframe of Firefox 3 there
> will be any set of metadata which we'd use to declare "This website is
> safe", but I'm willing to be proven wrong so I don't want to overstate
> my position.
In fact, I'm not sure there *can* be that kind of metadata. Anything
Ben Bucksch
Have you seen LocationBar^2
(https://addons.mozilla.org/firefox/4014/)? I'm considering something
a lot like that for Firefox 3 ...
I still think that showing *only* the second level domain - *not* as part of the URL, which is technical glibberish for most people - is - next to bookmarks - the best approach against phishing, even though a dramatic change in browser UI. I *don't* think that just bolding the URL is enough.
I once implemented that as experiment in
https://bugzilla.mozilla.org/show_bug.cgi?id=228524
see screenshots there.
I am thinking along the lines of (slightly different from the screenshots above):
- Show domain very prominently in the middle of the urlbar, so that even a normal user can't miss it. Not as textfield, but non-editable, selectable, bold label.
- Show the EV cert holder, if available, next to the domain. No
other special treatment of EV.
- Keep search field
- Remove the urlbar, to avoid clutter. Only in default config, it will still be available in the toolbar customization.
- Put an "open" button to the left of the domain field. Clicking on it shows the current URL in a textfield (either in dialog url toolbar), in a way so that the user can easily either edit the URL or enter a new one.
There are 2 problems with that approach:
- It will make tech guys freak out, they want to see the URL at all
times, but they can customize their toolbar. There is no practical
problem, because clicking on "Open" button and starting to type takes
exactly as many clicks as clicking on urlbar and starting to type.
- It will confuse people who want to go to a site by entering the
domain. They'll probably start entering URLs in the search field, which
is not what we want. Trying to recognize the URL/domain may or may not
be always possible, and turns the field a dual-purpose field which is
generally a very, very bad idea for usability and code.
Ben Bucksch
> Have you seen LocationBar^2
> (https://addons.mozilla.org/firefox/4014/)? I'm considering something
> a lot like that for Firefox 3 ...
OK, it doesn't fit in this thread, but since you mention that, I'll just
shortly tell you my ideas:
I still think that showing *only* the second level domain - *not* as
part of the URL, which is technical glibberish for most people - is -
next to bookmarks - the best approach against phishing, even though a
dramatic change in browser UI. I *don't* think that just bolding the URL
is enough.
I once implemented that as experiment in
https://bugzilla.mozilla.org/show_bug.cgi?id=228524
see screenshots there.
I am thinking along the lines of (slightly different from the
screenshots above):
* Show domain very prominently in the middle of the urlbar, so that
even a normal user can't miss it. Not as textfield, but
non-editable, selectable, bold label.
* Show the EV cert holder, if available, next to the domain. No
other special treatment of EV.
* Keep search field
* Remove the urlbar, to avoid clutter. Only in default config, it
will still be available in the toolbar customization.
* Put an "open" button to the left of the domain field. Clicking on
it shows the current URL in a textfield (either in dialog url
toolbar), in a way so that the user can easily either edit the URL
or enter a new one.
There are 2 problems with that approach:
* It will make tech guys freak out, they want to see the URL at all
times, but they can customize their toolbar. There is no practical
problem, because clicking on "Open" button and starting to type
takes exactly as many clicks as clicking on urlbar and starting to
type.
* It will confuse people who want to go to a site by entering the
beltzner
> I still think that showing *only* the second level domain - *not* as
> part of the URL, which is technical glibberish for most people - is -
> next to bookmarks - the best approach against phishing, even though a
> dramatic change in browser UI. I *don't* think that just bolding the URL
> is enough.
Interesting. I'd buy that argument, really.
> * Show domain very prominently in the middle of the urlbar, so that
> even a normal user can't miss it. Not as textfield, but
> non-editable, selectable, bold label.
I'd actually keep this in the location bar, but give it a very
button-like UI treatment. That way it also acts as a "snapback" to the
root domain.
> * Show the EV cert holder, if available, next to the domain. No
> other special treatment of EV.
For EV I was going to suggest that we don't show the domain name, but
instead show the name of the cert holder. So [Paypal, Inc.].
> * Keep search field
Yeah, that's not going anyplace soon. ;)
> * Remove the urlbar, to avoid clutter. Only in default config, it
> will still be available in the toolbar customization.
That's probably also not going anyplace soon, but I think there's a
lot of opportunity to make it more interactive and useful. Direct edit
capabilities need to be there to satisfy a core user set, and also
because, as you learn more about the internet, it turns out direct
edit of the URL field is achingly useful. I think we want to add
functionality to make the URL bar more useful for novices while not
taking away power from pros.
> * Put an "open" button to the left of the domain field. Clicking on
> it shows the current URL in a textfield (either in dialog url
> toolbar), in a way so that the user can easily either edit the URL
> or enter a new one.
Or do clever things when the user gestures that they want to enter an
edit mode by moving the mouse, clicking in the text areas, etc.
> There are 2 problems with that approach:
>
> * It will make tech guys freak out, they want to see the URL at all
> times, but they can customize their toolbar. There is no practical
> problem, because clicking on "Open" button and starting to type
> takes exactly as many clicks as clicking on urlbar and starting to
> type.
As long as the resulting structure looks sort of like a URL, I don't
think you're actually going to see this freakout, actually. I think
you will if you take away their ability to quickly cut, paste, and
edit the URL.
> * It will confuse people who want to go to a site by entering the
> domain. They'll probably start entering URLs in the search field,
> which is not what we want. Trying to recognize the URL/domain may
> or may not be always possible, and turns the field a dual-purpose
> field which is generally a very, very bad idea for usability and code.
There's been some good evidence recently that shows:
- people type in domain names to the location bar up to 30% of the
time for navigating to a new page
- people type in domain names to search engines to find competitors
or similar businesses.
Anyway, we're into UI design, which I promised myself I wouldn't do in
this forum, but I just find this idea of making the location bar
smarter and more useful so *intriguing*! :)
Ben Bucksch
> I'd actually keep this in the location bar, but give it a very
> button-like UI treatment. That way it also acts as a "snapback" to the
> root domain.
I don't know what you mean with "button-like UI treatment" and
"snapback", but I could buy that allowing users to enter something there
would both strengthen the user's focus on it (which is what I want) and
nicely solve the "where to manually enter URLs" discovery problem.
> For EV I was going to suggest that we don't show the domain name, but
> instead show the name of the cert holder. So [Paypal, Inc.].
I think that the domain is still the strongest trust root. I think
showing only the cert holder puts too much emphasis on EV. The realname
has phishing problems of its own. I know what ebay.com is, but I don't
know what eBay Help, Inc. is.
>> * Keep the search field
> Yeah, that's not going anyplace soon. ;)
lol!
>> * Remove the urlbar
>
> That's probably also not going anyplace soon
I know it's very tough, but it's quite central to the proposal. It's the
URL which is confusing users. (Half of the time - the other half it's
the link text - there are other ways to attack that.)
Imagine: domain label shows hosters.cx and urlbar shows
http://www.microsoft.com.hosters.cx/download/. What do you think will a
user pay attention to? You have only one guess.
BTW: The other hard, but central part is to educate companies to use one
domain only, always. No more mybankofamerica.com crap, no more
abcnews.com, much less abcnews.go.com, it *must* be either news.abc.com
or abc.com/news/. No exceptions allowed. At some point, when we
convinced most companies, we can use the press for the effort to educate
both users and the rest of companies.
Yes, for both news.abc.com and abc.com/news/, my proposal would show
only abc.com, but it would show (the bad) abcnews.com. That's kind of a
contradiction to the last paragraph. Not sure what to do. We could strip
down the URL, remove username/password and query, maybe even filename,
leaving only hostname (not just domain) and path. But then we're still
victim to microsoft.com.hosters.cx/download/, which is exactly what I
want to avoid.
> Direct edit capabilities need to be there to satisfy a core user set,
> and also
> because, as you learn more about the internet, it turns out direct
> edit of the URL field is achingly useful.
I agree that editing URLs is very useful, and I don't want to take it
away (thus the Open button, which is just as fast), but also quite rare,
and something very few users do at all. It's just faster to click on the
company logo than to select everything after the hostname and click
"Del" on the keyboard.
In many cases, even on many Wikis, the URL is hard to read, so most
people either completely ignore it or do only minimal parsing. *This* is
what got us this phishing problem. It must be dead-simple and obvious
how to read it, and always work for all users.
In other words: *Either* you make something the identifier *or* usable
for humans, but the two don't go terribly well together, and you surely
can't create a system which has seriously bad effects when the user gets
the ID wrong just once, but that's exactly what we did. The Internet
specs define the URL as a technical identifier. Some sites use it as the
latter, some try hard to make it human-readable. Some users can parse
them and pay attention to them, others are scared by the bad cases and
ignore it. And yet other users are so new to the Internet that they are
happy to have found a holiday recommendation site ("*They* said this is
a great hotel" - "Who is 'they'?" - "The people there on that site I
went to" - "Again: *who*?" - Silence).
>> * Put an "open" button to the left of the domain field. Clicking on
>> it shows the current URL in a textfield (either in dialog url
>> toolbar), in a way so that the user can easily either edit the URL
>> or enter a new one.
>
> Or do clever things when the user gestures that they want to enter an
> edit mode by moving the mouse, clicking in the text areas, etc.
Hm. May be an idea. Only thing is that I am skeptic about "clever"
software/UI :), it's not as predictable for users and thus usually
degrades usability more than explicit UI.
How about this:
* The urlbar shows the domain only
* The urlbar is editable, so an obvious way to manually enter URLs.
* The Open (or "Show") button makes the urlbar show the full url, so
the user can edit it. It's just as many clicks as right now - only
difference is that you have to click on the show button instead of
in the urlbar.
> As long as the resulting structure looks sort of like a URL, I don't
> think you're actually going to see this freakout, actually. I think
> you will if you take away their ability to quickly cut, paste, and
> edit the URL.
Yes. As I said, I don't want to. The button takes are of "quickly",
"cut" and "edit", but not "paste" and drag&drop. If the domain field
were editable, it would also be an obvious drop target.
> Anyway, we're into UI design, which I promised myself I wouldn't do in
> this forum, but I just find this idea of making the location bar
> smarter and more useful so *intriguing*! :)
OK :)
Ben
Gervase Markham
> In fact, I'm not sure there *can* be that kind of metadata. Anything
> that declares AOL or PayPal as "safe" is failure of the system :).
[Leaving aside the discussion of whether "safe" is the right term...]
Really? I've never heard of either company stealing people's money.
They may take it off you in accordance with their agreement you made
with them, and you may think that's unfair, but that's an entirely
different thing.
If any website can be declared "safe" in any sense, then a legitimate
bank or Paypal must fall into that category.
Gerv
Gervase Markham
> procedures and suggest / build a auditor profile and realistic
> requirements of the audit firm.
What makes you say that Webtrust's own criteria for what constitutes an
acceptable audit firm are not "realistic"?
> This would most likely result in more
> CAs (and not only StartCom) being able to issue certificates according
> to this guidelines and as some suggested "improve" the whole
> Internet...It would however also result in more transparency what
> auditing of the CAs concerns. (Or does anyone know how CAs are audited
> in first place? If not, so how does anyone know if it is sufficient?)
The Webtrust audit criteria, both for the normal audit and the EV one,
are public. So we know how they are audited, and can come to a judgment
about whether it is sufficient.
> Actually membership isn't the most important thing at the CA/Browser
> Forum, but they demonstrated their attitude in the best way they could!
> StartCom doesn't need the membership, it needs to be able to issue the
> same certificates...
I suspect that one requires the other - at least, if you want your certs
to be accepted as EV in IE.
Gerv
Gervase Markham
> On 2/14/07, Ben Bucksch <ben.buck...@beonex.com> wrote:
>> I still think that showing *only* the second level domain - *not* as
>> part of the URL, which is technical glibberish for most people - is -
>> next to bookmarks - the best approach against phishing, even though a
>> dramatic change in browser UI. I *don't* think that just bolding the URL
>> is enough.
>
> Interesting. I'd buy that argument, really.
I think the meta-question is: should an unfocussed URL bar always, on
principle, show all parts of the URL (length issues aside), even if they
are styled differently? If not, which do we remove or change, and when?
I think a focussed URL bar has to be pretty close to a text field in
function, even if different bits of the URL are separated, bolded,
highlighted or whatever in some way. Moving away from this breaks
various type-into, copy and paste scenarios which people use a lot.
But, trying to square the circle, I also think it's important that text
in the URL bar not shift around when you focus it.
>> * Show domain very prominently in the middle of the urlbar, so that
>> even a normal user can't miss it. Not as textfield, but
>> non-editable, selectable, bold label.
>
> I'd actually keep this in the location bar, but give it a very
> button-like UI treatment. That way it also acts as a "snapback" to the
> root domain.
If it's button-like, presumably that would mean you can't click it to
edit it?
>> * Show the EV cert holder, if available, next to the domain. No
>> other special treatment of EV.
>
> For EV I was going to suggest that we don't show the domain name, but
> instead show the name of the cert holder. So [Paypal, Inc.].
It would need to be [Paypal, Inc. (US)], for important disambiguation
purposes. The idea is that a combination of the C field (country) and
the O field (organisation) is pretty much unique. Given that we are
definitely talking about countries rather than languages, we could use
flags here if we wanted.
>> * Keep search field
>
> Yeah, that's not going anyplace soon. ;)
Unless we decide to combine the search field and the URL field? But
perhaps that possibility is incompatible with all these other ideas.
> As long as the resulting structure looks sort of like a URL, I don't
> think you're actually going to see this freakout, actually. I think
> you will if you take away their ability to quickly cut, paste, and
> edit the URL.
Yes. Form doesn't matter too much if the capabilities are there. There's
no problem with the URL bar e.g. permanently showing some space between
the domain and the rest of the URL, as long as the space doesn't show up
when I select the URL and copy it.
> Anyway, we're into UI design, which I promised myself I wouldn't do in
> this forum, but I just find this idea of making the location bar
> smarter and more useful so *intriguing*! :)
Where should we be having this discussion? Do you want to move over to
m.d.a.firefox?
Gerv
Ben Bucksch
> Ben Bucksch wrote:
>> In fact, I'm not sure there *can* be that kind of metadata. Anything
>> that declares AOL or PayPal as "safe" is failure of the system :).
>
> [Leaving aside the discussion of whether "safe" is the right term...]
>
> Really? I've never heard of either company stealing people's money.
I have.
AOL is known to not let subscribers cancel, but just to continue drawing
money. There have been tons of reliable reports for that, both in US and
Germany.
PayPal randomly freezes accounts without good reason and won't react or
solve for months, many reports on that. They completely ignore it when
your account gets robbed without your fault. See what happened to the
AbiWord project below.
And that's not even starting with things like that they are taking
ridiculous amounts of money for e.g. currency conversion, way above what
banks ask for, etc.pp.. You end up with considerably less money than you
have been sent, even when considering the fees you've been told when
signing up.
* Paypal Warning <http://www.paypalwarning.com>
* NoPayPal <http://www.nopaypal.com/>
* AboutPaypal - Class action, court cases <http://www.aboutpaypal.org>
* What happened to AbiWord
<http://www.abisource.com/mailinglists/abiword-dev/02/Oct/0422.html>
* Paypal Victims Club <http://groups.yahoo.com/group/nopal-paypal/>
> If any website can be declared "safe" in any sense, then a legitimate
> bank or Paypal must fall into that category.
There's a *huge* difference between a legitimate bank and PayPal, that's
the problem with PayPal. In fact, some argue that PayPal's business is
illegal exactly for that reason (PayPal acting as bank, but not
fulfilling the law requirements for banks).
> They may take it off you in accordance with their agreement you made
> with them, and you may think that's unfair, but that's an entirely
> different thing.
No, that's the point, disagree. If they write "we'll take 50% of any
money you have in your account, on every Friday the 13.", and only tell
me so somewhere deep in 20 pages of fine print, that's "in accordance
with their agreement", but it's still stealing money from me. Some of
PayPal's rules come close to being as ridiculous as my mockup rule above.
That company should *not* be marked "safe to do business with" in the
browser, because PayPal simply *is* not safe. That may mean we can't
mark any company as "safe", but that was my point.
Boris Zbarsky
> Ben Bucksch wrote:
>> In fact, I'm not sure there *can* be that kind of metadata. Anything
>> that declares AOL or PayPal as "safe" is failure of the system :).
> Really? I've never heard of either company stealing people's money.
You haven't listened very hard. PayPal has _definitely_ done this in the past.
In fact, they've done it to me (randomly "lose" an account that had money in
it). It wasn't a lot of money, but still...
Now this was a while back, and maybe they've reformed. I wouldn't know -- I
refuse to use PayPal since then.
-Boris
Ben Bucksch
> we could use flags here if we wanted.
Some patriotism in the browser. Yay!
BTW: My worry is that US companies would be preferred by US citizens,
i.e. it would hurt foreign companies which do a lot of business in the
US. With flag even more than with "US". However, I understand that the
country is important, for name uniqueness and applicability of law and
the EV checks performed.
> Unless we decide to combine the search field and the URL field?
That's an option, but I think a bad one. I think the experiences with
the URLbar in Netscape 6 have teached us that.
Heikki Toivonen
> AOL is known to not let subscribers cancel, but just to continue drawing
> money. There have been tons of reliable reports for that, both in US and
> Germany.
>
> PayPal randomly freezes accounts without good reason and won't react or
> solve for months, many reports on that. They completely ignore it when
> your account gets robbed without your fault. See what happened to the
> AbiWord project below.
Much as I dislike both, for a standard such as EV I think conviction in
court would be needed to say they are not "safe".
--
Heikki Toivonen
Ben Bucksch
> Much as I dislike both, for a standard such as EV I think conviction in
> court would be needed to say they are not "safe".
Probably. But I was talking about our browser UI here, not the EV
standard. I was just saying that we should not display /anything/ that
implies "safe", at least not for companies like these.
Eddy Nigg (StartCom Ltd.)
how exactly EV is already presented and marketed. Quoting from
http://www.verisign.com/ssl/ssl-information-center/faq/extended-validation-ssl-certificates.html
it says:
/What are the benefits of Extended Validation SSL to Web site
owners?/
/If your site has the “green bar” in IE 7 and your competitor’s site
does not, you appear to be more trusted and more legitimate. That’s a
competitive advantage in the world of e-commerce......When customers see
the green bar and the name of your security vendor, they can interact
with you online, with confidence./
This and more of the same can be expected in the context of EV...and
therefore you might be right with your suggestion below! So even your
suggestion would serve our interest because of the other objections we
have to the proposed EV standard, but right now I'm dead serious, that
this could backfire dangerously under certain circumstances!
Eddy Nigg (StartCom Ltd.) wrote:
> Ben Bucksch wrote:
>>
>> Probably. But I was talking about our browser UI here, not the EV
>> standard. I was just saying that we should not display /anything/
>> that implies "safe", at least not for companies like these.
>>
> I can't share the same experience concerning Paypal and similar sites,
> but poking around the suggested web sites from the previous mail, some
> information seems to be quite shocking! Should anything of this be
> true (even partly), than this /might/ have legal consequences for any
> browser vendor, if the the same browser suggests, that the site in
> question can be /"trusted'/ or is /"safe"/ to use...I'm not a lawyer
> and I'd suggest in any case to get some legal advice prior to making
> any changes which might brake the current flat system and which would
> suggest anything along these lines...
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
Gervase Markham
> BTW: My worry is that US companies would be preferred by US citizens,
> i.e. it would hurt foreign companies which do a lot of business in the
> US.
Governments often promote the notion of "buy British" (or equivalent)
even without our input. I agree there might be a side effect; but we are
merely revealing what was always true.
>> Unless we decide to combine the search field and the URL field?
>
> That's an option, but I think a bad one. I think the experiences with
> the URLbar in Netscape 6 have teached us that.
I agree that if we make these other changes, it isn't going to work.
See the discussion I just started in mozilla.dev.apps.firefox on the
future of the location bar.
Gerv
Ben Bucksch
> Ben Bucksch wrote:
>> BTW: My worry is that US companies would be preferred by US citizens,
>> i.e. it would hurt foreign companies which do a lot of business in
>> the US.
>
> Governments often promote the notion of "buy British" (or equivalent)
> even without our input. I agree there might be a side effect; but we
> are merely revealing what was always true.
You can't clearly tell that www.beonex.com is German. With a German
flag, these "Buy British" buyers or American patriots will be highly
visibly alerted that they're deserting when they use my products.
> See the discussion I just started in mozilla.dev.apps.firefox on the
> future of the location bar.
OK.
Gervase Markham
>> Eddy Nigg (StartCom Ltd.) wrote:
>>> So personally I'm very much in favor of *opening* up the *audit*
>>> procedures and suggest / build a auditor profile and realistic
>>> requirements of the audit firm.
>>
>> What makes you say that Webtrust's own criteria for what constitutes
>> an acceptable audit firm are not "realistic"?
> and which not (Or do I really have to dig up some spicy stories about
> Ernst&Young or KPMG?),
No - but _we_ (Mozilla) do. We need to make sure that the audit firm a
CA uses is trustworthy to assess under the Webtrust guidelines. Who
better to decide that than the people who wrote the guidelines?
>> The Webtrust audit criteria, both for the normal audit and the EV one,
>> are public. So we know how they are audited, and can come to a
>> judgment about whether it is sufficient.
> Can you point me to the audit criteria for EV please?
http://www.cabforum.org/WebTrustAuditGuidlines.pdf
Linked from the front page of cabforum.org.
> Well, I would prefer to concentrate on Mozilla in this respect and leave
> IE to Microsoft for now...I think Mozilla should make sure, that all CAs
> in the Mozilla CA store will be able to issue EV certificates and
> receive the same treatment according to the Mozilla CA policy.
I don't think that should be the goal. Because of the nature of EV (and
the additional resources and requirements necessary for doing the extra
validation) it may well be that there are some CAs who do not have the
resources to take it on, or cannot make a business case for doing it.
Saying that all CAs in the store should be able to issue EV is basically
saying "EV should be the same as what we have now".
I agree there should not be any unnecessary barriers.
Gerv
Eddy Nigg (StartCom Ltd.)
> We need to make sure that the audit firm a CA uses is trustworthy
> to assess under the Webtrust guidelines.
> Who better to decide that than the people who wrote the guidelines?
http://www.mozilla.org/projects/security/certs/policy/
>
> http://www.cabforum.org/WebTrustAuditGuidlines.pdf
Excellent! Thanks!
>
> I don't think that should be the goal. Because of the nature of EV
> (and the additional resources and requirements necessary for doing the
> extra validation) it may well be that there are some CAs who do not
> have the resources to take it on, or cannot make a business case for
> doing it. Saying that all CAs in the store should be able to issue EV
> is basically saying "EV should be the same as what we have now".
Absolutely not! I disagree with you strongly!
Extra validation (maybe they aren't that "extra" anyway - who says that
CAs don't perform and offer similar or better validations already
today?) can be performed by a CA wishing to do so, but you should
perhaps read http://financialcryptography.com/mt/archives/000835.html
And yes, I suggest that any CA confirming to the Mozilla CA policy
should be able to issue all certificates of any strength, including EV.
This absolutely doesn't mean "the same as what we have now". It's the
verification procedures which might make the difference, not the cartel
webtrust audit!
>
> I agree there should not be any unnecessary barriers.
Nice...now we just disagree on what means "unnecessary" :-)
Florian Weimer
> Florian Weimer wrote:
>> By the way, much of this could be sidestepped if CAs were required to
>> publish all the evidence they have gathered together with the EV
>> certificates they issue (in a complete list of certificates, not just
>> those certificates that are actually used on popular sites). This
>> way, everyone could review the strength of each CA's EV process. The
>> peer pressure should be sufficient to ensure that everyone keeps their
>> backyards clean.
>
> An interesting idea; but wouldn't there be confidentiality problems?
Sure, but that's the point. The exact procedure a CA is following is
a significant business asset because you want to do as little as
possible and get away with it (in all senses: PR, liability,
compliance with regulations etc.).
If you mean subject confidential information, than I share your
concern to some extent.
> Some of the things CAs might need to check might be things which a
> company quite reasonably does not want to be made public.
In such cases, the CA can still document the type of information, and
the reason why it is not published. This is still much better than
not publishing anything.
horr...@yahoo.com
PAYPAL !! Please Read on, this will change your life!!!!!
LET ME TELL YOU THAT THE FOLLOWING SCHEME WILL CHANGE YOUR LIFE IF
READ CAREFULLY AND FOLLOWED HONESTLY.
THOUSANDS HAVE EARNED AND MUCH MORE ARE EARNING .DONT MISS OUT THIS
ONE.
PAYPAL VERIFIES THAT THIS $6 INVESTMENT SCHEME IS 100% LEGAL AND IS A
BIG HIT THIS YEAR. SEE THEIR NOTE BELOW OR ASK THEM DIRECTLY... THIS
SCHEME MIGHT TAKE 15-30 MINUTES AND JUST $6, BUT IT IS 100% WORTH IT
TO MAKE THOUSANDS SO QUICKLY. THIS IS NOT ANOTHER SCAM THAT TAKES
LOTS OF YOUR HARD EARNED MONEY; THIS IS A NO RISK INVESTMENT THAT
WILL MAKE YOU THOUSANDS OF DOLLARS VERY EASILY AND QUICKLY.
>From PayPal:
"Dear Member, it has come to our attention that there is a paypal
scheme floating around at the moment you may have heard or seen the
$6 scheme. You may have even taken part in it. Well we have been
asked a lot of questions about this scheme. The answer is yes, it
does work and yes it is safe to use, providing you follow the rules.
It is legal and has made a big hit on the internet this year. If you
would like to take part in this scheme or would like a bit more
information ,then please see the attached file that was kindly
donated to us. Thank you for using PayPal!"
TURN $6 INTO $15,000 IN ONLY 30 DAYS...HERES HOW.
"What an amazing plan! I followed your instructions just 3 weeks ago,
and although I haven't made 15 grand yet, I'm already up to $9,135.
I'm absolutely gob smacked." -Pam Whittemore , Ohio
Let's get started, just follow the instructions exactly as set out
below and then prepare yourself for a HUGE influx of cash over the
next 30 days! Here's what you need to do. . .
REQUIREMENTS
..1) an email address ..2) a Premier or Business PayPal account
STEP ..1 - Setting up your FREE PayPal Account
It's extremely safe and very easy to set up a FREE PayPal account!
Copy and paste this to the address bar (notice the secure "https"
within the l
STEP ..2 - Sending PayPal money "It is an undeniable law of the
universe that we must first give in order to receive."
Now all you have to do is send $1.00 by way of PayPal to each of the
six email addresses listed below.
Make sure the subject of the payment says... *PLEASE PUT ME ON YOUR
EMAIL LIST* (this keeps the program 100% legal.. so please don't
forget!)
Note: (If you do not see the full email address for the 6 members,
just hit reply To this email and they will show up.)
(Just in case you still haven't opened your PayPal account yet, use
this link to open one in your name),
1. pridefightgear@ yahoo.com
2 ladybu...@yahoo.com
3. micheal...@yahoo.com
4. thegm...@gmail.com
5. abys...@yahoo.com
6. horr...@yahoo.com
Remember, all of this is ABSOLUTELY LEGAL. You are creating a
service!
If you have any doubts, please refer to Title 18 Sec. 1302 & 1241 of
the United States Postal laws.
STEP ..3 - Adding Your Email Address
After you send your six $1.00 payments, it's your turn to add your
email address to the list!
Take the ..1) email off the list that you see above, move the other
addresses up one (6 becomes 5 & 5 becomes 4, etc) then put YOUR email
address (the one used in your PayPal account) as ..6) on the list.
**MAKE SURE THE EMAIL YOU SUPPLY IS EXACTLY AS IT APPEARS IN YOUR
PAYPAL ACCOUNT.**
STEP ..4 - The Pure Joy of Receiving PayPal Money!
You are now ready to post your copy of this message, to at least 200
newsgroups, message boards, etc. (I think there are close to 32,000
groups)
All you need is 200, but remember, the more you post, the more money
you make - as well as everyone else on the list! In this situation
your job is to let as many people see this letter as possible. So
they will make you and me rich!!!! You can even start posting the
moment your email is confirmed. Payments will still appear in your
PayPal account even while your bank account is being confirmed.
HOW TO POST TO NEWSGROUPS & MESSAGE BOARDS
Step..1) You do not need to re-type this entire letter to do your own
posting. Simply put your CURSOR at the beginning of this letter and
drag your CURSOR to the bottom of this document, and select 'copy'
from the edit menu. This will copy the entire letter into your
computer's temporary memory.
Step ..2) Open a blank 'Notepad' file and place your cursor at the
top of the blank page. From the 'Edit' menu select 'Paste'. This will
paste a copy of the letter into notepad so that you can add your
email to the list.
Step ..3) Save your new Notepad file as a .txt file. If you want to
do your postings in different sittings, you'll always have this file
to go back to.
Step ..4) Use Netscape or Internet Explorer and try searching for
various newsgroups, on-line forums, message boards, bulletin boards,
chat sites, discussions, discussion groups, online communities, etc.
EXAMPLE: go to any search engine like yahoo.com, google.com,
altavista.com, excite.com - then search with subjects like ?
millionaire message board? or ?money making message board? or ?
opportunity message board? or ?money making discussions? or ?business
bulletin board? or ?money making forum? etc. You will find thousands
& thousands of message boards. Click them one by one then you will
find the option to post a new message.
Step ..5) Visit these message boards and post this article as a new
message by highlighting the text of this letter and selecting 'Paste'
from the 'Edit' menu. Fill in the Subject, this will be the header
that everyone sees as they scroll thru the list of postings in a
particular group, click the post message button. You're done with
your first one! Congratulations! THAT'S IT!! All you have to do is
jump to different newsgroups and post away. After you get the hang of
it, it will take about 30 seconds for each newsgroup!
REMEMBER, THE MORE NEWSGROUPS AND/OR MESSAGE BOARDS YOU POST IN, THE
MORE MONEY YOU WILL MAKE!! BUT YOU HAVE TO POST A MINIMUM OF 200**
That's it! You will begin receiving money within days!
**JUST MAKE SURE THE EMAIL YOU SUPPLY IS EXACTLY AS IT APPEARS ON
PAYPAL.**
So can you afford $6?? And see if it really works?? I think so?
People have said, what if the plan is played out and no one sends you
the money? So what are the chances of that happening when there are
tons of new honest users and new honest people who are joining the
internet and newsgroups everyday and are willing to give it a try?
Estimates are at 20,000 to 50,000 new users, every day, with
thousands of those joining the actual Internet.
Remember, play FAIRLY and HONESTLY and this will work. This really
isn't another one of those crazy scams! As long as people follow
through with sending out $6.00, it works!
Ka-Ping Yee
> > part of the URL, which is technical glibberish for most people - is -
> > next to bookmarks - the best approach against phishing, even though a
> > dramatic change in browser UI. I *don't* think that just bolding the URL
> > is enough.
>
I'd like to know what became of this discussion. Most of the user
training surrounding phishing seems to be about teaching users how
to correctly parse the top two levels of the domain out of the URL,
and that's a silly thing to waste effort trying to train humans to
do when it's a trivial task for the computer. Emphasizing or
isolating the top two levels of the domain in the UI, though non-ideal,
would be a positive move; IE would find itself playing catch-up to
the Firefox UI yet again.
-- ?!ng
Gervase Markham
> I'd like to know what became of this discussion. Most of the user
> training surrounding phishing seems to be about teaching users how
> to correctly parse the top two levels of the domain out of the URL,
> and that's a silly thing to waste effort trying to train humans to
> do when it's a trivial task for the computer. Emphasizing or
> isolating the top two levels of the domain in the UI, though non-ideal,
> would be a positive move; IE would find itself playing catch-up to
> the Firefox UI yet again.
Except that "top two levels" is not the right heuristic. See
http://wiki.mozilla.org/Gecko:Effective_TLD_Service
for what we are actually doing. And the Locationbar2 extension for some
UI ideas.
Gerv
Ka-Ping Yee
> Ka-Ping Yee wrote:
> > Emphasizing or
> > isolating the top two levels of the domain in the UI, though non-ideal,
> > would be a positive move; IE would find itself playing catch-up to
> > the Firefox UI yet again.
>
> Except that "top two levels" is not the right heuristic. See
> http://wiki.mozilla.org/Gecko:Effective_TLD_Service
Yes, that's exactly right. I spoke sloppily.
> And the Locationbar2 extension for some UI ideas.
I recall these ideas being discussed -- what has become of them?
Is there a specific design on the table at the moment, or is it
still a fuzzy idea? Is there a timeline?
Curiously,
-- ?!ng
Gervase Markham
> I recall these ideas being discussed -- what has become of them?
> Is there a specific design on the table at the moment, or is it
> still a fuzzy idea? Is there a timeline?
Dao recently attached a copy of Locationbar2 to the bug report for UI
review. This is where the rubber hits the road, and have to finally
decide if we want to do this or not. I'm trying to get some time from
beltzner and johnathan to look at it.
Gerv