[cabfpub] Use of wildcard certificates by cloud operators

Tue May 6 20:16:29 UTC 2014

On Tue, May 6, 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.
>

This isn't needed. 11.1.3 already allows this.

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140506/9be29a6f/attachment-0003.html>