[cabfpub] Use of wildcard certificates by cloud operators
Jeremy Rowley
jeremy.rowley at digicert.com
Wed May 7 06:32:49 MST 2014
Plus, as noted in my email, the ballot failed based on browser votes. CAs clearly voted in favor of the ballot. If the browsers are changing their mind, then we should re-discuss the topic.
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
Sent: Wednesday, May 7, 2014 7:12 AM
To: richard.smith at comodo.com; '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
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
More information about the Public
mailing list