Changes

Jump to: navigation, search

CA/Forbidden or Problematic Practices

4,441 bytes removed, 09:51, 5 May 2017
Split into Forbidden and Problematic
= Potentially Problematic This page contains comments about various CA Practices =practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla's Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but 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. Additional practices may be addressed in future versions of the policy.
This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are not explicitly addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla CA certificate policy] and we do not necessarily consider them security risks; some are addressed, and are forbidden. 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. Additional practices may be addressed in future versions of the policy.== Forbidden Practices ==
=== Long-lived DV Certificates ===
Note: the The BRs currently require certificates to have a maximum lifetime of 39 months, and that will be reduced to 27 months in March 2018.
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. == = Non-Standard Email Address Prefixes for Domain Ownership Validation ===
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [[CA:BaselineRequirements|Baseline Requirements]] (BRs) in the issuance and management of publicly trusted SSL certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR Section 11.1.1 (section 3.2.2.4 in BR version 1.3), which restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records and a selected whitelist of local addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster".
A CA that authorizes certificate subscribers by contacting any other email addresses is deemed to be non-compliant with Mozilla's Root Store Policy and non-conforming to the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any certificates that are technically capable of issuing SSL certificates, and subordinate CAs that fail to follow these requirements reflect upon the issuing CA that certified it.
== 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's Root Store Policy] and should always be incorporated into the issuing CA's 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 ===
This is forbidden by the Baseline Requirements.
== Allowing External Entities to Operate Subordinate CAs = Distributing Generated Private Keys in PKCS#12 Files ===
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. If Mozilla accepts and includes a CA's root certificate, then we have to assume It is reported that we also accept any of their future sub-CAs and their sub-some CAs. Therefore, generate the selection criteria key pairs for a CA's sub-CAs and their sub-CAs will be a critical decision factorsubscribers, as well as the documentation and auditing-of-operations requirements that the CA places on such relationships. In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes rather than having the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose subscribers generate their hierarchy, including CP, CPSown key pairs, and audits, when said hierarchy is capable of SSL or email issuance. More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is available]. During the root inclusion/change processonce generated, those CAs must provide a clear description of distribute the subordinate CAs that are operated by external third partiesprivate key, and an explanation as to how together with the CP/CPS issued public key certificate and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist. After inclusion, CAs must disclose their subordinate CAs in the [https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Database]its chain, and maintain annual updates to the corresponding CP/CPS documents and audit statements. == Distributing Generated Private Keys subscriber in a PKCS#12 Files ==file. The issues include:
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.
CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME encryption certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then: * The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.
=== Certificates Referencing Local Names or Private IP Addresses ===
This is forbidden by the Baseline Requirements. [http://www.cabforum.org/documents.html BR 9.2.1]: “As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the '''use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016'''. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.”
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.) It is not standards compliant for printable ASCII representations of IP addresses to be placed in any certificate field that is intended to hold DNS names, including the subject common name and the DNSName field of the Subject Alternative Names extension. There is a place in a certificate specifically intended to be where IP (v4 or v6) addresses may be placed. It is in the Subject Alternative Names extension. The SubjectAltNames extension has places for both additional DNS names and for IP addresses. The place for IP addresses takes them in binary form, not in printable ASCII (e.g. dotted decimal) form. See {{bug|553754}}. === Issuing SSL Certificates for .int Domains ===
It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD. In any case, CAs should be no longer issuing certificates for Internal Names.
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether. If you have issued certificates for internal domains within your CA hierarchy, Mozilla requests that you take the following actions:# Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.# Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents:#* Section 7 of [http://www.mozilla.org/projects/security/certs/policy/ Mozilla’s CA Certificate Policy]#* [[CA:Recommended_Practices|Recommended practices for CAs]] Mozilla also recommends that you # Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates.# Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by [http://www.icann.org/en/registries/top-level-domains.htm IANA], make an explicit decision whether or not to add the new TLD to your list. === OCSP Responses Signed by a Certificate Under a Different Root ===
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 the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]
== = Issuance of SHA-1 Certificates ===
These are This is forbidden by the Baseline Requirements.
SHA-1 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for SHA-1 based signatures. The SHA-1 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling SHA-1 will impact intermediate and end entity certificates, where the signatures are validated.
* [https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Security Blog Post Regarding SHA-1 Based Signature Algorithms]
== Potentially Problematic Practices == === 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's Root Store Policy] and should always be incorporated into the issuing CA's 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. === Allowing External Entities to Operate Subordinate CAs === Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. If Mozilla accepts and includes a CA's root certificate, then we have to assume that we also accept any of their future sub-CAs and their sub-CAs. Therefore, the selection criteria for a CA's sub-CAs and their sub-CAs will be a critical decision factor, as well as the documentation and auditing-of-operations requirements that the CA places on such relationships. In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of SSL or email issuance. More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is available]. During the root inclusion/change process, CAs must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist. After inclusion, CAs must disclose their subordinate CAs in the [https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Database], and maintain annual updates to the corresponding CP/CPS documents and audit statements. === Generic Names for CAs ===
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.
'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable to have the O be a generic term such as "Admin" because it could mislead users that rely on the issuer details, such as when you hover your mouse over the domain or organization section in the address bar.
=== Lack of Communication With End Users ===
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA.
===Backdating the notBefore Date===
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.
=== Issuer Encoding in CRL ===
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs ([https://www.ietf.org/rfc/rfc2459.txt RFC 2459], [https://www.ietf.org/rfc/rfc3280.txt RFC 3280], [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280]) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.
Gerv
Accountapprovers, antispam, confirm, emeritus
4,925
edits
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1170399"

Navigation menu