Robin Alden: > Eddy Nigg said: >> 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.
Well, we all know what a domain is.... > Is it the intention to prohibit trusted SSL certificates for IP addresses? I think an IP address is almost on the same level as a domain name, but even here there can be problems. For example if you are willing to validate dynamic assigned IP addresses, than this can be actively exploited obviously. An assigned IP may belong to somebody else within a few hours difference only and then what? > Is it the intention to prohibit trusted SSL certificates for private host > names which are not resolvable through DNS on the public internet? They can be easily replaced by real domain names as in my previous example (server.intern.domain.com). In my opinion there is no justification to use (and secure) hostname based servers. > It's not standard in my industry. Serial numbers, yes, common names, no. In other words, Comodo would issue multiple certificates for the very same domain name? You could have multiple valid certificates for www.mozilla.com? And with your case of hostnames, we can have multiple certificates like server1 owned by different subscribers? That's interesting... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
