Not sure what you are getting at here.

Sorry for being opaque ... sometimes people think that statements made by certificatess need to be interpreted by 90 page documents and people with both accountancy degrees and crypto degrees. Which is of course meaningless.

In this case it is very simple:

.... 1. The site is doing something "dodgy" like asking for your SSN.

.... 2. Yet, Verisign has issued it a cert, with a seal.

.... 3. Click on the seal, and Verisign confirms that "TRUSTEDID INC as a valid business."

You don't need EV. Verisign did everything you need. You can take that statement to court. No higher standards are needed, no better statement is needed. Which is as it should be.

> What was the need for EV then, again?

It makes the URL bar go GREEN*. Customers feel SAFER. They will BUY MORE FROM YOU instead of the local shopping mall or other websites.

(* If they run the latest UBER-SECURE browser on the latest UBER-SECURE version of Windows, available free with every new PC. Get yours now!)

> Verisign did everything you need.

They did not check if the company listed their address as the local cemetery!

On the other hand, I think this level of strictness did not get included in the final EV spec... so yes you would be no better off with EV... Ah well.

Sure. this is a "high assurance" cert and verisign makes that statement on the basis of the vetting they performed.

The problem is that CAx makes similar statements but performs slightly less vetting. CAy makes similar statements but performs slightly less vetting. CAz makes similar statements but performs slightly less vetting.

EV tries to rein that in. Are you saying that EV should be based on verisign's older practices not the new persumably deeper vetting?

Right, that's a good description of the problem. The solution is however not in a new certificate form.

Problem: browsers display all certs as if they were the same. But, not all certs are the same, far from it. No point in discussing this, it is somewhat impossible to make them the same. Hell freezes over, and all that.

Solution: display the CA. Then the users can start to get used to "Verisign says X which means Y" and "GoDaddy says X which means Z."

Now, EV may try and do that; but the important point is that it can be done regardless. It is the browsers that are in control, and they can display the CA any time they like. It's a patch, a couple of days of coding. A no-brainer.

We simply don't need EV, we need to get the browsers to move.

Now, we could argue that EV is the only way we'll get the browsers to change. Except, EV only covers a small segment; leaving the rest unprotected. It is a bad solution because it tries to create a false discrimination where there is none needed, and it does so at fairly significant cost.

If or when EV rolls out, then we will still need the browsers to display the CA, so what was the point of EV, again?

The browsers should show the CA. They should also tag domain validation certificates differently.

a lot of work the past couple years has gone into countermeasures to phishing ... original SSL was suppose to provide for both 1) is the website you think you are talking to, really the website you are talking to and 2) hide information will be transmitted over the internet.

some what related recent comment here on Extended Validation certificates
http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

however, recent news items:

Phishing overtakes viruses and Trojans
http://www.astalavista.com/?section=news&cmd=details&newsid=3321
Phishing overtakes viruses and Trojans
http://news.com.com/2100-7349_3-6154716.html?part=rss&tag=2547-1_3-0-20&subj=news
Phishing overtakes viruses and Trojans
http://news.com.com/Phishing+overtakes+viruses+and+Trojans/2100-7349_3-6154716.html?tag=nefd.top

a recent comment here
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"

and misc. past posts mentioning mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

we had looked at the whole domain name certification process ... when we were doing some consulting for a small client/server startup that wanted to handle payments on servers ... and had this technology called SSL ... old reference
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

part of the issue mentioned many times before is the economics to the merchant related to fraud. the merchant is already paying a heavy fraud burden effectively related to transaction insurance in form of interchange fees. the digital certificates don't provide any additional help in that area ... that was one of the reasons we coined the term "comfort certificates" way back when.

start of one such tread, long ago and far away
http://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates

and the certificates being somewhat orthogonal to basic issues also shows up in this old post on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

aka merchant is already paying a hefty bill ... the certificates provide little practical benefit to the merchant ... so it is difficult for merchant to show any ROI for spending large amounts of money on certificates ... which then means that certification authorities have hard time charging a lot for certification activities. this is my past observation that primary direction for digital certificates left is to move into the low-value/no-value market segment (which further reduces justification for doing a lot related to the issurance of certificates).
a few old posts on the subject:
http://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

and as i've frequently repeated in the past ... the miriad of vulnerabilities and exploits was behind a lot of the x9.59 financial industry standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

when in the mid-90s, the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments.

it would be more logical to drop back to clients being able to get "on-file" public keys directly from the domain name infrastructure for providing assurance that the website that the browser things it is talking to, is really the website the browser is talking to (and provide for slimmed down SSL providing for information hiding while in transits the internet) ... misc. past posts related to that subject
http://www.garlic.com/~lynn/subpubkey.html#catch22

and have the fraud and integrity issues related to types of transactions integrated into existing infrastructure operations for handling fraud and integrity issues.

a fundamental problem in security operations crops up trying to address issues in adhoc and hodge-podge manner ... which leaves a lot of openings and cracks for the attackers.