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

 
The EV certs can help the user but seem to have same problem as X.509
certs. Since the user agent relies on programmatic mechanisms to
validate the cert, I am not sure if IA is really improved by using an
EV cert. An issuer created the cert and is willing to verify it. The
user agents appears to have a need to consider cert quality or issuer
quality, and take "quality" into consideration before setting up the
session. I believe that the user experience is better when using an EV
cert, but does an EV cert really improve security?
 
Bill D.
 
 


________________________________

	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
michael.mccormick@wellsfargo.com
	Sent: Thursday, May 17, 2007 2:16 PM
	To: pbaker@verisign.com; public-wsc-wg@w3.org
	Cc: peltond@wellsfargo.com; Pete.Palmer@wellsfargo.com
	Subject: 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.