Closed Bug 487150 Opened 15 years ago Closed 14 years ago

Removal request of StartCom 1024 bit CA root

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eddy_nigg, Assigned: nelson)

References

Details

As the representative of StartCom I request hereby the removal of the StartCom CA root which was added to NSS in bug 338552. Removal may be performed at any time during the period from the first of June 2009 (2009-06-01) and the thirty-first of December 2009 (2009-12-31), but no later.

The root with the common name "Free SSL Certification Authority" has a RSA key size of only 1024 bit and uses Netscape extensions which are not commonly used anymore. StartCom has successfully transitioned all its CA business to a newer root which is also included in NSS and doesn't need this root to be supported by Mozilla anymore. The root should not be disabled, but removed in order to allow previous subscribers to import the root for their convenience (for example for the reading of previously encrypted email messages).

I'd appreciate coordination and confirmation of the removal in order to avoid any mistakes during this process (as not to remove the wrong root).
Assignee: kathleen95014 → hecker
Nelson, Are you the correct person to assign the removal requests to?  If not, would you please assign this bug to the correct person? Thanks.
Assignee: hecker → nelson
Kathleen, This may be only the first or second request we've ever had to 
remove a root cert, and is certainly the first request to remove a cert 
that has not yet expired.  I'm not aware of a clear policy about such 
requests, nor of a well defined procedure for doing so.  

My first reaction is to think that we ought to use a process similar to the
one we use to put a root CA cert into NSS.  We should have a policy (first)
and a public discussion for each such request.  Then when the policy process
has rendered a decision, we should file a separate NSS bug to make the 
change.  

My second reaction is to think that a separate NSS bug may be unnecessary,
but the policy and decision process seem vital.

More opinions:

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).  

I guess the right thing to do immediately is to file an RFE, requesting a 
new policy on cert removal, and mark that bug as "blocking" this one.
My take on this is, that no discussion should be needed. As the CA requesting removal there are considerations beyond explicit key compromise. As such I believe it would be to the disadvantage of the software vendor to keep a root which was explicitly requested to be removed.

Discussion is useful in case Mozilla would want to to remove roots without consent or request from the CA. I think there should be a policy for such cases.
Depends on: 500043
I have created bug 500043 for creating a policy for removing CAs.

The bug is currently assigned to me. Is there someone else who the bug should be assigned to?  

If I'm the correct person to do this, then is it a matter of creating a wiki page to describe the process, and then putting it up for discussion?
I think we need to differ between request made directly by the CA and a removal policy for other reasons without the involvement of the CA (expired, inactive, compromised, etc.). IMO this request is straightforward as it comes from a CA.

Eventually the bug needs to be assigned to Nelson for the actual removal from NSS.

(In reply to comment #2)
> 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.

What us concerns, any interested party may import this root manually into the software for validating old signatures.
Eddy, your point #3 is understood, it just needs to be incorporated into the policy or whatever document.

People can't remove the root unless they have the authorisation to do so.  The policy would clarify what authorisation is needed.  Right now, there is no real policy, so it probably defaults to "if Frank says so."  You asking isn't good enough.

Point #5 ditto, into the policy.
It's a good idea create a root certiticate remove policy, as we want rollover, as specified by the law and NIST after the end of 2010.

My opinion is the following:

If you remove a root certificate, you cant give a detail about certificate issued with that root.

Maybe it is much better to do a ceck with it.

Examples:
1) a CA was compromised:
a) root was removed
you get a message about unknown root, and the user clicks, to accept it, and uses the possibly wrong certificate
b) root was marked as an unusable certificate
(sorry, an enter was hit)

b) root was marked as an unusable certificate 
the user can get a big red flag.

2) a CA is valid, but it is 1024 bit and it is after the NIST deadline
you can check date, and if it is after the deadline, you can give a yellow flag

3) a CA is valid, but the hash algorithm is broken
you can give a red flag about the CA

My examples are not exactly conceptions, but maybe we should think on the cases of the certificate usage, and create series of handlers, to give the maximum security for the users.
Right. In our case (as I believe it's yours), there is no compromise, but this root is going to archival now. I guess your #2 applies. Kathleen and Frank started to work on the removal policy (see m.d.s.policy mailing list)
The "Free SSL Certification Authority" root cert has been removed from NSS as per bug #554330. The change is in Firefox 3.6.7.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.