Remove certificates that expired in August 2004 from tree



14 years ago
10 years ago


(Reporter: Igor Pohis, Assigned: kaie)


Firefox Tracking Flags

(Not tracked)



(1 attachment)

27.11 KB, patch
Nelson Bolyard (seldom reads bugmail)
: review+
Julien Pierre
: superreview+
Details | Diff | Splinter Review


14 years ago
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

  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

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
  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 as
somewhat similar example


14 years ago
Version: unspecified → 3.8.1
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.  
Ever confirmed: true
Priority: -- → P3
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.
Flags: blocking-aviary1.0?
Summary: certificates that will expire in August 2004 are present in Firebird 0.7, Mozilla 1.4.1 CA tree → Remove certificates that expired in August 2004 from tree

Comment 3

13 years ago
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.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
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.
Assignee: wchang0222 → nelson
Flags: blocking-aviary1.0+
Target Milestone: --- → 3.10

Comment 6

13 years ago
*** Bug 266307 has been marked as a duplicate of this bug. ***
QA Contact: bishakhabanerjee → jason.m.reid
Giving this bug to Wan-Teh.  I don't work on the built-in root list any more.
Assignee: nelson → wtchang
Target Milestone: 3.10 → ---
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries

Comment 8

10 years ago
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.
Assignee: nobody → kengert

Comment 10

10 years ago
Shall changes to the root CA list be approved by Gerv / 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 ) 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.)


Comment 12

10 years ago
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.


Comment 13

10 years ago
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.
Attachment #271935 - Flags: review?(nelson)
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.
Attachment #271935 - Flags: review?(nelson) → review+
Nelson: sounds sensible. Thanks for clueing me in.


Comment 17

10 years ago
(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
Target Milestone: --- → 3.12

Comment 18

10 years ago
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
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.44; previous revision: 1.43
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 19

10 years ago
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?
Resolution: FIXED → ---
Comment on attachment 271935 [details] [diff] [review]
Patch v1

I'll ask Julien to SR this patch.
Attachment #271935 - Flags: superreview?(julien.pierre.boogz)


10 years ago
Attachment #271935 - Flags: superreview?(julien.pierre.boogz) → superreview+

Comment 21

10 years ago
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:; previous revision:
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision:; previous revision:
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.