Eddy Nigg said:- > Robin Alden: > > f) refers to an SSL product which is limited in such a way that it isn't > > generally usable on the public internet. We offer no warranty on the > > product, and the main part of the domain validation is to ensure that > the > > domain name in the certificate is not a valid internet name or, if the > > certificate is for an explicit IP address, that the IP address is not > > internet routable. > > > > We do issue quite a number of these certificates, especially for use > within > > enterprise organizations. > > We don't issue many to localhost in particular but we have issued some! > > > > Thanks Rob for this information. I want to raise here a concern about > this practice. I view hostname based certificates not something public > CAs should be involved since with little knowledge an attack on those > sites is rather easy to perform. Considering that NO validations are > performed nor that the hostnames have to be unique (considering that you > mentioned that you issue SOME certificates for "localhost", which is > more than one), I suspect this to be in contradiction to the Mozilla CA > Policy: > > In http://www.mozilla.org/projects/security/certs/policy/ section 7 > explicitly states: > > "for a certificate to be used for SSL-enabled servers, the CA takes > reasonable measures to verify that the entity submitting the certificate > signing request has registered the domain(s) referenced in the > certificate or has been authorized by the domain registrant to act on > the registrant's behalf" [Robin said...] It does state exactly that, and its fine and dandy as far as it goes. It does not say exactly what a "domain" is in this context. Is it the intention to prohibit trusted SSL certificates for IP addresses? Is it the intention to prohibit trusted SSL certificates for private host names which are not resolvable through DNS on the public internet?
> > Uniqueness of the common name field is not mentioned explicit in the > Mozilla CA policy [Robin said...] Good. Then we don't need to consider it here. >, but nevertheless it's industry standard that CN > fields are unique per issuer (for server certificates). [Robin said...] It's not standard in my industry. Serial numbers, yes, common names, no. > Now, issuing > certificates for hostnames AND no uniqueness is required, I few the risk > even higher (since the same issuer might issue the same certificates, > one which might be used for such an attack). Please note that there is > NO validation performed, meaning anybody literally can get a certificate > as would be used somewhere else... > > Disclaiming any warranty doesn't cut I think...than why issue them in > first place? [Robin said...] I don't understand the premise on which you made that statement. You must be aware why people choose to use trusted SSL certificates. The warranty we offer with our certificates is outside the scope of the inclusion request, of course, but it relates to losses incurred by relying parties in e-commerce transactions. We don't expect anyone to use a certificate for a private host name to protect an e-commerce site. > > Now, I suggest to Frank to review this matter seriously and to evaluate > the risk which might be involved with hostname based certificates. > [Robin said...] Sure. Robin _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
