CA/Forbidden or Problematic Practices

Potentially problematic CA practices

This page contains draft comments about various CA practices that have been the subject of discussion in past CA evaluations. In general these practices are not explicitly addressed by the Mozilla CA certificate policy, and we do not necessarily consider them security risks. However we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Some of these practices may be addressed in future versions of the policy.

Long-lived DV certificates

A domain-validated SSL certificate attests only to ownership and control of a domain name, and the owner of a domain name may have acquired it from others. It is therefore possible for the previous owner of the domain to have a still-valid DV certificate for the domain. If such a valid certificate (and associated private key) were to be used in conjunction with a DNS spoofing attack it would allow a malicious site to masquerade as a legitimate site and bypass the protection afforded by SSL.

Some CAs issue DV SSL certificates that have expiration times several years in the future. This increases the time during which the possibility of such an attack exists.

Wildcard DV SSL 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 to third parties

Domain and Email validation are core-requirements of the 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

Some CAs issue end entity certificates directly from the root (i.e., signed using the root CA private key). This is not as secure as using an offline root and issuing certificates using a subordinate CA.

Allowing external entities to operate unconstrained subordinate CAs

Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.

Distributing generated private keys in PKCS#12 files

It is reported that some CAs generate the key pairs for their subscribers, rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file. The issues include:

• The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and
• The distribution channels used (e.g. unencrypted email) may not be adequately secured.

Certificates referencing hostnames or private IP addresses

The standard model for SSL on the web assumes that an SSL certificate references a domain name that is resolvable using the public DNS infrastructure (e.g., "www.example.com") or an IP address that is reachable from the public Internet. However it is also possible to include in a certificate a hostname not resolvable through the public DNS (e.g., "home") or a private IP address (e.g., 192.168.1.101); for example, this might be done for a corporate intranet with SSL-enabled servers behind a firewall and employees who don't want to enter fully-qualified domain names.

We consider this a problematic practice for a public CA because a subscriber who obtains a certificate of this type could in theory use it in contexts other than the one for which the certificate was obtained, and in particular could use it to help enable an SSL MITM attack on users in other organizations who are using the same hostname or IP address for their own SSL-enabled servers. (Depending on the hostnames and private IP addresses used, this vulnerability might also affect users of home networks with SSL-enabled home gateway devices.)

OCSP Responses signed by a certificate under a different root

CAs are not required to use OCSP. However, CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install another root.

Some OCSP implementations use a Trusted Responder, in which the OCSP response is signed by a certificate under a different root. In this case, the requester has to explicitly trust the OCSP responder by trusting the separate root. When an OCSP Responder URL is included in end-entity certificates, Firefox 3 will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate does not chain up to a trusted root, the OCSP check will fail with the error sec_error_ocsp_malformed_request.

CRL with critical CIDP Extension

Currently Firefox will not be able to load a CRL into the local database when the CRL Issuing Distribution Point extension is flagged as critical. When attempting to load a CRL with the critical CIDP, Firefox will return the error code ffffe095, which is equivalent to the negative decimal number -8043. According to the NSS Error Codes this error corresponds to SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION.

The NSS team is working on implementing the code that will understand and use the CIDP extension. There will also have to be changes in Firefox to make this work. However, older versions of Firefox will not be able to load CRLs with critical CIDP extensions.

Our recommendation is to remove the critical flag from the CIDP extension of your CRL.