[cabfpub] Use of wildcard certificates by cloud operators

[Rich Smith]

Jeremy,
As you have pointed out, a measure attempting to require OV for wildcards has already been proposed and rejected.  There is no need to resurrect that measure to address this topic which is about revocation of a wildcard due to malicious content contained on a particular sub-domain which has been allocated by a cloud operator to a customer.  A solution to this concern is straight forward and, it seems, pretty non-controversial without dragging an already rejected concept back into it.  IMO, we should keep it that way. 

-Rich

> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Tuesday, May 06, 2014 4:37 PM
> To: richard.smith at comodo.com; 'Kelvin Yiu'; ben at digicert.com; 'Gervase
> Markham'; sleevi at google.com; public at cabforum.org
> Subject: RE: [cabfpub] Use of wildcard certificates by cloud operators
> 
> This misses the point of requiring OV.   Although a browser UI is
> always appreciated, the UI is not as important as the benefit of
> ensuring the cert is only issued to a legitimate business entity that
> can ultimately be held responsible for the corresponding website's
> contents and use.  Because these certificates are higher risk than
> others (they secure an unknown number of domains), additional
> verification is necessary.  The CA's are more than competent at
> policing such differentiation, and the distinction is far from
> arbitrary. CA's police distinctions in cert profiles all the time, such
> as between code signing, EV, OV, and s/MIME. It's part of the business.
> 
> Jeremy
> 
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rich Smith
> Sent: Tuesday, May 6, 2014 2:16 PM
> To: 'Kelvin Yiu'; ben at digicert.com; 'Gervase Markham';
> sleevi at google.com; public at cabforum.org
> Subject: Re: [cabfpub] Use of wildcard certificates by cloud operators
> 
> > -----Original Message-----
> > From: Kelvin Yiu [mailto:kelviny at exchange.microsoft.com]
> > Sent: Tuesday, May 06, 2014 3:58 PM
> <snip>
> >
> > 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.
> >
> </snip>
> [RWS] IMO, the same rules should apply to DV and OV.  A couple reasons
> for that:
> 1) As a practical matter it is nearly impossible for a CA to police
> such a differentiation and trying to do so would be pretty arbitrary
> 2) The browsers do not at this time offer any differentiation between
> DV and OV, and many have pushed the interface for the user to view the
> actual certificate details deeper and deeper into the UI making it even
> more difficult for users to differentiate for themselves, so I don't
> see much point in us trying to differentiate usage rules unless the
> browsers want to change their stance on DV vs. OV in the UI.
> 
> > 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140507/8f6dcfdb/attachment-0003.bin>