CA/PolicyVersion2.0

From MozillaWiki
< CA
Jump to: navigation, search

The following items were considered while updating the Mozilla CA Certificate Policy to Version 2.0, which was published on February 2, 2011. Changes were made in regards to all of the items listed below, except for limiting the validity period of long-lived DV SSL certs.

  • CP/CPS documents must be publicly available
    • CAs should supply the complete Certification Policy (CP) and/or Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.
    • The CP/CPS should be publicly available from the CA's official web site.
    • The CP/CPS must be included in the audit examination and report/statement.
  • Compromised Certificates: CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.
    • Suggestion: If a key is compromised (proven for example by submitting the key in a bug), and the CA knows it (proven for example by CCing the CA) and the cert is not revoked within n days (n being small), the root is automatically and without further debate removed or at least fitted with a warning.
    • This requires a definition of compromise for it to be useful. You might say it is compromised if it becomes computationally feasible to determine the key, but one person's feasible might be another persons's infeasible. Where do you draw the line?
      • If a 2048 bit key is weakened by (effectively) 2 bits is it compromised?
      • If a 2048 bit key is weakened by (effectively) 2000 bits is it compromised?
  • Audit Renewals
    • Update Mozilla CA certificate policy to require regular (eg annual) audit. (Bug #528303)
    • Max Time Between Audits: It has been suggested that, when the CA cert policy is revised, we specify the maximum period allowed between audits.
      • WebTrust currently specifies 12 months.
      • ETSI certificates appear to be issued every three years, and failing a subsequent annual audit would cause the certification to be canceled. This doesn't stop us from requiring an annual public statement from the ETSI auditors, but we would need to specify exactly what we need the statement to say because it will be produced solely for this purpose.
    • http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/4ad6c15661a5df4f#
  • Root Changes
    • Security Compromise: When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed.
    • Changing Trust Bits: Enabling a trust bit of a root currently in NSS requires going through the same review and approval process as root inclusion.
    • Disabling a Root: Who can request, why, how.
    • Enabling EV: Enabling EV for a root currently in NSS requires going through the full review and approval process.
    • Removing a Root: Who can request, why, how. (Bugs #500043 and #413375)
  • OCSP Max Expiration: OCSP responses in end-entity certs should be limited to a reasonable maximum expiration time, e.g. 10 days.
  • nextUpdate for CRLs for end-entity certs should be limited to a reasonable time frame; e.g. less than 10 days.
  • Long-lived DV certificates: The expiration times of DV certificates should be short enough to mitigate risk, for instance 2 years or less.
    • POSTPONED. This item was postponed. In this phase we added the 4th bullet in #6 of the Inclusion Section: verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less;
  • Email Address Prefixes for DV Certs
    • Email addresses used for challenge-response mechanisms to verify ownership/control of domain names should be limited to a particular list.
    • Bug 477783 and Bug 556468 are specific cases where this was problematic.
  • Specify the types of signatures and moduli that are supported
    • https://wiki.mozilla.org/CA:MD5and1024
    • http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/7b9a3130311daf49#
    • Minimum Key Sizes: One suggestion for a future revision of the CA Cert Policy is that we should specify minimum key sizes, either just for roots or for roots, intermediates and end entity certificates. The exact restrictions would need to be discussed, but doubtless we would take into account the views of our crypto team and advice from places like NIST.
    • We expect that all new certificates contain randomness (preferably in the Serial Number), especially when using the SHA-1 hash function or RSA key size smaller than 2048 bits.
      • Perhaps that should be amended to say something like "cryptographically secure randomness" or some specification of how many bits of entropy should be included (as a guideline at least).
  • In sections 7 and 8 of the Mozilla CA Certificate Policy:
    • Remove references to June 30, 2008 and update to current EV criteria text and links.
    • Make it clear that the "attestation of their conformance to the stated verification requirements" needs to be a "public attestation"; e.g. the auditor must provide a public statement of compliance with the corresponding criteria.
    • Add ETSI TS 102 042 EV criteria.
    • Update the information and link for: "WebTrust Principles and Criteria for Certification Authorities" in AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0;
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/PolicyVersion2.0&oldid=1239758"