[EMAIL PROTECTED] wrote:
Let me respond to a couple of good points in the prior string.

On the question of which type of cert (manual, O field certs or
automated CN field certs) would give a defrauded consumer the greater
chance of finding the fraudster:

I should interject here to note that I'm not necessarily championing manual verification over automated verification here. I'm saying that we need to assess certs according to how likely it is that we can trace the cert back to a real individual, not as to how the data required for such tracing was gathered.


GeoTrust's automated vetting ends
up with about the same number of verifiable identity touchpoints with a
site owner as manual vetting does. We have confirmed domain name,
WhoIs data, verified phone number (so we can trace back through phone
company records),

Has GeoTrust ever done this? Are there not laws which prevent you getting access to phone company records?


Do you check before issuing the cert that the phone number isn't a disposable mobile, "personal number", payphone, etc.? What happens if it's an international number?

and credit card used to purchase the automated cert
(we can track back that way as well).

Assuming it's not stolen?

The manual vetting process has
pretty much the same touch points (or fewer) - and the paper that was
presented for a manual, O field cert may be pretty worthless for
purposes of finding a fraudster if it was copied from a real
company's corporate filings in the public record,  or is just the
paper for a phony shell corporation.

I certainly agree that faxed or even posted paper credentials don't carry much weight. Good printers are cheap.


Second, on the value of manually vetted certs.  My paper doesn't say
all manually vetted certs are bad in the O field - it's probably
relatively accurate in 90 percent of cases, maybe more.  But it is (or
can be) definitely wrong in 1 or 2 percent of cases, or more.  That is
a perfect phishing environment if consumers believe the field is
accurate and can be used for trust decisions.

Sure. I'm happy to give the O field up as a lost cause. My concern is that _somewhere_ there's some information that lets you track the cert back to a company or human being. It doesn't need to be in the cert itself.


Some might say "make manual vetting more vigorous", but then certs
might cost $1,000 or more (need corporate resolutions, contacts with
registered agent, site visit, review of financial statements to make
sure it is a "real" company and not a shell) along with subjective
judgments on which business entities are real and which are virtual
only. And of course, this would have to be repeated annually (and
maybe a process is needed to revoke the certificate mid-year if the
business is liquidated, etc.)

Sounds good to me. I'd certainly want my bank to have a cert that was verified this much. $1,000 is small change to a bank. And I'd want my browser to tell me so, so that anyone who wanted to pretend to be my bank would have to go through the same process.


A lot of small businesses would just
drop SSL in response.

Only if there was a single level of verification applicable to all certs, and that it cost $1000+.


I'd rather have SSL be cheap and ubiquitous, and also display
verified third party reputation and performance data for the business

How would such data be classed as "verified"? How does it differ from the business identity verification? Would one have to trust the provider of the data?


by tying it to the only unique, certain attribute in a cert - the CN
field showing fully qualified domain name. Kind of like the eBay model
for sellers whose identities are otherwise not verified.

The eBay model only works if a) one trusts eBay, and b) eBay aggregates the views of a large number of people to come up with a trust number. This is not the same model as one where there's a single supplier of "verified third party reputation and performance data".


Gerv
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security

Reply via email to