82
edits
CA/Forbidden or Problematic Practices: Difference between revisions
CA/Forbidden or Problematic Practices (view source)
Revision as of 22:55, 12 January 2009
, 12 January 2009→Delegation of Domain / Email validation by third parties
| Line 13: | Line 13: | ||
Some CAs issue domain-validated SSL certificates that can function as wildcard certificates, e.g., a certificate for *.example.com where the CA verifies only ownership and control of the example.com domain, and the certificate subscriber can then use the certificate with any site foo.example.com, bar.example.com, etc. This means that a subscriber could establish malicious SSL-protected web site that are deliberately named in imitation of legitimate sites, e.g., paypal.example.com, without knowledge of the CA. Concerns have been expressed that wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated with organizational validation (OV). (There are no EV wildcard certificates.) | Some CAs issue domain-validated SSL certificates that can function as wildcard certificates, e.g., a certificate for *.example.com where the CA verifies only ownership and control of the example.com domain, and the certificate subscriber can then use the certificate with any site foo.example.com, bar.example.com, etc. This means that a subscriber could establish malicious SSL-protected web site that are deliberately named in imitation of legitimate sites, e.g., paypal.example.com, without knowledge of the CA. Concerns have been expressed that wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated with organizational validation (OV). (There are no EV wildcard certificates.) | ||
=== Delegation of Domain / Email validation | === Delegation of Domain / Email validation to third parties === | ||
Domain and Email validation are core-requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Policy] and should always be incorporated into the issuing CAs procedures. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures or should be audited with the issuing CA. Delegation of domain/email validation to third parties should generally be avoided. | Domain and Email validation are core-requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Policy] and should always be incorporated into the issuing CAs procedures whenever possible. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures and/or should be audited together with the issuing CA. The CA must demonstrate clear and efficient controls attesting the performance of its RAs. Delegation of domain/email validation to third parties should generally be avoided. | ||
=== Issuing end entity certificates directly from roots === | === Issuing end entity certificates directly from roots === | ||