[cabfpub] Use of wildcard certificates by cloud operators

Rich Smith richard.smith at comodo.com
Wed May 7 13:45:45 UTC 2014 

Jeremy and Steve,
I don't disagree with either of you that we can re-visit earlier topics, but in this instance, I think there is a clear, seemingly non-controversial solution without doing so.  In any such case I think we're all best served to follow the K.I.S.S. principle, and save getting bogged down by re-visiting of possibly controversial topics for another day.
-Rich

> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Wednesday, May 07, 2014 9:33 AM
> To: 'Steve Roylance'; 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
> 
> 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
> 

-------------- 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/445b1ba6/attachment-0003.bin>

More information about the Public mailing list