500043 - Create Policy for Removing CAs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

Based on recent discussions, it looks like Mozilla needs to create a policy/procedure for removing CAs for one or more of the following reasons:
Security Compromise
Expired or Expiring CA
Less than 2048-bit
MD2 or MD5
Transition/Rollover to new root completed
Legacy, no longer in use

Comment 1

[Frank Hecker]

Kathleen, if you have time and are willing to do it then I am happy with you being assigned the primary responsibility for creating a draft version of such a policy. I'll note this in the m.d.s.policy newsgroup as well.

Comment 2

[Kyle Hamilton]

My two cents on this (since I haven't heard anything in the past six months):

Security Compromise: Leave in NSS, disable all trust bits.

Less than 2048-bit root: leave in NSS with only email trust if and only if the CA makes a statement that it will not issue any further certificates under the root (even from sub-CAs), leave in NSS and remove all bits if the CA does not provide such a statement.  (I would recommend that this be a form of contract between the CA and Mozilla so that Mozilla has standing to bring action if the CA issues a new certificate under it.)

Expired or Expiring CA: Same treatment as less-than-2048-bit-root.  (Nelson has stated, and as far as I've been able to read them, that neither RFC5280 nor RFC3280 make any statements about the X.509 container which is used to package the trust anchor, other than that its data can be used to calculate the Authority of issued certificates.  It does not state that any given trust anchor is beholden to the expiration date of the X.509 certificate that contains or is used to distribute it.)

MD2 or MD5: Provide vendor with notice of intent to disable all trust bits unless they issue and provide a new CA self-signed certificate with better hashes.  Give 6 to 12 months to comply (as CPSes need to be updated to allow for reissuance of self-signed root certs), leave old root in NSS and disable all trust bits if not provided, leave old root in NSS and add new root in NSS until old root's expiration date, at which time only email trust bits should remain on old-root.

Transition/Rollover to new root completed: If the CA representative certifies that the old root has been transitioned from, I believe it's most appropriate to allow the CA to determine whether to transparently (no user intervention required) support old email certificates issued from that root, or to provide its own technical support to opaquely (user intervention requiring full technical support) support re-adding the old root.  This should be a business decision on the part of the CA, not a requirement imposed by Mozilla.

Legacy/No longer in use: Same as Transition/Rollover.  This one should allow for the business to state affirmatively what the last possible expiration date of any certificates issued under its authority could be (the latest expiration date on any certificate that the root directly issued, since RFC 3280 and 5280 both state that if any certificate in the chain is not yet valid or is no longer valid that the chain must be rejected).

Any CA that does not provide an annual audit report: 45-day grace period, else remove all trust bits.

-security, -thunderbird, and -firefox all need to be notified of any actions made, and if the NSS team (Kathleen with potential intercedence by Frank) believes that it is severe enough to warrant a mid-cycle update to the Mozilla softwares impacted.

Comments requested (as it's blocking the removal of a certificate that meets 3 of these states: less-than-1024-bit-root, Legacy/no-longer-used, Transition/Rollover).

Comment 3

[Kathleen Wilson]

I have created a new wiki page which outlines the process for changing a root certificate that is currently included in NSS. This includes the process for disabling or removing a root certificate from NSS.

https://wiki.mozilla.org/CA:Root_Change_Process

This page is linked to from https://wiki.mozilla.org/CA:Overview in the "Work in progress" section. The link is called "Root Change Process".

In writing this process, I have taken into account input that was provided through previous discussions, bug postings, the previous removal policy notes (https://wiki.mozilla.org/CA:Root_Removal_Policy_Notes), and my current work to clean up the legacy roots that are no longer audited/used.

> Less than 2048-bit root: 
Email has been sent to the relevant CAs requesting a date for when their 1024-bit roots may be disabled or removed from NSS. Soon I will also start a discussion thread in mozilla.dev.security.policy to recommend dates for phasing out all 1024-bit roots in NSS.

> MD2 or MD5: 
MD2 has already been turned off in NSS. Currently working on determining when MD5 can be turned off in NSS. Still two CAs that this heavily impacts. I'm continuing to investigate this to determine if we can turn off MD5 using the NSS environment variable, or if we'll have to disable/remove roots separately. Further discussion may be found/continued in mozilla.dev.security.policy.

> Transition/Rollover to new root completed:
and
> Legacy/No longer in use:
Please see https://wiki.mozilla.org/CA:Root_Change_Process

> Any CA that does not provide an annual audit report: 
This has been one of my higher priority projects. I've almost got all updated audits or agreement from the CA to disable/remove the root.

Roots that haven't been recently audited are included in my other project to disable/remove legacy roots: bug #534274

> Comments requested (as it's blocking the removal of a certificate that meets 
> 3 of these states: less-than-1024-bit-root, Legacy/no-longer-used,
> Transition/Rollover).

I believe the root that you reference is also in bug #534274.

Comment 4

[Kathleen Wilson]

I believe that this bug has been completed with the combination of updates to the Mozilla CA Certificate Policy 
http://www.mozilla.org/projects/security/certs/policy/index.html 
and the introduction of the wiki page describing the Root Change Process
https://wiki.mozilla.org/CA:Root_Change_Process

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Kathleen, 
Isn't updating Mozilla's CA Certificate policy the point of this request?  
In what sense is this resolved if the policy is not updated?

Comment 6

[Kathleen Wilson]

(In reply to comment #5)
> Kathleen, 
> Isn't updating Mozilla's CA Certificate policy the point of this request?  
> In what sense is this resolved if the policy is not updated?

Mozilla's CA Certificate policy was updated, and published on Feb 2, 2011.

(In reply to comment #0)
> Based on recent discussions, it looks like Mozilla needs to create a
> policy/procedure for removing CAs for one or more of the following reasons:
> Security Compromise
> Expired or Expiring CA
> Less than 2048-bit
> MD2 or MD5
> Transition/Rollover to new root completed
> Legacy, no longer in use


See sections 8, 9, and 10 of the Maintenance Policy
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

And see the Enforcement Policy
http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Sorry, I misread comment 4.  Thanks for your reply.