| Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs. The risk as I see it is two-fold: 1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no clear way to extrapolate a successful validation for one domain into a plethora of FQDN's in a way that works for all scenarios. So the risk in this sense is that the issuer might allow a cert requester to over-subscribe a given domain's name space. 2) Abuse: Once the wildcard cert has been issued there is no way to check that the host (or FQDN) to which I'm connecting is a legitimate part of the broader domain or if it has been taken over for nefarious purposes. This is in contrast to the non-wildcard case wherein I know it's a legitimate part because I see the FQDN listed explicitly in the SAN field. So the risk in this sense is to the relying party who is less able to protect himself or herself from connecting to bad servers. The use of "problematic" to describe wildcard certs is perhaps misleading. Perhaps the wildcard certs themselves are not problematic but trying to manage or mitigate the risk they pose is. Either way, I don't think it would be wise to remove this from the problematic practices list.
On 21/04/17 12:09, Nick Lamb wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate > for verifying that the applicant controls the entire domain and thus > *.example.com, whereas say 3.2.2.4.6 proves only that the applicant > controls a web server, it seems quite likely they have neither the > legal authority nor the practical ability to control servers with > other names in that domain. I can see arguments either way for > 3.2.2.4.4, depending on how well email happens to be administrated in > a particular organisation. So your concern is that a subset of the 10 Blessed Methods might not be suitable for verifying the level of control necessary to safely issue a wildcard cert? If that's true, we should look at it, but I don't see how that's connected with saying or not saying on our wiki page that wildcard certs are inherently problematic. So, to analyse: you are saying that demonstrating control over http://www.example.com/ and getting a cert for *.www.example.com is shaky? Or demonstrating control of http://example.com/ and getting a cert for *.example.com? Or something else? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
