Gervase Markham wrote:
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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
