Robin Alden wrote: > Sure, but CAs issue certificates to IP addresses too (as we discuss below) > yet the policy does not allow for the possibility. Either the policy is > imprecise, or it is being flouted by the CAs that issue certificates for IP > addresses.
You're correct, this is a gap in our policy, which assumes the more typical case of an SSL certificate being tied to a domain name. We can discuss revising the policy later, but for now I think it's reasonable to say that issuing an SSL certificate tied to an IP address is OK as long as the following is true: * the IP address is public, i.e., reachable from the public Internet * the subscriber owns/controls the IP address on a permanent basis, i.e., it's a static IP address assigned to the subscriber by the subscriber's ISP (either a standalone address or part of a subscriber-controlled block of addresses) This is basically the current policy with "public static IP address" standing in place of "domain". As with domains, there are natural extensions to this case, most notably an SSL cert with multiple IP addresses included using SubjAltName; in this case the CA would do the verification for all the IP addresses referenced in the cert. (To others with more knowledge of this than I: Is there a notion of an "IP wildcard" cert, i.e., an SSL cert with a wildcard like 1.2.3.*, where the cert would be recognized as valid for an server with IP address in that range? If so, the implications for policy seem pretty straightforward: the CA should verify that the subscriber controls the entire IP address range.) > We do not consider dynamic IP addresses when validating IP addresses. We > look for static registration of an IP block. Ideally we want to see the > applicant registered as the owner of the block containing the IP address > being requested. Failing that we will accept written confirmation > (directly) from the block owner confirming that the IP address in question > is delegated to the applicant. IMO this meets the proposed policy requirements I outlined above. > I'm sure that some of our customers would argue over how easy it is to > replace these hostnames with FQDNs, but on reflection we do accept that the > use of what we are calling hostnames here could provide for an increased > risk that such a certificate could be used in a MITM attack, especially with > the (topical) possibilities of practical DNS poisoning attacks meaning that > there is an increased chance of an attacker being able to direct a reference > to a server by what appears to be an internal hostname to an external > server. Although not subject to the same threat of attacks on DNS we would > also include non-internet routable IP addresses as being of increased risk. > We therefore give a commitment that we will not issue any certificates which > are signed by, or benefit from cross-signing by, or otherwise inherit trust > from the ECC root which is the subject of this application that would > otherwise be allowed by the provisions of section 2.4.1 (f) of our main CPS. Thanks, this addresses an issue I was concerned about. > Frank, would you consider these practices of issuing certificates to > hostnames* and also of issuing to non-internet routable IP addresses as > being something to add to your problematic practices list? Yes, I'll do that. (Incidentally, I'm now calling it the "potentially problematic practices" list, because there's a lack of consensus on the extent to which some of these practices are problems in general.) >> In other words, Comodo would issue multiple certificates for the very >> same domain name? You could have multiple valid certificates for >> www.mozilla.com? > [Robin said...] > Yes, we would. Jean-Marc identified one case where it is desirable. > There are also cases when a server has been wiped (and so they private key > lost) and must be re-installed. I don't think it is realistic or appropriate to mandate that all currently valid certs issued by a CA have unique FQDNs associated with them; in other words, I think that having multiple certs with the same FQDN is not and of itself indicative of a problem. (I should also add that there's a similar case that's fairly common and unremarkable, where a CA issues a wildcard cert for, e.g., *.example.com, and also a cert for a specific domain otherwise encompassed in the wildcard, e.g., foo.example.com. As with the case of multiple certs with the same FQDN, here too we have the theoretical possibility of having one cert/private key pair that could be substituted for another without a typical user noticing.) To the best of my knowledge we've now covered all the outstanding issues for this request, and we're past the end of the second comment period. I'm going to proceed now to render a final decision. More later... Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
