229335 - Remove certificates that expired in August 2004 from tree

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[Igor Pohis]

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

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 2

[Jeff Walden [:Waldo]]

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.

Comment 3

[chris hofmann]

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.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I can't imagine why this should block anything.  Chris?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 6

[Wan-Teh Chang]

*** Bug 266307 has been marked as a duplicate of this bug. ***

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Giving this bug to Wan-Teh.  I don't work on the built-in root list any more.

Comment 8

[Julien Pierre]

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.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 10

[Kai Engert [:KaiE:]]

Shall changes to the root CA list be approved by Gerv / Mozilla.org before I go ahead and remove it?

Comment 11

[Gervase Markham [:gerv]]

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

Comment 12

[Kai Engert [:KaiE:]]

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

[Kai Engert [:KaiE:]]

Attachment: 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.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

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 15

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 16

[Gervase Markham [:gerv]]

Nelson: sounds sensible. Thanks for clueing me in.

Gerv

Comment 17

[Kai Engert [:KaiE:]]

(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

Comment 18

[Kai Engert [:KaiE:]]

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

Comment 19

[Kai Engert [:KaiE:]]

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 20

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 271935 [details] [diff] [review]
Patch v1

I'll ask Julien to SR this patch.

Comment 21

[Kai Engert [:KaiE:]]

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: 1.36.24.9; previous revision: 1.36.24.8
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.37.24.8; previous revision: 1.37.24.7
done