[cabfpub] EV Wildcards

[Geoff Keating]

> On 26 Mar 2015, at 3:03 pm, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Mar 26, 2015 at 2:59 PM, Geoff Keating <geoffk at apple.com <mailto:geoffk at apple.com>> wrote:
> 
>> On 26 Mar 2015, at 8:46 am, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com>> wrote:
>> 
>> We disagree with this line of thinking. Today someone can pay a few dollars and secure *.example.com <http://example.com/>, where the result is [high-risk].example.com <http://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.
>>  
> 
> I don’t believe this is correct; a legitimate organization that passes EV verification can order that same certificate, and no further validation is required.  What they can’t do is get it marked as EV.
> 
> That depends on a CA-by-CA basis.
> 
> [high-risk] is a CA-dependent determination which the BRs don't normatively specify, and thus subject to a wide degree of interpretation regarding it. So you could shop EV CAs until you found a CA willing to do it.
> 
> It's not even a valid PR compliant, as was suggested elsewhere. It'd be two CA's bickering over what "high risk" means and whether "[some string]" is high-risk or not. The process/procedures of the EV process would have been fully followed. 

I meant, they can order the same wildcard certificate.  I’d hope there aren’t CAs who will allow orders for facebook.example.com <http://facebook.example.com/> even as DV.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150326/6ff281fc/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4103 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150326/6ff281fc/attachment-0001.p7s>