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

Hi Phil,
 
I'm glad we agree about favicons.  I readily concede X.509 logos are
more secure than favicons.  However, unless there is a central authority
and process in place to ensure no two sites use visually similar or
indistinguishable images in their EV certificates, these logos should
not be relied upon as identity cues.
 
My reason for bringing this up is I've become aware many EV issuers and
RPs are planning to use these logos for branding and identity assurance
purposes.
 
Mike

  _____  

From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
Sent: Wednesday, April 25, 2007 12:35 PM
To: McCormick, Mike; public-wsc-wg@w3.org
Subject: RE: ACTION 181: Summary of EV certificate discussion, prototype
recommendation


Well naturally I totaly disagree with the second recommendation.
 
If the issuer has taken appropriate steps to authenticate certificate
subject information and there are approriate accountability controls it
is appropriate to display it. 
 
And the certificate issuer can surely be trusted to authenticate their
own brand information. 
 
A favicon is objectionable because it is not authenticated and the use
is not accountable. Favicons are not intended to be an authentication
cue, are not secured as such but are easily confused as being so. An
authenticated logotype is explicitly intended for that purpose and the
issuing controls governing their use are designed to ensure that the
level of security is appropriate.
 
 
But since the recommendation does not mention logotype information at
all and it did not come up in the conversation I don't see where the
justification for a prohibition would be.
 



  _____  

	From: michael.mccormick@wellsfargo.com
[mailto:michael.mccormick@wellsfargo.com] 
	Sent: Wednesday, April 25, 2007 1:20 PM
	To: public-wsc-wg@w3.org
	Cc: Hallam-Baker, Phillip
	Subject: 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.