User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 If you check "Authorities" tab in "Manage Certificates" dialog in either Firebird 0.7, Mozilla 1.4.1 and Mozilla 1.0.1, you will see that those include following certificates which will expire in August 2004 VeriSign, Class 1 Public Primary OCSP Responder Class 2 Public Primary OCSP Responder Class 3 Public Primary OCSP Responder Above was detected using WIN2000 Firebird 0.7 downloaded from Mozilla.org On SUN Mozilla 1.4.1 built with NSS 3.8.1 Beta, besides all above mentioned certificates, there is also another one which will exprire in August 2004 Secure Server OCSP Responder VeriSign, Secure Server OCSP Responder Reproducible: Always Steps to Reproduce: go to "Authorities" tab in "Manage Certificates" dialog Expected Results: Certificates that will soon expire may be removed, see http://bugzilla.mozilla.org/show_bug.cgi?id=69556 as somewhat similar example
These are intermediate CA certs. We don't usually put intermediate CA certs into the built-in token, IIRC. Unless we have some contractual obligation to ship these, I agree we can just remove them when they expire.
I don't know if this has been done or not, but if it hasn't this would be one way to reduce build size by a very small amount.
is this fix picked up in the move to the latest NSS release? I'll plus this if it is. is there a bug some one can refer me to on that work? I think we need to move forward on picking up the the latest NSS quickly.
I can't imagine why this should block anything. Chris?
I see Chris isn't on the cc list, so ... I'm removing the blocking-aviary flag from this P3 bug,, since AFAIK the presence of these old certs causes NO problems for anyone. If these were root CA certs used to issue email certs, we'd want to leave them in so that email signatures can continue to be checked, retrospectively, even after their expirations. But since these certs are only used for OCSP, and OCSP signatures are not expected to be preserved and checked long after, it's no problem to remove them shortly after they expire. There are a number of new requests to add new root certs to NSS, and I will implement them for NSS 3.10. I will plan to work on this request (for cert removal) for NSS 3.10 also.
*** Bug 266307 has been marked as a duplicate of this bug. ***
Giving this bug to Wan-Teh. I don't work on the built-in root list any more.
Who is now in charge of the root cert module maintenance ? I seem to recall that we make a decision not to remove expired CAs before, but I am not certain.
Yes, we did decide not to remove expired root CA certs. But the certs requested in this bug are intermediate CA certs. I believe Kai is now doing to root CA module work.
Shall changes to the root CA list be approved by Gerv / Mozilla.org before I go ahead and remove it?
I have no problem with the removal of any expired certs. If and when there is an external list of all the certs included (something like http://www.mozilla.org/projects/security/certs/included/ ) then I would need to be notified so I could update that. But that's not true yet. (It seems from comment #9 that the NSS team has decided not to remove expired root certs; I'd be interested to know why that was.) Gerv
I propose we restrict this fix to the trunk of NSS, this seems to have a very low priority, but as it's absolutely trivial to fix, I'll attach a patch now.
Created attachment 271935 [details] [diff] [review] Patch v1 Obvious patch to remove the 4 certs. I'm only including the changes to certdata.txt, I'll of course run the script to produce the updated .c file at the time I check it in.
The reasons not to remove expired certs are a) There is no benefit from removing them, and there is some potential harm. b) There is benefit to leaving them in place. Leaving them in place allows you to continue to verify signatures on old emails and old signed JAR files, and to continue to decrpyt email messages sent to you when your cert chained up to that old root, before it expired. This allows you to continue to have access to documents that you know you have already verified the signatures on back when the certs were not yet expired. (One generally does not save emails or JAR files that have invalid signatures at the time they are received.) Removing the old certs makes it impossible to verify subordinate certs thereafter, which makes signature reverification and other re-uses of certificates impossible thereafter. I have emails that were signed with certs issued subordinate to a now- expired GTE root. Today, I can still read them and verify the signatures on them. If that cert is removed, I will no longer be able to do that. How, then, does removal of that cert benefit me?
Comment on attachment 271935 [details] [diff] [review] Patch v1 This patch is good, as far as it goes, but MAY be incomplete. Depending on what release of NSS will include this patch, it may also be necessary to change the nssckbi version number, if it hasn't already been changed by a previous patch in this same release. Please indicate the target NSS release for this patch, so we can determine if additional nssckbi version number changes are needed.
Nelson: sounds sensible. Thanks for clueing me in. Gerv
(In reply to comment #15) > Please indicate the target NSS release for this patch See my comment 12, I propose to do this on trunk only for 3.12, so I didn't include changes to nssckbi.h
Fixed on trunk. Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.44; previous revision: 1.43 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.44; previous revision: 1.43 done
Nelson, this is the bug that removed the root CA certs that would like to see removed on the 3.11 branch, too. Who should do the second review for branch landing?
Comment on attachment 271935 [details] [diff] [review] Patch v1 I'll ask Julien to SR this patch.
checked in to NSS 3.11 branch. I did not update the version number, because we have recently done so already (and no release since that change). marking fixed. Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 220.127.116.11; previous revision: 18.104.22.168 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 22.214.171.124; previous revision: 126.96.36.199 done