CA/PolicyVersion2.1

From MozillaWiki
< CA
Jump to: navigation, search

Topics Considered when drafting Version 2.1

The following items were considered while updating the Mozilla CA Certificate Policy to Version 2.1, which was published on February 14, 2013.

Important: The information below includes a collection of comments that were considered when each item was discussed. These comments may not actually be in agreement with current or future policy or recommended practice.

Fixes to Version 2.0

  • In the Inclusion Section item #4 should not list DSA certs with 2048-bit primes as an example of an invalid public key. bug 724038 - 2048-bit primes are now valid for DSA certificates
    • Fixed
  • In the Enforcement Section item #2 should say: "Mozilla may, at its sole discretion, disable(partially or fully) or remove..."
    • Fixed
  • In the Enforcement Section item #3 is too limiting. This item either needs to be removed or updated because Mozilla can disable the root or any issued certs in any way we choose.
    • Fixed

RAs and Subordinate CAs

Previously Considered Drafts

  • Recommendations for Roots
    • Resolved in 4th sub-bullet of #6 of InclusionPolicy.
    • A hierarchical structure of a single root with subordinate or intermediate certificates is required.
    • The (single top-level) root's public certificate is supplied for Mozilla's root list; the intermediate certificates are not.
    • The root is expected to be offline, the intermediate certificates online.
      • This should be made a requirement, and CA's not currently doing this should be required to fix it and only issue end-entity certs from intermediate certificates.
    • There should be a separated intermediate certificate for each RA. These should be internally-operated intermediate certificates, such that the "parent" CA is in full control of these intermediates and able to audit/control all activities of them. (add to Recommended Practices)
    • The audit process should cover the entire set of hierarchy.
    • Update section 15 of the Inclusion policy. It seems that (a) this suggests using separate single level roots, and (b) suggests that Mozilla will control the intermediates. Now, it may be that this is 3 year old writings, and the experience has led to a different path .. does the policy need updating?
      • The policy should state: "All certificates in the database shall be treated as root certificates."
      • Mozilla can control only selected intermediate certificates of a specific root and not include the root in case this is required.
      • The policy might consider a CA path length of 0 for subordinate certificates which are operated by third parties to the root. This is a requirement for the issuing EV certificate.
  • Cross-signing -- Root certs whose CAs would not meet the requirements of Mozilla's CA Policy should not be cross-signed by root certs that are included in NSS.
    • Resolved with items #8, 9, 10, and 12 of the Inclusion section.
  • Public disclosure of subCAs
    • Resolved with items #8, 9, and 10 of the Inclusion section.
    • I feel that the entire chain of trust in a CA's root must be transparent. Thus, the policy should require identification of third-party public subordinate CAs since the public will depend upon their trustworthiness. On the other hand, a CA could also have third-party private subordinate CAs that are not publicly identified; however, I would suggest that such CAs be based on separate intermediate certificates or even separate root certificates that are not in Mozilla's NSS database.
      • The entire point of having a private sub-CA is that the root your certs chain to is already in all your browsers. If an organization needs to add a new root to all the browsers, they might as well operate their own CA.
    • But what possible legitimate reason, from the perspective of users that rely on these entities, could there be for not requiring disclosure? At times, there seems to be a posture on the part of the Moz cert team against things that are thought to inconvenience the CAs.
      • I can imagine a variety of ways that public disclosure would help with policing. It would mean that people could conduct tests against the full list to verify actual validation. People could report RAs that do not have disclosed audits. Etc...
    • A CA’s list of third-party private subCAs is basically the CA’s enterprise customer list, which they frequently treat as confidential. However, I don’t see why third-party public subCAs could not be disclosed -- since they are issuing certs to people outside of their organization they must have publicly available CP/CPS documentation and audit statements. I suppose a similar argument could be made for requiring a CA to publicly disclose their list of third-party public RAs.


  • Mechanisms must be in place to prevent or catch mal-issuance by RAs and subCAs
    • Resolved with items #8, 9, 10, and 12 of the Inclusion section.
    • even if the CA outsources the customer contact, and outsources verification of customer identification documents, the CA should still be involved in at least a minimal way.
    • Check the latest version of the CAB Forum minimum requirements document section 15.7, External Systems Controls.
    • there should be a mandatory automated verification of domain ownership. That automated verification could be done by:
      • RA submits domain name to CA
      • CA sends email to one of postmaster/hostmaster/webmaster, as chosen by customer
      • prior to any certificate issueing, customer should prove that he controls the domain, by clicking a link in that verification email
      • The above could be fully automated by the CA, and wouldn't limit the powers of the RA.
    • Ways for the CA to implement automated checks for RAs and subCAs follow. In all these cases where there is a red flag, it makes the most sense to halt the process and do the extra validation before the cert is generated (not just before it is sent to the requester).
      1. Instead of trusting the RA do the domain control validation, it should have done the domain control validation itself.
      2. Simply by opening an HTTPS connection on port 443 for each site, it could have detected that each of the sites already have a cert from a different CA with different private/public key pairs. This should have triggered manual review by a security officer and more thorough determination of domain control before the certs were issued.
      3. By doing #2, the CA could easily detect if the site is using an EV cert. No CA should be issuing (non-EV) certs for a website in this situation without comprehensive authentication of the requester.
      4. Check that the domain name is a valid DNS name. Why would the software even allow a cert with "DNS Name=global trustee" to be generated, regardless of claims of validity?
      5. Require network-based (email, http request) validation. AFAICT, the alternate forms of validation of the requester are pretty rare and it seems very reasonable to mandate that someone from the CA re-validate the request after the RA has done so when this alternative type of validation is used.
      6. Build a list of high-value target domains, which would have included all of the domains targeted in this attack. Flag these high-risk domains as for manual review by multiple people at the CA.
      7. Check for mismatch between the country of the requester and the geo-ip lookup for the servers in question.
  • Constraints to help control what kind of certs intermediates can issue.
    • Resolved with items #8, 9, and 10 of the Inclusion section.
    • Require chain length limits to help control what kind of certs intermediates can issue (preventing an intermediate from issuing another CA cert).
      • Suggestion: Implement the RFE in bug #376853, with a default chain length of four (root, intermediate, intermediate, site).
    • Suggestion: Mandate name constraints. Anyone who wants a certificate without name constraints is to be considered a CA and should be forced to apply themselves. It should be made clear that a name constraint must match a "real" domain name and no TLD, i.e. *.example.com is ok, *.example.co.uk is ok, but *.co.uk and *.com are not. Multiple name constraints can be allowed. (If someone wants a TLD-level constraint, they are a CA and must apply themselves.)
  • Constraints on Third-party private (or enterprise) subordinate CAs.
    • Resolved with items #8, 9, and 10 of the Inclusion section.
    • Make crystal clear the expectation that we have is that any cert that chains to a trusted root is the responsibility of that root.
    • Bug #561024 - Require disclosure of the identities of external private sub-CAs
      • From David Ross: A private, subordinate CA should be restricted to signing subscriber certificates only for that CA's intranet. The subordinate CA's certificate should chain up to a root that is not used to sign certificates for public-facing Web sites, E-mail, or software; that is, the Mozilla policy should prohibit including any root certificate to which a certificate of a private, subordinate CA chains. The Mozilla policy should require the primary CA's CP/CPS should explicitly state that any private, subordinate CA must restrict itself to its own intranet; and the Mozilla policy should require the periodic audit of the primary CA to examine whether private, subordinate CAs are indeed complying with that provision in the CP/CPS. This is the only way I would find acceptable the practice of primary CAs not disclosing the identities of their private, subordinate CAs.
      • Suggestion: Certificate authorities should maintain separate root certificates for sub-CAs that are signing user certificates for private, intranet use, and those root certificates should not be included in NSS.
    • Require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280.
      • There may be acceptable reasons why this may not be feasible for some subCAs.
    • https://wiki.mozilla.org/CA/SubordinateCA_checklist
    • Bug #394919 Requested that dNSName constraints be applied to the Common Name, in addition to the SANs. Both the old certificate verification function and libPKIX were updated to apply dNSName constraints to the Subject Common Name. Both patches are in NSS 3.12.7, which is in mozilla-central and mozilla-1.9.2.
    • Require all contracts to be disclosed. (not the names of who meets the contracts, but the contract that is met.
    • Require that non-disclosed third-party sub-CAs be technically constrained from within the intermediate certificate(s); e.g. by use EKU and Name Constraints.

Audits

  • Audit disclosure/renewals of all Third-party public subordinate CAs.
    • Resolved with items #8, 9, and 10 of the Inclusion section.
    • Similar to audit renewals for root certs, specify audit renewal frequency for Third-party public subordinate CAs.
    • Require public disclosure of Third-party public subordinate CAs.
      • Such disclosure may not be reasonable to expect of all sub-CAs. May need to consider that this could have to be done under NDA with Mozilla, such that the list of such sub-CAs is not made public, but Mozilla verifies that updated audits for third-party public subCAs is provided on a regular basis.
    • https://wiki.mozilla.org/CA/SubordinateCA_checklist
  • Cross-signed roots also should be audited.
    • Resolved with items #8, 9, and 10 of the Inclusion section.

Domain Names

  • DNS names in SANs: It would be appropriate for Mozilla CA policy to mandate that CAs put all DNS names for a cert into SANs. It would not be necessary to go beyond that and disallow CAs to ALSO ADDITIONALLY put one DNS name in the subject common name for the benefit of VERY old (more than 12 year old) browsers that don't recognize SANs. It is only necessary to make it clear that ALL the DNS names (not all but one) must go into the SAN.
    • Resolved by the CAB Forum Baseline Requirements, and item #12 of Mozilla's CA Inclusion Policy.
    • Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN.
    • Then, modern browsers should stop paying attention to Subject common names (bug 552346). Doesn't matter what CAs put there as long as browsers don't look there.
    • How does this relate to Bug #394919 which requested that dNSName constraints be applied to the Common Name, in addition to the SANs?
    • See also section 4.4.4 of IETF Draft spec on TLS Server ID Checking.
    • See also the CAB Forum's Baseline Requirements draft: section 8.2.2, Subject Common Name Field
      • Certificate Field: subject:commonName (OID 2.5.4.3)
      • Required/Optional: Optional
      • Contents: If present, this field MUST contain a single Fully-Qualified Domain Name of a server. The server MUST either be owned and operated by the Applicant or by a related entity (e.g., a hosting service). The Applicant MUST own or control the Domain Name or have been granted the right to use the Domain Name. The value MUST also appear in an extensions:subjectAltName:dNSName entry described above. Domain Names that are not resolvable through the public DNS MUST NOT be included in this field.
    • RFC5280 Section 4.2.1.6, Subject Alternative Name: The subject alternative name extension allows identities to be bound to the subject of the certificate. [...] Defined options include an Internet electronic mail address, a DNS name, [...] Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4.
  • Issuing SSL Certificates for Internal Domains
    • Resolved by the CAB Forum Baseline Requirements, and item #12 of Mozilla's CA Inclusion Policy.
    • Bug #567193 - Enforce Mozilla CA Policy requirement section 7
    • Bug #526560 is in regards to the case were certs were issued to .int domains without sufficient verification.
    • Bug #553754 - Stop honoring string representations of IP addresses in all cert fields from which we take DNS names
    • IP addresses and non-registrable TLDs. Some CAs issue certificates for meaningless Class C/B IP addresses, host names without any TLDs and host names which are based on non-existing/non-registrable TLDs. Anything that can't be verified in some way to be under the control of a specific entity can't provide any security whatsoever. With today's WiFi access points, this issue has become a real problem as compared to just about a few years ago.
    • Certificates referencing hostnames or private IP addresses: 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); We consider this a problematic practice [...] It is also a problematic practice to issue a certificate with non resolvable DNS or private IP and resolvable DNS adresses together.
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/PolicyVersion2.1&oldid=1239756"