Personal tools

CA:Root Change Process

From MozillaWiki

Jump to: navigation, search

Contents

Changing a Root Certificate that is Currently Included in NSS

This page describes how to change the default settings of a root certificate that is currently included in NSS.

Reasons to change a root certificate in NSS may included, but are not limited to:

  • Security Compromise
  • Add a Trust Bit (one of Websites, Email Code Signing)
  • Enable EV
  • Disable a Root (turn off one or more of the trust bits)
  • Remove a Root

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.

Add a Trust Bit

When a root certificate is included in NSS, one or more of the three trust bits (websites, email, code signing) are enabled. It is common for a CA to request inclusion with a subset of the trust bits enabled, and then later request that an additional trust bit be enabled. The following steps outline how a CA may request to enable additional trust bits for a root certificate that is included in NSS.

  1. Do some initial preparations before you formally submit a request:
  2. Once you are ready, formally submit your request using the Mozilla project's Bugzilla issue tracking system:
    • Click on the "Create a new bug report" link in CA:How_to_apply.
    • Set the bug summary to "Enable trust bits for <name of your root>".
    • In the bug description, include a reference to the original root-inclusion bug number.
    • In the bug description, include links to the updated CP/CPS and the updated audit.
  3. The request will go through the Information Gathering and Verification, Public Discussion, and Inclusion phases as described in CA:How_to_apply.

Enable EV

The following steps outline the procedure for a CA to request that Extended Validation (EV) be enabled for a root certificate that is currently included in NSS.

  1. Do some initial preparations before you formally submit a request:
  2. Once you are ready, formally submit your request using the Mozilla project's Bugzilla issue tracking system:
    • Click on the "Create a new bug report" link in CA:How_to_apply.
    • Set the bug summary to "Enable EV for <name of your root>".
    • In the bug description, include a reference to the original root-inclusion bug number.
    • In the bug description, include links to the updated CP/CPS and the WebTrust EV audit.
  3. The request will go through the Information Gathering and Verification, Public Discussion, and Inclusion phases as described in CA:How_to_apply

Disable a Root

Disabling a root is the act of turning off one or more of the three trust bits (Websites, Email, Code Signing).

Reasons for disabling a root certificate may include, but are not limited to:

Important: Root changes that are motivated by a serious security concern such as a major root compromise should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed.

The process for disabling a root in NSS is as follows:

  1. Any individual may initiate the request using the Mozilla project's Bugzilla issue tracking system:
    • File a bug in Bugzilla with the following information:
      • Product: mozilla.org
      • Component: CA Certificates
      • Summary: Disable (CN or cert name) root cert
      • Description: Include the following information
        • Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
        • The certificate Common Name and or Certificate Name
        • If needed, other information to clearly identify which root is to be changed (eg SHA1 Fingerprint)
        • Which trust bits are to be turned off
        • Reason for requesting this change
        • Impact that the change may have on Mozilla users
    • The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.
      • The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root.
    • In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA.
  2. The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the standing module owner.
  3. The Mozilla representative will ensure the necessary information has been provided.
    • Options should be identified
      • Which trust bits to unset (Websites, Email, Code Signing)
      • Whether the root certificate should be removed from NSS instead of unsetting trust bits
    • Technical assistance may be requested
    • Additional information may be requested of CA and other parties
    • The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either
      • The known representative of the CA, or
      • Two Mozilla staff members, if the CA is not in agreement.
  4. The Mozilla representative will deliver any preliminary decisions
  5. The Mozilla representative whom the bug is assigned to will start a public discussion in the mozilla.dev.security.policy newsgroup.
    • Outline is presented, references to full bug provided
    • Deadline for discussion is set
    • Security-sensitive requests for root changes would be discussed primarily within the (closed) Mozilla security group. However others could be added to the discussion by explicitly cc-ing them on the bug.
  6. The Mozilla representative whom the bug is assigned to will summarize the discussion and communicate the decisions in the bug.
    • Decision about which trust bits to unset
    • Any other options or actions as decided
  7. Implementation
    • If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.
    • A Mozilla representative creates a test build of NSS with the change to the root certificate, and attaches nssckbi.dll to the bug. A representative of the CA or of Mozilla must download this, drop it into a copy of Firefox and/or Thunderbird and confirm (by adding a comment in the bug) that the certificate has been correctly changed.
    • A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
    • For security-sensitive bugs, the security update will proceed as described in Mozilla's Policy for Handling Security Bugs
    • For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.
  8. Notification
    • The CA is responsible for providing appropriate notification to users who may be impacted by the change.
    • For Security-sensitive requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.

Remove a Root

Kathleen: I’ve been thinking about the result of an included root being caught in something serious, such as a MITM attack. If that does happen, then it might be better to disable the trust bits of that root by default, rather than just removing the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for SSL in Firefox unless a user specifically turned on the websites trust bit for it.

Reasons for removing a root certificate may include, but are not limited to:

  • Security Compromise
    • Root removals that are motivated by a serious security concern such as a major root compromise should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed.
  • Expired or Expiring CA
  • Small modulus key length (e.g. 1024-bit or smaller)
  • Outdated signing key algorithm (e.g. MD2 or MD5)
  • Transition/Rollover to new root completed
  • Legacy, no longer in use
  • No recent audit
  • Previously deprecated

Note: For some root certificates it may be better to turn off the websites trust bit and leave one or both of the email and code singing trust bits enabled. The Disable a Root section above explains how to request that specific trust bits be turned off for a root certificate.

The process for removing a root from NSS is as follows:

  1. Any individual may initiate the request using the Mozilla project's Bugzilla issue tracking system:
    • File a bug in Bugzilla with the following information:
      • Product: mozilla.org
      • Component: CA Certificates
      • Summary: Remove (CN or cert name) root cert
      • Description: Include the following information
        • Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
        • The certificate Common Name and or Certificate Name
        • If needed, other information to clearly identify which root is to be changed (eg SHA1 Fingerprint)
        • Reason for requesting that the root be removed
        • Impact that removing the root may have on Mozilla users
    • The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.
      • The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.
    • In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA.
  2. The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the standing module owner.
  3. The Mozilla representative will ensure the necessary information has been provided.
    • Options should be identified
      • Whether the root certificate should be removed from NSS instead of unsetting trust bits
    • Technical assistance may be requested
    • Additional information may be requested of CA and other parties
    • The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either
      • The known representative of the CA, or
      • Two Mozilla staff members, if the CA is not in agreement.
  4. The Mozilla representative whom the bug is assigned to will deliver any preliminary decisions
  5. The Mozilla representative whom the bug is assigned to will start a public discussion in the mozilla.dev.security.policy newsgroup.
    • Outline is presented, references to full bug provided
    • Deadline for discussion is set
    • Security-sensitive requests for root removals would be discussed primarily within the (closed) Mozilla security group. However others could be added to the discussion by explicitly cc-ing them on the bug.
  6. The Mozilla representative will summarize the discussion and communicate the decisions in the bug.
    • Decision about whether or not to remove the root certificate
    • Any other options or actions as decided
  7. Implementation
    • If the resulting decision is to remove or change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.
    • A Mozilla representative creates a test build of NSS with the change to the root certificate, and attaches nssckbi.dll to the bug. A representative of the CA or of Mozilla must download this, drop it into a copy of Firefox and/or Thunderbird and confirm (by adding a comment in the bug) that the certificate has been correctly changed or removed.
    • A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
    • For security-sensitive bugs, the security update will proceed as described in Mozilla's Policy for Handling Security Bugs
    • For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.
  8. Notification
    • The CA is responsible for providing appropriate notification to users who may be impacted by the change.
    • For Security-sensitive requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.