<p dir="ltr">Rich,</p>
<p dir="ltr">The wording doesn't apply to users of wildcard certs - in particular, cloud hosts - the topic at hand.</p>
<div class="gmail_quote">On May 7, 2014 8:18 AM, "Rich Smith" <<a href="mailto:richard.smith@comodo.com">richard.smith@comodo.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Geoff,<br>
We have wording in the BRs already regarding high risk request checking.<br>
Are there any specific short-comings with that that you'd like to see<br>
addressed in regards to this topic?<br>
-Rich<br>
<br>
> -----Original Message-----<br>
> From: Geoff Keating [mailto:<a href="mailto:geoffk@apple.com">geoffk@apple.com</a>]<br>
> Sent: Wednesday, May 07, 2014 10:02 AM<br>
> To: Kelvin Yiu<br>
> Cc: <a href="mailto:richard.smith@comodo.com">richard.smith@comodo.com</a>; <a href="mailto:ben@digicert.com">ben@digicert.com</a>; Gervase Markham;<br>
> <a href="mailto:sleevi@google.com">sleevi@google.com</a>; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
> Subject: Re: [cabfpub] Use of wildcard certificates by cloud operators<br>
><br>
><br>
> On 6 May 2014, at 12:58 pm, Kelvin Yiu <<a href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>><br>
> wrote:<br>
><br>
> > It sounds like we have some consensus to move forward on the issue. I<br>
> can draft a proposal that include the following:<br>
> ><br>
> > 1. Update Section 11.1.3 to clarify that wildcard is allowed for<br>
> domains for cloud operators. I hear that when the forum last updated<br>
> section 11.1.3, there was a lot of headache involved, so I will try to<br>
> be precise and keep the changes to a minimum.<br>
> > 2. Update Section 13.1.5 to allow cloud operators a chance to remedy<br>
> fraudulent sub domains and within a reasonable time period. The idea is<br>
> that CAs would still be required to contact the cloud operator. But if<br>
> the cloud operator can take down any fraudulent site within n days (I<br>
> think n should be less than 7 days) and can attest the private key is<br>
> not compromised, revocation is not necessary.<br>
><br>
> I'd like to also see some kind of filtering for phishing-related<br>
> domains, some kind of 'best effort' to keep misleading names out in the<br>
> first place.<br>
</blockquote></div>