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

I wish to amend my earlier recommendation #2.  I now feel sites &
issuers should freely use X.509 logographic extensions.  However:
 
 - I strongly recommend web agents only display subject or community
logos for high grade SSL certificates (such as EV) that vet certificate
requesters thoroughly.  (If www.phishingsite.com attaches Wells Fargo's
logo to their self-signed SSL certificate I don't want browsers to
display it.)
 
 - I recommend CAs who issue high grade SSL certificates (such as EV)
remind requesters that logographic imagery is subject to trademark laws
and the requester is responsible to ensure the logo they supply to the
RA is (a) legal for use in all countries and (b) visually
distinguishable from other logos.  (This may be a topic best discussed
in CAB Forum.)
 
 - In support of (b) above I think W3C might usefully provide some
guidelines for sound SSL logo design: Use company name (text) in
addition to imagery; don't rely on color to distinguish one company's
logo from another (for color blind users); etc.
 
In case anyone's wondering, I remain very concerned about favicons (as
currently implemented) and still plan to write up a detailed
recommendation on that topic.
 
Regards, Mike M.

  _____  

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


The proposal is for subject logos, not relying party logos.
 
Issuers of certificates cannot be the enforcement point but they can
determine whether the subject is accountable to an enforcement point.
And since the proposal is that the issuer logo be prominently displayed
as well the issuer is accountable for ensuring that this is the case.
 
I don't think that there is going to be any issuer that is prepared to
put their own brand next to a brand that is only accountable to an
enforcement point in a country that is a byword for corruption. 
 
But equally, if we do not have the confidence in our issuance process to
put the subject brand there we should probably not be issuing EV
certificates at all. If you are prepared to state that a certificate
holder is Bank of America then you should be prepared to communicate
that fact by the means that creates the most immediate, most direct
connection to the customer, or not at all.
 
 
Ten years ago the exact same set of concerns was raised concerning the
subject name. People only became comfortable with that business practice
because VeriSign was prepared to bite the bullet and step up to the
plate. 


  _____  

	From: michael.mccormick@wellsfargo.com
[mailto:michael.mccormick@wellsfargo.com] 
	Sent: Wednesday, April 25, 2007 3:21 PM
	To: Hallam-Baker, Phillip; public-wsc-wg@w3.org
	Subject: RE: ACTION 181: Summary of EV certificate discussion,
prototype recommendation
	
	
	I'm pretty okay with issuer logos.  I withdraw the phrase "and
certificate issuers" from recommendation 2.
	 
	My concern is more with relying party logos since users will
view them as site identifiers (much like favicons).  A legal process to
prevent ambiguity, resolve infringement, etc, would help but issuers
can't/won't be the enforcement point.
	 
	Cheers, Mike

  _____  

	From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
	Sent: Wednesday, April 25, 2007 1:03 PM
	To: McCormick, Mike; public-wsc-wg@w3.org
	Subject: RE: ACTION 181: Summary of EV certificate discussion,
prototype recommendation
	
	
	I think that first we have to separate the issue of subject and
issuer icons
	 
	As far as I am concerned any issuer that is not prepared to put
their own brand on their EV certs shouldn't be issuing them.
	 
	Issues such as ambiguity and possible confusion are of course
vital here. It does not follow that the EV process needs to be the sole
means of addressing these issues however. There is an existing legal
infrastructure to deal with those issues. What is critical here is
whether or not a certificate holder is or is not within the reach of
that legal infrastructure, whether there is accountability.
	 
	To paraphrase Judge Hands here: A criminal is unlikely to attack
an infrastructure if the expected reward is less than the cost of making
the attack plus the cost of getting caught times the probability of
being caught.
	 
	We limit the expected reward using efficient revocation. I would
be more than happy to accept a tight constraint on freshness of
recocation data (OCSP with TTL of 30 minutes or so). 
	 
	We engineer a situation where the cost of reducing the chance of
being caught to an acceptable level renders the attack uneconomic.
	 
	 
	Ambiguity is in many ways less of an issue where brands are
concerned than in the context of a subject name. There are multiple
companies that trade under the name 'Prince' but their logos are rather
less likely to be ambiguous than their domain name. 
	 


  _____  

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