[cabfpub] Use of wildcard certificates by cloud operators

Wed May 7 06:12:21 MST 2014

Hi Rich.

Note that opinions do change over time, so let's agree that nothing is fixed forever.  e.g. The world really is round ;-)   

Let's remain open to embrace change even on subjects previously discussed.  It's what allows the flexibility to be able to claim 'current' best practice.

Kind Regards

Steve.  

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Rich Smith
> Sent: 07 May 2014 14:04
> To: 'Jeremy Rowley'; '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
> 
> 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/pkcs7-signature
Size: 4256 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140507/c661b687/attachment-0001.bin 