Closed Bug 592939 Opened 15 years ago Closed 15 years ago

Expired CAs in certdata.txt

Categories

(NSS :: CA Certificates Code, task, P3)

3.12.7

Tracking

(Not tracked)

RESOLVED FIXED
3.12.9

People

(Reporter: dj, Assigned: dj)

References

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6) Gecko/20100706 Firefox/3.6.6 Build Identifier: mozilla-central head Searched around for a while, but did not find any previous report of this. I would have expected that this has been filed well before now, but I'm seeing an Equifax cert that expired in 2004? Additionally, one that expired in June of 2010. Entries are still present as of rev 1.65. 8f111d69 and f2cce23a are the openssl-1.0 hash values. No idea how to convert those values to anything meaningful WRT to certdata.txt, but maybe patches are more transparent. See attachments: remove-1.diff and remove-2.diff (resp). Reproducible: Always Steps to Reproduce: 1. N/A 2. 3.
This CA expired in 2004? I have no idea why it is still there. Please review.
Recently expired on June 20, 2010. New one available? Please review.
IIUC, the expired Equifax cert has already been replaced by the one with SHA1: \176\170\112\020\034\202\145\314\055\341\361\155\107\264\100\312\331\012\031\105 No replacement for the beTRUSTed Root CA that I'm aware of (Entrust only now?)
Comment on attachment 471397 [details] [diff] [review] Remove long expired Equifax CA 6 years seems like long enough. :)
Attachment #471397 - Flags: review+
Assignee: nobody → dj
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → 3.12.9
Version: unspecified → 3.12.7
Comment on attachment 471399 [details] [diff] [review] Remove recently expired beTRUSTed Root CA [checked in] Normally, I would say we don't want to be too hasty in removing recently expired certs. It's much less confusing for a user to get a message about expired issuer than about unknown issuer, for a cert she's used in the past. But in this case, this issuer was never actually trusted for anything. -CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN -CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN So I'm not sure why it was even in the trust list in the first place.
Attachment #471399 - Flags: review+
(In reply to comment #4) > Comment on attachment 471397 [details] [diff] [review] > Remove long expired Equifax CA > > 6 years seems like long enough. :) Slow down, careful... - the cert this patch would remove is actually: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C= US" Validity: Not Before: Mon Jun 21 04:00:00 1999 Not After : Sun Jun 21 04:00:00 2020 Subject: "CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C =US" [...] The one which "expired in 2004" is this one here, however (which I'm sure Nelson will remember quite well)... note the subject, in particular: Certificate: Data: Version: 3 (0x2) Serial Number: 66 (0x42) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C= US" Validity: Not Before: Sat Jul 31 00:00:01 2004 Not After : Thu Sep 02 00:00:01 2004 Subject: "CN=MD5 Collisions Inc. (http://www.phreedom.org/md5)" [...]
(In reply to comment #5) > Comment on attachment 471399 [details] [diff] [review] > But in this case, this issuer was never actually trusted for anything. > > -CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN > -CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN > -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NETSCAPE_TRUST_UNKNOWN > > So I'm not sure why it was even in the trust list in the first place. See bug 554334.
(In reply to comment #6) > (In reply to comment #4) > > Comment on attachment 471397 [details] [diff] [review] [details] > > Remove long expired Equifax CA > > > > 6 years seems like long enough. :) > > Slow down, careful... - the cert this patch would remove is actually: > Ouch...sorry guys. > The one which "expired in 2004" is this one here, however (which I'm sure > Nelson will remember quite well)... note the subject, in particular: > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 66 (0x42) > Signature Algorithm: PKCS #1 MD5 With RSA Encryption > Issuer: "CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C= > US" > Validity: > Not Before: Sat Jul 31 00:00:01 2004 > Not After : Thu Sep 02 00:00:01 2004 > Subject: "CN=MD5 Collisions Inc. (http://www.phreedom.org/md5)" > [...] Which is why I asked for review, and the url that I completely ignored explains it quite well. I actually had found nothing interesting upon searching. I have no problem removing it locally from only java cacerts (and leaving it in moz and system as it should remain), but it might be nice to give at least a comment in certdata.txt to keep from getting another bug report. Of course, that wouldn't matter if one selects the incorrect cert for review. :-) I'm terribly sorry about that.
Comment on attachment 471397 [details] [diff] [review] Remove long expired Equifax CA Kaspar, Good catch. I have just found a program I wrote long ago to help me review patches to certdata.txt. It decodes the MULTILINE_OCTAL sections, first from octal, then from DER (using NSS's pp tool). Had I had this a few days ago, I might have caught this. Fortunately, changes such as this typically get reviewed more than once before being committed. Kaspar, will bmo let you add review flags to NSS bugs? (I suspect so) If so, you could have added an "addl. review" flag of r-. Feel free to do so when appropriate (such as in this case). I think you should be a "Peer" of the NSS module. Are you willing?
Attachment #471397 - Flags: review+ → review-
Oh Yes, now I do remember the cert that lived only one second. I created it (!) at Mozilla's request to thwart an attack that would require someone to set their system/browser date back to within the validity period of the original cert with that name, which was compromised. I should add a comment to certdata.txt to point to that bug, for the next time I forget. :) Personally, I don't believe we should be attempting to deal with such attacks. Our security model assumes that the user is in control of his own system and is running it securely, that is, it not allowing an attacker to control his computer. But adding this cert to the list made some people happy at the cost of some mere bloat. So, I think there's just one expired cert here to be potentially removed. The one remaining r+ patch removes it. (I double checked with my tool). The actual decision to remove it requires approval from Kathleen Wilson, I think.
Please clarify exactly which root(s) you are planning to remove. And exactly which trust bits are enabled by default for the affected root(s). In bug #534274 I communicated many times with the CA's whose roots needed to be cleaned up. Some of them agreed to removing the roots, while others requested that only the trust bits be turned off. See https://bugzilla.mozilla.org/show_bug.cgi?id=534274#c17
That would the the attachment 471399 [details] [diff] [review] (Comment 2) for "beTRUSTed Root CA". Certificate expired on June 20th, 2010 and is already unknown trust.
Kathleen, the cert to be removed is this one (extracted from the patch): Certificate: Data: Version: 3 (0x2) Serial Number: 961510791 (0x394f7d87) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=beTRUSTed Root CA,CN=beTRUSTed Root CAs,O=beTRUSTed,C=WW" Validity: Not Before: Tue Jun 20 14:21:04 2000 Not After : Sun Jun 20 13:21:04 2010 Subject: "CN=beTRUSTed Root CA,CN=beTRUSTed Root CAs,O=beTRUSTed,C=WW" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d4:b4:73:7a:13:0a:38:55:01:be:89:56:e1:94:9e:d4: be:5a:eb:4a:34:75:1b:61:29:c4:e1:ad:08:60:21:78: 48:ff:b4:d0:fa:5e:41:8d:61:44:87:e8:ed:c9:58:fa: fc:93:9a:df:4f:ea:3e:35:7d:f8:33:7a:e6:f1:d7:cd: 6f:49:4b:3d:4f:2d:6e:0e:83:3a:18:78:77:a3:cf:e7: f4:4d:73:d8:9a:3b:1a:1d:be:95:53:cf:20:97:c2:cf: 3e:24:52:6c:0c:8e:65:59:c5:71:ff:62:09:8f:aa:c5: 8f:cc:60:a0:73:4a:d7:38:3f:15:72:bf:a2:97:b7:70: e8:af:e2:7e:16:06:4c:f5:aa:64:26:72:07:25:ad:35: fc:18:b1:26:d7:d8:ff:19:0e:83:1b:8c:dc:78:45:67: 34:3d:f4:af:1c:8d:e4:6d:6b:ed:20:b3:67:9a:b4:61: cb:17:6f:89:35:ff:e7:4e:c0:32:12:e7:ee:ec:df:ff: 97:30:74:ed:8d:47:8e:eb:b4:c3:44:e6:a7:4c:7f:56: 43:e8:b8:bc:b6:be:fa:83:97:e6:bb:fb:c4:b6:93:be: 19:18:3e:8c:81:b9:73:88:16:f4:96:43:9c:67:73:17: 90:d8:09:6e:63:ac:4a:b6:23:c4:01:a1:ad:a4:e4:c5 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6334.1.0.0 Policy Qualifier Name: PKIX User Notice Qualifier Display Text: "liance on this certificate by any part y assumes acceptance of the then applicable stand ard terms and conditions of use, and certificatio n practice statement, which can be found at beTRU STed's web site, https://www.beTRUSTed.com/vault/ terms" Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: "https://www.beTRUSTed.com/vault/t erms" Name: CRL Distribution Points Directory Name: "C=WW,O=beTRUSTed" Name: Certificate Subject Key ID Data: 2a:b9:9b:69:2e:3b:9b:d8:cd:de:2a:31:04:34:6b:ca: 07:18:ab:67 Name: Certificate Authority Key Identifier Key ID: 2a:b9:9b:69:2e:3b:9b:d8:cd:de:2a:31:04:34:6b:ca: 07:18:ab:67 Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Key Agreement Certificate Signing CRL Signing Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 79:61:db:a3:5e:6e:16:b1:ea:76:51:f9:cb:15:9b:cb: 69:be:e6:81:6b:9f:28:1f:65:3e:dd:11:85:92:d4:e8: 41:bf:7e:33:bd:23:e7:f1:20:bf:a4:b4:a6:19:01:c6: 8c:8d:35:7c:65:a4:4f:09:a4:d6:d8:23:15:05:13:a7: 43:79:af:db:a3:0e:9b:7b:78:1a:f3:04:86:5a:c6:f6: 8c:20:47:38:49:50:06:9d:72:67:3a:f0:98:03:ad:96: 67:44:fc:3f:10:0d:86:4d:e4:00:3b:29:7b:ce:3b:3b: 99:86:61:25:40:84:dc:13:62:b7:fa:ca:59:d6:03:1e: d6:53:01:cd:6d:4c:68:55:40:e1:ee:6b:c7:2a:00:00: 48:82:b3:0a:01:c3:60:2a:0c:f7:82:35:ee:48:86:96: e4:74:d4:3d:ea:01:71:ba:04:75:40:a7:a9:7f:39:39: 9a:55:97:29:65:ae:19:55:25:05:72:47:d3:e8:18:dc: b8:e9:af:43:73:01:12:74:a3:e1:5c:5f:15:5d:24:f3: f9:e4:f4:b6:67:67:12:e7:64:22:8a:f6:a5:41:a6:1c: b6:60:63:45:8a:10:b4:ba:46:10:ae:41:57:65:6c:3f: 23:10:3f:21:10:59:b7:e4:40:dd:26:0c:23:f6:aa:ae Fingerprint (MD5): 85:CA:76:5A:1B:D1:68:22:DC:A2:23:12:CA:C6:80:34 Fingerprint (SHA1): 5B:CD:CD:CC:66:F6:DC:E4:44:1F:E3:7D:5C:C3:13:4C:46:F4:70:38
Kathleen, The cert that is proposed to be removed is one of the ones that had its trust bits unset about 4 months ago (bug 554334). Now, more recently, it has expired. Do we have any further reason to keep it?
I have exchanged email with Steven Medin of Verizon, and he responded that all of the following roots (which had their trust bits unset in bug 554334) may now be removed from NSS. Steven is also cc'd on this bug now. CN = GTE CyberTrust Root SHA1 Fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6:89:64 CN = beTRUSTed Root CA SHA1 Fingerprint: 5B:CD:CD:CC:66:F6:DC:E4:44:1F:E3:7D:5C:C3:13:4C:46:F4:70:38 CN = beTRUSTed Root CA-Baltimore Implementation SHA1 Fingerprint: DC:BB:9E:B7:19:4B:C4:72:05:C1:11:75:29:86:83:5B:53:CA:E4:F8 CN = beTRUSTed Root CA - Entrust Implementation SHA1 Fingerprint: 72:99:79:13:EC:9B:0D:AE:65:D1:B6:D7:B2:4A:76:A3:AE:C2:EE:16 CN = beTRUSTed Root CA - RSA Implementation SHA1 Fingerprint: 1D:82:59:CA:21:27:C3:CB:C1:6C:D9:32:F6:2C:65:29:8C:A8:87:12
In comment Kathleen requests to remove 5 roots. For the second root in that list we already have an r+'ed patch, which is attachment 471399 [details] [diff] [review]. I'm going to check that in now. We'll do another patch for the remaining 4 roots.
Comment on attachment 471399 [details] [diff] [review] Remove recently expired beTRUSTed Root CA [checked in] Trunk commit: Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.70; previous revision: 1.69 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.67; previous revision: 1.66 done 3.12 branch commit: Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.67.2.3; previous revision: 1.67.2.2 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.64.2.3; previous revision: 1.64.2.2 done
Attachment #471399 - Attachment description: Remove recently expired beTRUSTed Root CA → Remove recently expired beTRUSTed Root CA [checked in]
Attached patch remove 4 CAsSplinter Review
Remove the remaining 4 certs listed in comment 15.
Attachment #491718 - Flags: review?(nelson)
Depends on: 613394
Comment on attachment 491718 [details] [diff] [review] remove 4 CAs I ran my "readable" program on this patch and verified - that it removes four certificates and their trust, - that all four certificates' SHA1 fingerprints were among the five listed in comment 15, and - that all 4 had previously had their trust bits all set to "unknown". r+ = nelson
Attachment #491718 - Flags: review?(nelson) → review+
trunk checkin: Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.72; previous revision: 1.71 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.69; previous revision: 1.68 done
3.12 branch checkin: Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.67.2.5; previous revision: 1.67.2.4 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.64.2.5; previous revision: 1.64.2.4 done
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: