Re: ACTION 181: Summary of EV certificate discussion, prototype recommendation

I slammed it in the wiki. You might want to pretty it up a bit:

http://www.w3.org/2006/WSC/wiki/ExtendedValidationCerts

Now others can modify the proposal :-). 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Hallam-Baker, Phillip" <pbaker@verisign.com> 
Sent by: public-wsc-wg-request@w3.org
04/25/2007 10:51 AM

To
<public-wsc-wg@w3.org>
cc

Subject
ACTION 181: Summary of EV certificate discussion, prototype recommendation






Extended Validation (EV) Certificates are X.509v3 certificates that are 
issued in accordance with minimum authentication criteria defined by the 
CA-Browser Forum, as demonstrated by a Web Trust audit of the issuer. 
When certain browsers (currently IE7 with the anti-phishing filter enabled 
or Firefox with a plug-in) visit a site secured with SSL and an EV 
certificate an enhanced user experience is presented. Currently in IE7 
this user experience consists of the address bar turning green and the 
certificate subject and issuer being displayed alternately next to the 
address bar. Advertising and User education programs for EV certificates 
frequently use phrases such as 'Green for Go'.
The current CAB-Forum criteria are specified at: 
http://www.cabforum.org/EV_Certificate_Guidelines.pdf
The core principle of EV certificates is to assure the relying party that 
there is accountability. The EV issuing criteria require a certificate 
issuer to verify that the organization specified in the certificate 
subject exists as a legal entity, that the physical contact address is 
valid, that the party making the application is authorized to do so by the 
specified subject, that the applicant has control of the domain name 
specified in the certificate and that the applicant has possession of the 
private key corresponding to the specified public key.
If the issuance process should fail the certificate issuer is to be held 
accountable, hence the display of the issuer name in the EV security 
experience.
An EV certificate does not guarantee that a vendor selling a $3000 plasma 
TV will deliver a product that works or even that the TV will be delivered 
at all. But an EV certificate does guarantee that either the vendor can be 
held accountable for the default or the certificate issuer held 
accountable for the failure of their authentication program.
In addition to requiring minimum authentication standards and a WebTrust 
audit, the CABForum guidelines require CAs to implement certain technical 
measures. Certificates must conform to a specific profile of the X.509v3 
and PKIX standards. Wildcard certificates are not permitted, the maximum 
validity interval is one year, a means of efficient revocation must be 
supported and certain minimum key sizes must be employed. These measures 
are generally consistent with community consensus amongst network security 
specialists.
Although the EV guidelines do not mandate support for publication of 
status information by OCSP, accountability of the certificate issuer 
creates a significant incentive to do so. 
While EV certificates are designed to be compatible with the existing 
deployed base of browsers the use of EV makes use of certain protocol 
extensions which are already highly desirable to be even more desirable. 
In particular support for the certificate host identification extension 
and OCSP token stapling. 
Although the EV security experience in IE7 is designed to resist certain 
types of attack it is impossible to provide absolute guarantees of 
security on a platform that is not considered trustworthy. For example the 
IE7 does not allow users to add EV signing certificates to the root store. 
IE7 only presents the EV security experience if a root certificate that is 
countersigned by a Certificate Trust List signed by an offline root. An 
attacker can only circumvent this requirement by compromising the IE7 
executable.
Prototype recommendation:
Web clients SHOULD present a distinctive user experience in response to 
presentation of an EV certificate. Such a user experience SHOULD be 
guarded against emulation by browser content. The certificate subject and 
issuer SHOULD be displayed in the primary user experience.
In order to facilitate accessibility such a user experience SHOULD NOT use 
color alone, although if color is used the color green SHOULD NOT be used 
EXCEPT to indicate a positive condition and the color red SHOULD NOT be 
used except to indicate a negative condition.
In order to reduce the consuption of IPv4 addresses Web Clients SHOULD 
support the TLS host name identification extension on all SSL/TLS 
transactions regardless of whether an EV certificate is presented or not.
For efficiency, Web Clients SHOULD support the OCSP token stapling 
extension of TLS on all SSL/TLS transactions regardless of whether an EV 
certificate is presented or not.