Extended Validation Guidelines v1 Released!


I’ve talked several times in the past about Extended Validation SSL certificates and how they are a great step forward in establishing verified identity for websites. It is therefore with great pleasure that I am writing today about the official ratification of the EV Guidelines v1.0 by the Certification Authority/Browser (CA/B) Forum. You can read their announcement at http://cabforum.org.

Internet Explorer 7 has supported EV SSL Certificates since February 2007, based on the then current draft 11 guidelines. At the time only incorporated businesses and government entities were able to get an EV Certificate, which was a cause of concern for some. Version 1 of the guidelines (which are effective immediately) incorporates the experience from the past five months into the guidelines and expands the process so that now unincorporated businesses (such as sole proprietorships or general partnerships) can also get an EV certificate. Given the benefits that EV SSL brings with the verified identity information it offers to the users, there’s no good reason today for using a traditional SSL certificate instead of an EV certificate. (EV certificates work like traditional SSL certificates on older browsers).

IE7 users can already see the verified identity information (contained in the EV certificate and displayed in the address bar) on over 1,000 live sites on the internet – and with v1 of the guidelines, we expect the EV sites to keep growing even faster. But this is not just an IE story. Other browser vendors have committed to implementing EV support in upcoming versions, so their users can enjoy the same added protection that IE7 offers today.

And while EV is not a panacea, it is definitely a significant step forward and shows how the industry can work together to protect users.

Markellos Diorinos
Product Manager

Comments (12)

  1. Matt Ellis says:

    Good news. I rather like the green bar.

    Is there any way to get at this information when hosting the WebBrowser control? Can I know that a site has an EV cert and find out what the DN is?

    Cheers

    Matt

  2. That’s a great feature, just wish I had a great bank. 😉

  3. Please allow us also to programmatically access the EV SSL certificate data.

    A good start would be to update the DWebBrowserEvents2::SetSecureLockIcon event and add a special constant like secureLockIconSecure128BitEVSSL to indicate that a EV SSL certificate is being used.

  4. Paul R says:

    "Given the benefits that EV SSL brings with the verified identity information it offers to the users, there’s no good reason today for using a traditional SSL certificate instead of an EV certificate."

    I can think of two really good reasons that EV SSL certificates should not be used by everyone.

    1. They are prohibitively expensive ($2695.00 for two years from Verisign)

    2. They are not needed. If the certificate authorities did their job and verified people like they used to with the original certificate, we wouldn’t need a new one. In the late 90s you had to provide a Dun & Bradstreet number and jump through lots of hoops to get an SSL certificate for $395 / year. Today, if you pay the $99 / year, they give you one, no questions asked.

    The EV SSL Certificates are nothing more than an excuse for the certificate authorities to raise prices and gouge web site owners rather than fixing their own broken business practices.

  5. EricLaw [MSFT] says:

    @Viktor/Matt– Unfortunately, there’s no supported mechanism today to surface the certificate information out to the hosts of the WebOC or extensibility.

    @Paul R– Verisign isn’t the only certificate vendor offering EV certificates, and you’ll find that prices vary greatly between vendors.

    You are correct in noting that EV certificates are primarily useful in that they formally standardize the certificate validation practices required of each CA.

  6. Christian says:

    It’ bad that whereever I look there is only this marketing stuff.

    Does *ANYONE* know what such an EV certificate actually techincaly is???? How would I detect it myself if I parse the X509-certificate?

    How does IE7 know which certificates are EV? Can this be configured? Are there some OIDs hardcoded?

  7. Dave Bacher says:

    Christian:

    http://en.wikipedia.org/wiki/Extended_Validation_Certificate

    or

    http://www.answers.com/topic/extended-validation-certificate

    —cut—

    The primary way to identify an EV certificate is by referencing the Certificate Policies extension field. Each issuer uses a different object identifier (OID) in this field to identify their EV certificates, and each OID is documented in the issuer’s Certification Practice Statement.

    —cut—

  8. Christian says:

    Thanks, Dave!

    But do you also know where this list is stored?

    I mean, does IE7 hardcode these into its code? Even without an automatic update mechanism?

    This must be stored somewhere.

    And what if I use these OIDs myself in a company where I distributed root-certificates? How is "Verisign" or "Thawte" identitified by IE7 so that it knows which OID to look at?

  9. Dave Bacher says:

    I can’t answer how Internet Explorer handles it; I don’t work for Microsoft, the question asked was just "how do you identify an EV certificate," and thats how.

    I would expect the information is in a signed data source that is difficult for spyware to get at or modify, such as an Authenticode Signed DLL.

    The issue is how TLS works.

    As you know, the browser walks up the chain when you hit a TLS/SSL site.  If the entire chain is valid, then the certificate for the site you’re visiting is valid.

    The problem with that validation is that example.com can sign for fakebank.com, and example.com can be signed by verisign.com.  The chain, then, is valid and so TLS/SSL is allowed without a warning, even though it is a fake website.

    The idea is an EV certificate can only be issued by specific trusted certificates with specific OID’s.  

    Example.com can issue a certificate to fakebank.com, and can mark it with the OID, but because they aren’t the right trusted root authority, it will never have the green bar.

    If that all makes sense.

    I would think, because of this, you couldn’t allow the list to be easily modified.  If anyone other than Microsoft could change the list, that would seem (to me) to be a bad thing.

  10. It’s been a little over a year since we released IE7 on Windows XP and for Windows Vista, so I thought