232347 - OCSP Responder Certificates Expiring

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[David E. Ross]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113

Verisign and RSA OCSP Responder certificates delivered with Mozilla expire July
and August 2004.  These are certificate authority (CA) certificates.  

While there is no problem yet, the certificates should be updated for the next
release of Mozilla (before they expire).  Also, for those users who do not
immediately update to the next version of Mozilla, information should be
provided on how to obtain new certificates to import.   

The affected certificates are:  

For Verisign --
Class 1 Public Primary OCSP Responder (expires 3 Aug 04)
Serial # 2B:68:D4:A3:46:9E:C5:3B:28:09:AB:38:5D:7F:27:20

Class 2 Public Primary OCSP Responder (expires 31 Jul 04)
Serial # 09:46:17:E6:1D:D8:D4:1C:A0:0C:A0:62:E8:79:8A:A7

Class 3 Public Primary OCSP Responder (expires 3 Aug 04)
Serial # 2E:96:9E:BF:B6:62:6C:EC:7B:E9:73:CC:E3:6C:C1:84

For RSA --
Secure Server OCSP Responder (expires 3 Aug 04)
Serial # 00:FF:45:D5:27:5D:24:FB:B3:C2:39:24:53:57:E1:4F:DE


Reproducible: Always
Steps to Reproduce:
1.  Select Edit > Preferences
2.  Select Privacy & Security > Certificates
3.  Select the Manage Certificates button
4.  Select the Authorities tab
5.  Select any of the CA certificates I indicated
6.  Select the View button

Actual Results:  
Under Validity, note the Expires On date is in the summer of 2004.  

Expected Results:  
Under Validity, the Expires On date should be some later year.  

First answer the question:  Are OCSP certificates still used?  All other CA
certificates have expiration dates far in the future.  If OCSP certificates are
no longer used, they should be deleted from the next Mozilla version.

Comment 1

[timeless]

http://www.verisign.com/support/vendors/ocsp.html

for lack of a better url it seems ocsp isn't dead, although it might be the case
that our impl won't work...

Comment 2

[John G. Myers]

Nelson, is this not an NSS issue?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

John, 
No, these are intermediate CA certs, not root CA certs.  
If these intermediate CA certs are in the cert DB, I'm not sure why.
It is both necessary and sufficient for NSS to have the ROOT of the chain
trusted.  
The OCSP responder will send out a complete cert chain.  
When the old intermediate CA certs expire, the server will send out the 
new ones, and NSS should honor the new ones that it received in the chain
over the ones it had before in the cert DB.

I believe there is another bug that reports this same thing, that has been
closed invalid.  This bug should duplicate that one.

Comment 4

[David E. Ross]

Certificates on the Authorities tab of the Certificates Manager window expire in
less than six months.  Before this bug is closed as a duplicate of some other
INVALID bug, the following questions should be addressed:  

1.  If those certificates indeed belong there, then will it not be a bug for
expired certificates to be included with any version of Mozilla released after 3
Aug?  And if so, when should that bug be fixed if not before the certificates
expire?  

2.  If those certificates do not belong there, then why is their presence not a
bug?  

3.  And finally, since Mozilla 1.6 is likely to still be in some use after 3 Aug
(since we know that many business installations and some home installations will
not upgrade immediately when Mozilla 1.7 or even Mozilla 1.8 is released), what
mitigation will be appropriate for Mozilla 1.6 (according to whether the
certificates belong or not) and how will that be documented?  

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The presence of these certificates after their expiration dates causes 
no problem.  These certs have no trust flags.  They're just extra certs.
Users who have cert8.db files that were derived from old cert7.db files
made prior to moz 1.3 may also have these certs in their cert7 and cert8.db
files.  Removing these certs from the built-in list is no more urgent than 
remvoing them from users' cert8.db files.  No mitigation is necessary.  
Think of them as dead code (after their expiration dates).  

My *guess* is that AOL/Netscape had a contractual obligation to include
these certs in Netscape branded products, and they are left-overs from the
era in which AOL/Netscape controlled mozilla's built-in trusted root list
(as are all the certs presently in Moz's built-in trust list).  

Once bug 233453 is resolved and a new public mozilla foundation policy is
in place governing which certs belong in the built-in list, then if it is
determined that these certs do not belong there, they should be removed.

In the meantime, I see no reason to try to urgently remove them prior to
their expiration dates.  I'd say that they should be removed in the next
release thereafter (again, assuming that bug 233453 isn't resolved sooner).

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I'm marking this bug invalid.

The presence of these certs in the built-in list is causing no failures,
and is apparently as was intended at the time they were added.  

When bug 233453 is resolved, I am sure that ALL the certs in the built-in
list will be reviewed for consistency with that new policy.  And I expect
there will be big changes then.  :)

Until then, we have no basis upon which to remove these certs, other than
if they were causing a problem (e.g. false positive or false negative cert
chain validation), which they are not, and will not, even after they expire.

Comment 7

[David E. Ross]

While my concerns were not addressed in the form I expected, I concur that
comment #5, comment #6, and bug #233453 are collectively sufficient to mark this
closed.