CA:Root Removal Policy Notes

Mozilla CA Root Removal Policy Notes

The purpose of this wiki page is to gather input on creating a policy for removing CA root certificates from NSS. This page is open to everyone, so please add your input/comments directly. Adding content is greatly appreciated, but please don’t delete anything, but rather add a comment if you think something should be removed.

Summary and Policy Rational

CA root certificates may need to be removed from NSS for one or more of the following reasons:

• Security Compromise
• Expired or Expiring CA
• Small modulus key length, NIST recommend that 1024 bit roots be phased out by the end of 2010
• Outdated signing key algorithm, such and MD2 and MD5
• Transition/Rollover to new root completed
• Legacy, no longer in use
• The CA has requested (via a bug report) a site certificate to be removed

Goals of Policy/Process:

• To have a completely open and public process, with public posting of all policy drafts and public discussion of what should go into the policy.
• To make explicit all the underlying rationales for why the policy is the way it is, including referencing available third-party documents that support particular policy decisions.
• To make an effort to get input from people who don't normally participate in mozilla.dev.security.policy discussions, including the development teams for Firefox, Thunderbird, SeaMonkey, Camino, and other Mozilla-based products, as well as representatives of CAs.
• To create a policy that is clear and understandable, is the product of a transparent public process, can be justified as reasonable given the current state of knowledge in the crypto/PKI/CA world, and is compatible with the general way we operate in the Mozilla project.

Comments:

• It doesn't hurt anything to leave roots in NSS past their expiration date,and it is occasionally useful for validating signatures on old emails, etc. For a CA whose ONLY purpose is to issue SSL server certs, which have no long term use after they expire, I see no reason to keep them after they expire. But email and code signing certs are different, because they validate signatures on long lived things (emails, code files) long after.
• I also think that we should not remove a cert before its expiration unless the CA has utterly repudiated that cert (e.g. declared a compromise).
• What’s the best way to get input from people who don’t normally participate in mozilla.dev.security.policy discussions?
• A root certificate cannot be added to NSS without a request from the CA. A request from the CA to remove a root certificate should be treated as if the original request to add it was then withdrawn. The CA should not be required to express a reason for the request to remove the certificate. The CA might have a reason that precludes actually revoking the certifcate. However, legacy uses of mail and code-signing certificates can indeed create a need for a certificate to remain in use despite the CA's request. Thus, the CA's request should prevail only for site certificates; for mail and code-signing certificates, the action should be to remove the trust bit for sites instead of removing the certificate itself.

Suggestions about what the policy should include

Information that the policy should include:

• Which root certificates should be removed, and when:
  • NIST recommend that 1024 bit roots be phased out by the end of 2010
  • Other?

• Reasons a root certificate may be removed:
  • Security Compromise
  • Expired or Expiring CA
  • Small modulus key length (1024 or smaller)
  • Outdated signing key algorithm, such as MD2 or MD5
  • Transition/Rollover to new root completed
  • Legacy, no longer in use

• Actions that the CA is required to perform before a root certificate may be removed.
  • provide ?
  • publicly disclose information about ?
  • prior to removing the CA certificates, verify ?

• Required notifications when a root certificate is to be removed, for example
  • For security compromise or legacy reasons, the CA should be notified.
  • Other?

Comments:

Suggestions about the Policy Language

Using much of the text from the Mozilla CA Policy, I have created the shell for the Removal Policy:

http://www.mozilla.org/projects/security/certs/removal-policy/

Please add your comments/recommendations about the text in the removal-policy here.

Comments:

• In the case of security compromise or legacy roots, we probably don’t want to depend on the CA filing a bug to request removal. On the other hand, I’m sure a CA would not want some random person to be able to file a root certificate removal request on their behalf. Should it be limited to an official representative of either the CA or Mozilla?
• iang I disagree.
  • CAs are making representations to relying parties, who are known persons according to CA's RPA. They are also (potentially, arguably) creating risks for non-related persons, those who aren't relying parties according to their RPA, for whom Mozilla stands in for. The existence of the audit process and the mozilla policy bears testament to the risks, liabilities and obligations of all these parties.
  • Obviously, CAs only and every reaction will be to suppress all claims by all others all the time.
  • It is therefore both important and difficult to know who has valid and relevant claim to make against a CA or CA's root.
  • I would therefore prefer that anyone can file a bug against a root or a CA, and that there be an easy procedure for dismissing the bug.
  • And, I would suggest that Mozilla explicitly create a "safe harbour" for doing so by being precise as to the method.
• iang I think the notion of a removal policy is a bit too precise.
  • There may be many other things that we want to do, such as deliver instructions to fix things, give deadlines, change settings.
• iang Some of the removals are likely to happen in adverse circumstances, so a policy is necessary but isn't sufficient.
  • We need a filing procedure. That is easy, just use the bugzilla.
  • We need a procedure whereby the due attention is paid to claims in a formal setting, so that any decision can stand up in court.
  • We need a decision maker. Relatively easy: Mozilla Foundation.
  • In any adverse setting, the CA will be talking to their lawyers. It should be planned as if it will end up in court. This doesn't mean it will end up in court, quite the reverse. It doesn't end up in court, because you planned it as if it would end up in court. So, lay the chain of events and the evidence carefully.
  • All of this can be the same for both adversarial and non-adversarial process. The latter can just speed it up by an order of magnitude. Doing it this way means that when we come to the former case, it has a chance of working.
• iang There needs to be a little bit more formalism with the CAs
  • Technically there should be a written contract
  • the bug filed to get a root added can be implied into a contract
  • but it's very messy ... better to have a description page that lays out what the contract is, referring to all the other areas.
  • also, we need to get CAs to accept that Mozilla has jurisdiction over its root, and has the ability and right and desire to remove roots and other actions.
  • At the moment, it could be argued that Mozilla provides a public service, and does not have the right to not provide it. Or some blah blah.
• iang Which is to say, this "root removal" project will have implications on other areas. Perhaps move some of these points to the talk page?

Suggestions about the Process

High level process for removal of a root certificate:

1. CA or Mozilla representative files bug
2. Mozilla representative ensures necessary information provided
3. Public discussion on mozilla.dev.security.policy
4. Approval (or not)
5. Assignment of bug to appropriate person for actual changes to NSS
6. Test
7. Notification

Comments:

• Should the root cert actually be removed from NSS? Or is there a another alternative that would enable an appropriate error message to be returned when an attempt is made to use a “removed” root cert?
• Mozilla should have a rapid response plan for removing a compromised root, and corresponding procedures to test the removal.
• When a CA requests a root certificate to be removed (a site certificate), should the removal be delayed by this process? The only process that should be required is to authenticate the source of the request.