[cabfpub] Use of wildcard certificates by cloud operators
Ben Wilson
ben at digicert.com
Wed May 7 15:27:13 UTC 2014
Rich,
It appears that Geoff's high-risk checking would be a new flow-down
requirement to cloud providers.
Ben
-----Original Message-----
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Wednesday, May 07, 2014 9:18 AM
To: 'Geoff Keating'; 'Kelvin Yiu'
Cc: ben at digicert.com; 'Gervase Markham'; sleevi at google.com;
public at cabforum.org
Subject: RE: [cabfpub] Use of wildcard certificates by cloud operators
Geoff,
We have wording in the BRs already regarding high risk request checking.
Are there any specific short-comings with that that you'd like to see
addressed in regards to this topic?
-Rich
> -----Original Message-----
> From: Geoff Keating [mailto:geoffk at apple.com]
> Sent: Wednesday, May 07, 2014 10:02 AM
> To: Kelvin Yiu
> Cc: richard.smith at comodo.com; ben at digicert.com; Gervase Markham;
> sleevi at google.com; public at cabforum.org
> Subject: Re: [cabfpub] Use of wildcard certificates by cloud operators
>
>
> On 6 May 2014, at 12:58 pm, Kelvin Yiu <kelviny at exchange.microsoft.com>
> wrote:
>
> > It sounds like we have some consensus to move forward on the issue. I
> can draft a proposal that include the following:
> >
> > 1. Update Section 11.1.3 to clarify that wildcard is allowed for
> domains for cloud operators. I hear that when the forum last updated
> section 11.1.3, there was a lot of headache involved, so I will try to
> be precise and keep the changes to a minimum.
> > 2. Update Section 13.1.5 to allow cloud operators a chance to remedy
> fraudulent sub domains and within a reasonable time period. The idea is
> that CAs would still be required to contact the cloud operator. But if
> the cloud operator can take down any fraudulent site within n days (I
> think n should be less than 7 days) and can attest the private key is
> not compromised, revocation is not necessary.
>
> I'd like to also see some kind of filtering for phishing-related
> domains, some kind of 'best effort' to keep misleading names out in the
> first place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140507/1d9c57c2/attachment-0001.p7s>
More information about the Public
mailing list