There appears to be two legacy roots that are owned by RSA and still
included in NSS. I am waiting for a representative from RSA to confirm that the
following two roots may be disabled:
OU = ValiCert Class 3 Policy Validation Authority
CN = http://www.valicert.com/
1999 Jun 25 to 2019 Jun 25
OU = RSA Security 1024 V3
2001 Feb 22 to 2026 Feb 22
I have exchanged email with both RSA and VeriSign, and both have stated that they do not own the "RSA Security 1024 V3" root certificate.
Therefore, I will recommend that the "RSA Security 1024 V3" root certificate be removed from NSS.
RSA has stated that they own the"ValiCert Class 3 Policy Validation Authority" root certificate. However, there does not appear to be a recent audit that covers this root.
Therefore, I plan to recommend that the "ValiCert Class 3 Policy Validation Authority" root certificate be disabled in NSS. I am waiting for response from RSA as to when the last end-entity cert under this root expires, and if the email trust bit should remain enabled.
I received the following in email from an RSA representative:
The ValiCert Class 3 root is still actively in use for certificate
validation and cannot be disabled at this time.
In the past we used the ValiCert Class 3 root to sign the RSA Public
Root CA cert that is covered under our WebTrust audit and is used for
the actual issuance of customer CA certs under our RSA Root Signing
Service. No new CA signings are being performed under the ValiCert
Class 3 root hierarchy, but there are customers that still have active
certificates chaining to the ValiCert Class 3 root.
I would recommend a target date of no earlier than 1/1/2012 for disabling the ValiCert Class 3 root.
I have confirmed that the recent WebTrust audit report covers the "RSA Public Root CA V1" and "RSA Security 2048 V3" root certificates.
Therefore, in this bug I will only propose that the "RSA Security 1024 V3" root certificate be removed from NSS.
I am now opening the public discussion period for this request to remove the "RSA Security 1024 V3" root certificate from NSS.
Public discussion will be in the mozilla.dev.security.policy newsgroup and the
corresponding firstname.lastname@example.org mailing list.
The discussion thread is called “Recommend Removing RSA Security 1024 V3 root certificate authority”
Please actively review, respond, and contribute to the discussion.
I'm no longer involved with NSS and I'm not going to participate in newsgroup discussions. bugzilla should be sufficient for this. As the one who did the checkin for this cert, I will say that the certs were verified by at least 3 people internally before checkin and I'm surprised that someone is disclaiming ownership of the root. Unfortunately, company e-mail records are no longer available and all the people involved have moved on. If possible, I would recommend a search for public SSL servers that have certificates chaining to this root to see if it appears to have ever been used.
I have received email from official representatives of RSA confirming that RSA did indeed create the "RSA Security 1024 V3" root certificate that is currently included in NSS.
In regards to my previous statement from Comment #1: "I have exchanged email with both RSA and VeriSign, and both have stated that they do not own the "RSA Security 1024 V3" root certificate."
I probably should have been more cautious about how I worded that statement. The response that I regularly got from RSA when requesting information about this root was:
"The RSA Root Signing Service (RSS) has two active Root CAs:
- http://www.valicert.com/ (AKA "ValiCert Class 3 Policy Validation Authority" )
- RSA Security 2048 V3"
OK. That's a very different situation then, if we know that RSA owns the private key, but is just no longer issuing certs with that root. Unless the key was compromised, there is no security risk posed by trusting this root.
Depending on the last activity date for this root (which should be provided by RSA), we may or may not want to remove this root. The process for dealing with inactive roots in general should be followed. In the past, old roots were simply kept. What's a little different about this one is that it isn't expired yet, and it doesn't expire for a long time still. I don't believe the Mozilla certificate policy addresses how to deal with inactive roots either way. I think unless the root CA private key was compromised, we may want to treat this bug as a WONTFIX.
Nonoono...please see https://wiki.mozilla.org/CA:Root_Change_Process#Remove_a_Root
This must be fixed obviously. There is nobody taking any responsibility and the root isn't audited.
RSA has confirmed that they are in possession of the private key for the "RSA Security 1024 V3" root certificate. RSA agrees that this root should be removed from NSS.
There is no recent audit for this "RSA Security 1024 V3" root certificate, because it is no longer in use. Therefore, I will continue with the root removal process as described in
The public comment period for this request is now over.
This request has been evaluated as per
Based on the recent response from RSA, and the input provided during the public discussion, it is clear that this "RSA Security 1024 V3" root certificate should be removed from NSS.
On behalf of the Mozilla project I approve this request to remove the following root certificate from NSS:
OU = RSA Security 1024 V3
O = RSA Security Inc
Valid From: 2/22/01
Valid To: 2/22/26
I will file the NSS bug to effect the approved change.
I have filed bug #557937 against NSS for the actual changes.
Is it the case that all the certs ever issued subordinate to this root
are now believed to be expired?
If so, how recently did the last one expire?
Nelson, It doesn't sound like this root was ever actively used. The following is from an email from RSA on April 6: "The RSA Security 1024 V3 root was created along with the RSA Security 2048 v3 root back in February 2001, but it is not a root that RSA employs or has ever been active to deliver the RSS or any other service."
Thanks for this added information, Kathleen. That satisfies all my remaining
In Firefox 3.6.7.