[cabfpub] Use of wildcard certificates by cloud operators

Tue May 6 20:16:26 UTC 2014

The last time we tried to amend this section, Globalsign proposed certain rules for wildcards, including requiring at least OV for wildcard certs.  DigiCert supported this effort, but the motion (ballot 92) failed with 76% of CAs voting in favor and 80% of browsers voting against. 

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Kelvin Yiu
Sent: Tuesday, May 6, 2014 1:58 PM
To: 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

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. 

There is also a question about whether these wildcard rules should be applied equally to DV and OV certificates. Both Microsoft and Google (AFAIK) issue OV certificates from their own CA to their own cloud operations, so I am interested in hearing what the forum thinks. 

Kelvin

-----Original Message-----
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Tuesday, May 6, 2014 11:11 AM
To: ben at digicert.com; 'Gervase Markham'; Kelvin Yiu; sleevi at google.com; public at cabforum.org
Subject: RE: [cabfpub] Use of wildcard certificates by cloud operators

I agree with the approach of giving the cloud operator the opportunity to remedy the situation.  Assuming the key has not been compromised, what we are looking for here is the end of the particular threat.  The best solution for all concerned is that the offending content is removed as quickly as possible, and with minimal interference to the cloud operator, and the honest members of their customer base.  If the cloud operator is unresponsive, or seems to continuously have these types of problems out of proportion to other operators, then we can use revocation.

Something that needs to be pointed out here is that browser revocation checking/handling is spotty and there's nothing this Forum can do about that.  Some browsers, members of this Forum, have made perfect the enemy of good with respect to revocation handling and in so doing have completely dropped the ball for their users.  That being the case, to ALWAYS require revocation in this kind of instance without trying first to allow the cloud operator to handle the situation would still leave a lot of end users exposed.  What happens when we revoke, and those browsers who have chosen to punt on revocation checking don't pick it up because they've chosen performance over security, and the malicious content remains on the site?

-Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Ben Wilson
> Sent: Tuesday, May 06, 2014 11:17 AM
> To: 'Gervase Markham'; 'Kelvin Yiu'; sleevi at google.com; 
> public at cabforum.org
> Subject: Re: [cabfpub] Use of wildcard certificates by cloud operators
> 
> 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.
> 
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public