[cabfpub] Use of wildcard certificates by cloud operators

[Ryan Sleevi]

On Mon, May 5, 2014 at 10:10 AM, Kelvin Yiu
<kelviny at exchange.microsoft.com>wrote:

>  This Netcraft post (
> http://news.netcraft.com/archives/2014/04/28/phishers-find-microsoft-azure-30-day-trial-irresistible.html)
> has highlighted some questions for us about wildcard certificate
> requirements in the BR and how they apply to cloud operators.
>
>
>
> Microsoft Azure customers can create sub domain names under specific MS
> registered domains (e.g. myservice.azurewebsites.net). Users can access
> these FQDNs using HTTPS, which is is secured with a wildcard certificate
> managed by Azure. Customers do not have access to the private key of the
> wildcard certificate. Azure also maintains a process to monitor for
> fraudulent activities and will take down such sites. AFAIK, other cloud
> operators such as Google App Engine and Amazon Web Services uses wildcard
> certificates in a similar way.
>
>
>
> Here are my questions to the forum:
>
>
>
> 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?
>
The Public Suffix List is presently divided into two sections -
ICANN-assigned suffices (eg: gTLDs, ccTLDs) and "Private" (enterprise)
suffices, for which Azure falls under (as do many other hosted services,
such as AWS and Google App Engine)

In both cases, things are fuzzy - in a know-it-when-I-see-it sort of way.
That is, it's easy to say something like "*.com" should be invalid. For
something like *.appspot.com or *.azurewebsites.net, one would say that it
should be invalid for "just anyone" to register, but it should be valid for
Google/Microsoft (respectively) to register - as they have. So perhaps we'd
say this is a "high-risk domain" and requires manual vetting, but it's hard
to say as a general rule it should be prohibited.

Further, it gets more troubling with something like *.nike (as a
hypothetical). If Nike doesn't allow third-party registrations, but instead
fully operates the domain - much like *.appspot.com or
*.azurewebsites.net- should it be allowed to register a wildcard cert?
Maybe, maybe not. (For
the record, Chrome, in present form, would reject it, as it would any
wildcard to an ICANN/IANA-assigned gTLD)

Note that Section 11.1.3 provides for registrations in *.azurewebsites.netand *.
appspot.com - as well as *.nike - in its present form, in the first
sentence of the second paragraph:

"If a wildcard would fall within the label immediately to the left of a
registry-controlled† or public suffix, CAs MUST refuse issuance unless the
applicant proves its rightful control of the entire Domain Namespace."

 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?
>

I don't have a good answer for this, and will probably need to think more
before responding. I can see positive and negative outcomes with either
answer.


>
>
> Kelvin
>
> _______________________________________________
> 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/20140505/5b0442f0/attachment-0003.html>