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

This is excellent.  I'd like to propose a couple minor additions to
Phil's recommendation:
 
1. Web clients MUST verify revocation status of the EV certificate and
associated CA certificates as a precondition for displaying a positive
security signal.  Web clients SHOULD use OCSP protocol to perform this
check if it is available from the certificate issuer.
 
2. Web sites and certificate issuers SHOULD NOT use X.509 logographic
extensions to visually brand EV certificates.  Web clients SHOULD NOT
display logos attached to EV certificates.
 
Rationale:
 
1. It is critical to the credibility & trustworthiness of EV SSL that
compromised certificates can be revoked, and that revocation prevents
web clients from signaling positively.
 
2. See my earlier email about favicons.  My reasons for mistrusting
certificate logos are essentially the same: They are mistakenly viewed
as identity cues or security context signals by most users, which makes
them easily exploitable.  Also they blur the distinction between chrome
and content.
 
Thanks, Mike
 
P.S. In interest of full disclosure, Wells Fargo is a member of the CAB
Forum and will likely be a commercial issuer of EV SSL certificates.

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, April 25, 2007 9:52 AM
To: public-wsc-wg@w3.org
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.