[cabfpub] Use of wildcard certificates by cloud operators

Ben Wilson ben at digicert.com
Tue May 6 15:16:30 UTC 2014

If the Baseline Requirements don't quite address the problem (higher risk) the way we would like them to, then we ought to draft and propose an amendment that says what we want it to say.  For instance, on #2 below, do we allow the cloud operator the opportunity to remedy the problem and only revoke certificates where the operator fails to take action with a certain amount of time?  Would an escalation procedure or ratcheting process be good to include in the pre-revocation stage?  Are there procedures elsewhere that have worked well in these types of relationships that could be adapted to this use case?

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Tuesday, May 06, 2014 4:01 AM
To: Kelvin Yiu; public at cabforum.org
Subject: Re: [cabfpub] Use of wildcard certificates by cloud operators

I agree with Ryan :-)

On 05/05/14 18:10, Kelvin Yiu wrote:
> 1.       Section 11.1.3 of the BR explicitly disallow wildcard
> certificates for registry controlled domains (e.g. *.com). The Mozilla 
> maintained http://publicsuffix.org is cited as an example of a public 
> suffix list where Azure, GAE, and AWS domains can be found. Does the 
> current usage of wildcard certificates by cloud operators violate the 
> BR? If so, is this intentional and what is the reason?

No. The PSL is in two sections for precisely this reason - there are privately-owned sites where an e.g. appspot.com cookie should not be allowed (allows one appspot site to perform cookie fixation attacks against another) but a *.appspot.com cert should be allowed. So we split the PSL logically into two to put sites like this in their own section.

> 2.       Section 13.1.5 of the BR explicitly require wildcard
> certificates that were “used to authenticate fraudulently misleading 
> subordinate FQDN” to be revoked within 24 hours. If the fraudulent 
> sites never had access to the private key of the wildcard certificate 
> and the cloud operator has a process to take down fraudulent sites, 
> should these wildcard certificates be required to be revoked?

Hmm. This is tricky. I suspect this situation was not considered when we wrote that. I'd lean towards No, but I'm not sure that's what the BRs say on their face, and I'd welcome more discussion.

Public mailing list
Public at cabforum.org
-------------- 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/20140506/65bbfdee/attachment-0001.p7s>

More information about the Public mailing list