[cabfpub] EV Wildcards

Dean Coclin Dean_Coclin at symantec.com
Thu Mar 26 15:46:59 UTC 2015

We disagree with this line of thinking. Today someone can pay a few dollars and secure *.example.com, where the result is [high-risk].example.com with the most limited form of authentication. However a legitimate organization that successfully passes EV verification cannot order that same certificate. This makes zero sense — in fact, since the concern is with the exploit, this logic means that wildcards would be forced to the least authenticated customers.  Hence we would support wildcards for EV certs.


If we were going to change anything else (which is a completely separate discussion), it would be to put a minimum authentication requirement on the issuance of wildcards.





From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Wednesday, March 25, 2015 9:05 PM
To: CABFPub (public at cabforum.org)
Subject: [cabfpub] EV Wildcards


All the arguments on the question of allowing EV Wildcard certs are well considered and valid on both sides.  Chris Bailey and I come down on the side of “no EV wildcard certs” for the following reason.


It’s true that *.example.com could “hide” the use for facebook.example.com.  It’s also true that the owner of example.com today could ask for an EV cert for facebook.example.com, and if the cert is issued, it’s “no different” from using a wildcard cert *.example.com.


However, there is one important difference.  BR 11.5 (High Risk Requests) and the related EV Guideline 11.12.1 require the following:


BR 11.5 High Risk Requests

The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.


High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.


Among other things, we interpret that to require CAs to scan FQDNs for “names at higher risk for phishing or other fraudulent usage” at every level in the FQDN, and as a matter of policy, we generally won’t issue a cert for facebook.example.com unless the customer can show us it has Facebook’s permission.  The same is true for a long list of other high risk names, and we apply the scan to all FQDNs in the SANs field as well.


So this means that under our policy and interpretation a customer could not get an EV cert from us for [high risk name].example.com, which helps cut down on the likelihood of fraud or imitation.  An EV cert for *.example.com, on the other hand, could be used to secure the same high risk name FQDN.


We recognize that other CAs may not have a policy as restrictive as ours for EV certs, but if another CA issues an EV cert for facebook.example.com and it’s used for fraud or phishing – presumably that CA will get very adverse publicity, and will have some explaining to do to the public.  That is likely to keep the number of such high risk name EV certs to a minimum.  In contrast, no scanning or review will happen for EV wildcard certs.


So in that sense, there is a difference, and we think wildcard certs should not be issued for EV – prohibiting EV wildcard certs makes CAs a bit more responsible, in our opinion.


Kirk R. Hall

Operations Director, Trust Services

Trend Micro



The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150326/6575c70e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150326/6575c70e/attachment-0001.p7s>

More information about the Public mailing list