Closed Bug 881553 Opened 11 years ago Closed 9 years ago

Remove or turn off trust bits for 1024-bit root certs after December 31, 2013

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: The final changes for this are in Firefox 38) 

According to https://wiki.mozilla.org/CA:MD5and1024
“December 31, 2013 – Mozilla will disable the SSL and Code Signing trust bits for root certificates with RSA key sizes smaller than 2048 bits. If those root certificates are no longer needed for S/MIME, then Mozilla will remove them from NSS.”

Here are the 1024-bit root certs that are included in NSS.

== Entrust ==
Entrust.net
(c) 1999 Entrust.net Limited	
Entrust.net Secure Server Certification Authority	
1999 May 25	
2019 May 25	
SHA-1

== GoDaddy ==
ValiCert, Inc.	
ValiCert Class 2 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 26	
2019 Jun 26	
SHA-1

== IdenTrust ==	
Digital Signature Trust Co.	DSTCA E1	
Digital Signature Trust Co. Global CA 1	
1998 Dec 10	
2018 Dec 10	
SHA-1

Digital Signature Trust Co.	
DSTCA E2	
Digital Signature Trust Co. Global CA 3	
1998 Dec 09	
2018 Dec 09	
SHA-1

== NetLock == 	
NetLock Halozatbiztonsagi Kft.	
Tanusitvanykiadok	
NetLock Expressz (Class C) Tanusitvanykiado	
1999 Feb 25	
2019 Feb 20	
MD5

NetLock Halozatbiztonsagi Kft.	
Tanusitvanykiadok	
NetLock Uzleti (Class B) Tanusitvanykiado	
1999 Feb 25	
2019 Feb 20	
MD5

== RSA the Security Division of EMC ==
ValiCert, Inc.	
ValiCert Class 3 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 26	
2019 Jun 26	
SHA-1

== SECOM ==	
ValiCert, Inc.	
ValiCert Class 1 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 25	
2019 Jun 25	
SHA-1

== Symantec ==
Equifax	
Equifax Secure Certificate Authority	
Equifax Secure CA	
1998 Aug 22	
2018 Aug 22	
SHA-1

Equifax Secure	
Equifax Secure eBusiness CA-2	
Equifax Secure eBusiness CA 2	
1999 Jun 23	
2019 Jun 23	
SHA-1

Equifax Secure Inc.		
Equifax Secure eBusiness CA-1	
1999 Jun 21	
2020 Jun 21	
MD5

Equifax Secure Inc.		
Equifax Secure Global eBusiness CA-1	
1999 Jun 21	
2020 Jun 21	
MD5

Thawte Consulting cc	
Certification Services Division	
Thawte Premium Server CA	
1996 Aug 01	
2020 Dec 31	
MD5

Thawte Consulting cc	
Certification Services Division	
Thawte Server CA	
1996 Aug 01	
2020 Dec 31	
MD5

VeriSign, Inc.	
VeriSign Trust Network	
VeriSign Class 2 Public PCA – G2	
1998 May 18	
2028 Aug 01	
SHA-1

VeriSign, Inc.	
Class 3 Public Primary Certification Authority	
VeriSign Class 3 Public PCA	
1996 Jan 29	
2028 Aug 01	
MD2

VeriSign, Inc.
Class 3 Public Primary Certification Authority	
VeriSign Class 3 Public PCA	
1996 Jan 29	
2028 Aug 02	
SHA-1
	
VeriSign, Inc.	
VeriSign Trust Network	
VeriSign Class 3 Public PCA – G2	
1998 May 18	
2028 Aug 01	
SHA-1

VeriSign Trust Network	
VeriSign Class 1 Public PCA – G2	
1998 May 17	
2028 Aug 01	
SHA-1

== Verizon ==
GTE Corporation	
GTE CyberTrust Solutions, Inc.	
GTE CyberTrust Global Root	
1998 Aug 13	
2018 Aug 13	
MD5
All, please post a comment in this bug regarding your CA's 1024-bit root certificates that are listed above to indicate:

1) The root certificates that may be removed in Q1, 2014.

2) The root certificates that need to remain in NSS with only the S/MIME trust bit enabled.

Thanks,
Kathleen
Status: NEW → ASSIGNED
Root Certificate below can be removed in Q1, 2014:

== RSA the Security Division of EMC ==
ValiCert, Inc.	
ValiCert Class 3 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 26	
2019 Jun 26	
SHA-1

Thanks,

Robert Legendre
RSA
robert.legendre@rsa.com
Could you help us understand the browser response to a root removal, where it may still be deployed on a web server. The Entrust root in question has been used to provide extended trust to the root certificate used for EV. The Entrust EV root certificate is also embedded by Mozilla.

If a user goes to a site and sees a CA certificate from the Entrust (1024) root to the Entrust EV root, will the user still see the green SSL trust indication?

Thanks, Bruce.
(In reply to Bruce Morton from comment #3)
> Could you help us understand the browser response to a root removal, where
> it may still be deployed on a web server. The Entrust root in question has
> been used to provide extended trust to the root certificate used for EV. The
> Entrust EV root certificate is also embedded by Mozilla.

Currently in Firefox, treatment of cross-signing depends on the notAfter/notBefore dates of the certificates in question (which one was issued later). Firefox currently only builds one path, and if it builds the wrong path, it won't try to build another one.

You can test this behavior now with a cert that chains up to both Entrust's 1024-bit root cert and Entrust's 2048-bit root cert that was created in 2006. According to the notBefore in the roots (1999 and 2006), Firefox is currently only creating the path to the 2048-bit root. Turning off the websites trust bit of the 1024-bit root cert will have no impact.

The test website I have for the 1024-bit root is https://validev.entrust.net. When I browse to the site and view the cert chain via the cert manager I see the 2048-bit root (and EV treatment is given for this site).  Also, I turned off all of the trust bits for the 1024-bit root, and I still get EV treatment when I browse to https://validev.entrust.net/
The test site for the Entrust 1024-bit root is https://ssltest.entrust.net. The test site for the Entrust EV root is https://validev.entrust.net. However, the issuing CA is the same for the 1024-bit root and another 2048-bit root. 

It looks like Firefox embeds the CA certificate that was issued by one of the roots - probably the first one it encounters. This messes up the test of the other root as the path is changed.

I think the way to resolve this problem is to have the test certificates issued directly from the root, then no issuing CA certificate can interfere with the test.

Bruce.
Although our preference would be to keep the following root active until the risk to 1024-bit RSA was greater, I can confirm that this is the correct Entrust 1024-bit root to remove.

== Entrust ==
Entrust.net
(c) 1999 Entrust.net Limited
Entrust.net Secure Server Certification Authority
1999 May 25
2019 May 25
SHA-1

Thanks, Bruce.
Please remove the GTE CyberTrust Global Root expiring August 13, 2018 in Q1, 2014.  Verizon intends to produce CRLs and keep this root under audit until it expires or is no longer feasible.  Upon removal from Mozilla root stores, Mozilla Root Policy is understood to no longer apply to our operation of this root.  Certain environments that do not rely on Mozilla's root stores have critical need to continue operation as we migrate this root from public to private closed PKI community status.
(In reply to Bruce Morton from comment #5)
> The test site for the Entrust 1024-bit root is https://ssltest.entrust.net.
> The test site for the Entrust EV root is https://validev.entrust.net.
> However, the issuing CA is the same for the 1024-bit root and another
> 2048-bit root. 


I fixed my spreadsheet.


> 
> It looks like Firefox embeds the CA certificate that was issued by one of
> the roots - probably the first one it encounters. This messes up the test of
> the other root as the path is changed.


As per Comment #4, Firefox currently only builds one path -- using the root with the newer notBefore/notAfter dates.

So https://ssltest.entrust.net is a good test case, because its website cert chains up to both the old 1024 and 2048 bit roots. The 1024 bit root cert has notBefore date of May 25, 1999. The 2048 bit root cert has notBefore date of Dec 24, 1999. As expected, Firefox only builds the path to the 2048 bit root. Turning off the trust bits for the 1024-bit root has no impact.
Dear Kathleen,

Please set the SMIME bit for these Netlock roots at 2013-12-31.

== NetLock == 	
NetLock Halozatbiztonsagi Kft.	
Tanusitvanykiadok	
NetLock Expressz (Class C) Tanusitvanykiado	
1999 Feb 25	
2019 Feb 20	
MD5

NetLock Halozatbiztonsagi Kft.	
Tanusitvanykiadok	
NetLock Uzleti (Class B) Tanusitvanykiado	
1999 Feb 25	
2019 Feb 20	
MD5


Regards, Viktor Varga
Netlock
IT service and Customer Service Executive
Dear Kathleen-san,

You can remove our root certificate below in Q1, 2014.


== SECOM ==	
ValiCert, Inc.	
ValiCert Class 1 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 25	
2019 Jun 25	
SHA-1

Best regards,
Hisashi Kamo
Please remove the ValiCert Class 2 root identified below in Q1 2014.

== GoDaddy ==
ValiCert, Inc.	
ValiCert Class 2 Policy Validation Authority	
http://www.valicert.com/	
1999 Jun 26	
2019 Jun 26	
SHA-1

Thanks, Wayne
Here's the current status on this bug...

> == Entrust ==
> Entrust.net
> (c) 1999 Entrust.net Limited	
> Entrust.net Secure Server Certification Authority	
> 1999 May 25	
> 2019 May 25	
> SHA-1

Remove cert in Q1, 2014.


> == GoDaddy ==
> ValiCert, Inc.	
> ValiCert Class 2 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 26	
> 2019 Jun 26	
> SHA-1

Remove cert in Q1, 2014.


> == IdenTrust ==	
> Digital Signature Trust Co.	DSTCA E1	
> Digital Signature Trust Co. Global CA 1	
> 1998 Dec 10	
> 2018 Dec 10	
> SHA-1
> 
> Digital Signature Trust Co.	
> DSTCA E2	
> Digital Signature Trust Co. Global CA 3	
> 1998 Dec 09	
> 2018 Dec 09	
> SHA-1


Only the email trust bit is enabled for these two IdenTrust root certs, so no action needed.


> == NetLock == 	
> NetLock Halozatbiztonsagi Kft.	
> Tanusitvanykiadok	
> NetLock Expressz (Class C) Tanusitvanykiado	
> 1999 Feb 25	
> 2019 Feb 20	
> MD5
> 
> NetLock Halozatbiztonsagi Kft.	
> Tanusitvanykiadok	
> NetLock Uzleti (Class B) Tanusitvanykiado	
> 1999 Feb 25	
> 2019 Feb 20	
> MD5

Turn off websites and code signing trust bits for these two NetLock root certs in Q1 2014.



> == RSA the Security Division of EMC ==
> ValiCert, Inc.	
> ValiCert Class 3 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 26	
> 2019 Jun 26	
> SHA-1

Remove cert in Q1, 2014.

> 
> == SECOM ==	
> ValiCert, Inc.	
> ValiCert Class 1 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 25	
> 2019 Jun 25	
> SHA-1

Remove cert in Q1, 2014.


> == Symantec ==
> Equifax	
> Equifax Secure Certificate Authority	
> Equifax Secure CA	
> 1998 Aug 22	
> 2018 Aug 22	
> SHA-1

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?


> Equifax Secure	
> Equifax Secure eBusiness CA-2	
> Equifax Secure eBusiness CA 2	
> 1999 Jun 23	
> 2019 Jun 23	
> SHA-1

Already removed, bug #856718.


> Equifax Secure Inc.		
> Equifax Secure eBusiness CA-1	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?

> Equifax Secure Inc.		
> Equifax Secure Global eBusiness CA-1	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?

> Thawte Consulting cc	
> Certification Services Division	
> Thawte Premium Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5

The email trust bit is not set. So remove cert in Q1, 2014.



> Thawte Consulting cc	
> Certification Services Division	
> Thawte Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5

The email trust bit is not set. So remove cert in Q1, 2014.


> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 2 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1

Need response from Symantec. Email and code signing trust bits currently enabled. So remove cert in Q1? Or disable code signing trust bit?


> VeriSign, Inc.	
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 01	
> MD2

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?


> VeriSign, Inc.
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 02	
> SHA-1

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?
	
> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 3 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1

Need response from Symantec. All three trust bits currently enabled. So remove cert in Q1? Or disable websites and code signing trust bits?


> VeriSign Trust Network	
> VeriSign Class 1 Public PCA – G2	
> 1998 May 17	
> 2028 Aug 01	
> SHA-1

Only the email trust bit is enabled for these two IdenTrust root certs, so no action needed.


> == Verizon ==
> GTE Corporation	
> GTE CyberTrust Solutions, Inc.	
> GTE CyberTrust Global Root	
> 1998 Aug 13	
> 2018 Aug 13	
> MD5

Remove cert in Q1, 2014.
Kathleen, I agree with Bruce in Comment 6 - our preference would be to keep most 1024-bit roots active until the risk to 1024-bit RSA was greater. Leaving the roots active would match Microsoft's policy, and would make it easier for CAs and our customers to understand what's going to happen with 1024-bit roots. I think much would be gained by having all major browser vendors agree on a policy on these roots, as well as other issues. The CAB Forum would be a great place to have this discussion. In the meantime, can you explain the risk of leaving these roots active, and why Mozilla's policy is different from Microsoft's?

For the most part, we've been issuing off our 2048-bit roots for years, and giving customers a cross-certificate that would allow their SSL cert to also chain up to 1024-bit roots for older browsers. Those customers will be unaffected if the 1024-bit roots are removed. However, the CAB Forum allows SSL certificates to be issued directly from 1024-bit roots (Section 12 of the Baseline Requirements), and Symantec has a number of customers that have asked for such certificates to be issued directly from these roots. The difficulty we face is identifying those customers, reaching out to them to see if they would be affected by the removal of the root, and planning a workaround for them if they would be affected. We need more time to complete this. The Q1 2014 deadline is arbitrary.
Rick, 

Please help me understand Symantec's situation. 

According to Appendix A of the BRs, subscriber certs with validity period ending after 31 Dec 2013 must have minimum RSA modulus of 2048. As you pointed out, BR #12 allows for an "old" 1024-bit root cert to directly sign an end-entity cert. I believe this means that SSL certs that expired after 2013 and are directly issued from a 1024-bit cert must have minimum RSA modulus of 2048. 

Has Symantec been issuing 2048-bit end-entity SSL certificates directly from 1024-bit root certificates? If yes, why? 

Does Symantec continue to issue SSL certificates directly from 1024-bit root certificates?  If yes, why?

What older browsers are you referring to that support 2048-bit end-entity SSL certs, but not 1024-bit root certs?

> The difficulty we face is identifying those customers, reaching out to them to see if 
> they would be affected by the removal of the root, and planning a workaround for them 
> if they would be affected. We need more time to complete this.

I see. So how about if we identify which of the above root certificates will still be compliant with the BRs after 31 Dec 2013 and will still need to have the websites and code signing trust bits set?  Perhaps the most efficient way to do this would be to run a scan of the Symantec databases to determine which of the 1024-bit root certs actually have directly issued (2048-bit) SSL certificates that will still be compliant with the BRs after 31 Dec 2013.


> The Q1 2014 deadline is arbitrary.

Perhaps, but I would like to complete as much of this work as possible now. I prefer to turn off trust bits or remove the 1024-bit root certs before it becomes a crisis. If you do have a specific need for certain 1024-bit root certs to continue to issue SSL certs that are compliant with the BRs, then please tell us specifically which roots those are. I see no reason to hold up work on all of the other 1024-bit root certificates for those.

Also, note that in response to a CA Communication that I sent in 2010
https://wiki.mozilla.org/CA:Communications#October_11.2C_2010
and further followup with the VeriSign representatives at that time, I received the following:
"3. Support for SHA1 1024 bit roots:
December 31, 2013 is a reasonable date to record for VeriSign."
(In reply to Kathleen Wilson from comment #14)
> Rick, 
> 
> Please help me understand Symantec's situation. 
> 
> According to Appendix A of the BRs, subscriber certs with validity period
> ending after 31 Dec 2013 must have minimum RSA modulus of 2048. As you
> pointed out, BR #12 allows for an "old" 1024-bit root cert to directly sign
> an end-entity cert. I believe this means that SSL certs that expired after
> 2013 and are directly issued from a 1024-bit cert must have minimum RSA
> modulus of 2048. 
> 
> Has Symantec been issuing 2048-bit end-entity SSL certificates directly from
> 1024-bit root certificates? If yes, why?

Yes, because customers have asked us to. I suspect it's because they're non-browser applications that have embedded our roots. The only way to confirm that is to reach out to each of them and ask. I've talked with a very small number of customers that have confirmed, but there are more.
 
> Does Symantec continue to issue SSL certificates directly from 1024-bit root
> certificates?  If yes, why?

Yes, because customers ask us to, and the BRs allow it. It's not our default. It's a very manual, expensive process that customers ask for and pay for because they have no other option. 
 
> What older browsers are you referring to that support 2048-bit end-entity
> SSL certs, but not 1024-bit root certs?

I didn't say they were browsers. I suspect they're all non-browser apps, but I need to confirm.
 
> > The difficulty we face is identifying those customers, reaching out to them to see if 
> > they would be affected by the removal of the root, and planning a workaround for them 
> > if they would be affected. We need more time to complete this.
> 
> I see. So how about if we identify which of the above root certificates will
> still be compliant with the BRs after 31 Dec 2013 and will still need to
> have the websites and code signing trust bits set?  Perhaps the most
> efficient way to do this would be to run a scan of the Symantec databases to
> determine which of the 1024-bit root certs actually have directly issued
> (2048-bit) SSL certificates that will still be compliant with the BRs after
> 31 Dec 2013.

I'm in the process of doing this, although it's somewhat involved. Every root I've looked at so far has some certs issued directly from it. I'm focusing right now on two roots that I think might be removed with the least impact, but I suspect that we might need almost all of them to remain with the websites and code signing trust bits set.

> > The Q1 2014 deadline is arbitrary.
> 
> Perhaps, but I would like to complete as much of this work as possible now.
> I prefer to turn off trust bits or remove the 1024-bit root certs before it
> becomes a crisis. If you do have a specific need for certain 1024-bit root
> certs to continue to issue SSL certs that are compliant with the BRs, then
> please tell us specifically which roots those are. I see no reason to hold
> up work on all of the other 1024-bit root certificates for those.
> 
> Also, note that in response to a CA Communication that I sent in 2010
> https://wiki.mozilla.org/CA:Communications#October_11.2C_2010
> and further followup with the VeriSign representatives at that time, I
> received the following:
> "3. Support for SHA1 1024 bit roots:
> December 31, 2013 is a reasonable date to record for VeriSign."

That comment was made over three years ago by someone who has since left the company. He made that statement without full knowledge of the extent of the issue.

What's behind all this is that over the years, customers have (usually without our knowledge) embedded our roots into non-browser applications, and now they find that browser policy is dictating what they can and can't do. In retrospect, had we known about these applications, we would have created private hierarchies for them. But we didn't, and now we're just trying to avoid major crises in payment systems and mobile applications (just to give two examples).
(In reply to Rick Andrews from comment #15)
> What's behind all this is that over the years, customers have (usually
> without our knowledge) embedded our roots into non-browser applications, and
> now they find that browser policy is dictating what they can and can't do.
> In retrospect, had we known about these applications, we would have created
> private hierarchies for them. But we didn't, and now we're just trying to
> avoid major crises in payment systems and mobile applications (just to give
> two examples).


Please help me understand... If the customers have embedded these roots into non-browser applications, then why would it matter to them if these root certs are or aren't in NSS?
One more thing... While you're doing the scans, please also get an idea of when those certs expire. I'm interested to see what Symantec would like to have as the date for turning off the SSL and Code Signing trust bits for these 1024-bit roots.
(In reply to Kathleen Wilson from comment #16)
> (In reply to Rick Andrews from comment #15)
> > What's behind all this is that over the years, customers have (usually
> > without our knowledge) embedded our roots into non-browser applications, and
> > now they find that browser policy is dictating what they can and can't do.
> > In retrospect, had we known about these applications, we would have created
> > private hierarchies for them. But we didn't, and now we're just trying to
> > avoid major crises in payment systems and mobile applications (just to give
> > two examples).
> 
> 
> Please help me understand... If the customers have embedded these roots into
> non-browser applications, then why would it matter to them if these root
> certs are or aren't in NSS?

You're right, it wouldn't matter to them if they're not using a browser. But I just don't know if they're using a browser or not (except for a few that I've talked to already) - that's the uncertainty.
OK. My current understanding is that Symantec is working to evaluate the situation of these 1024-bit root certs, and it is *possible* that you will need more time to complete the transition for some customers.  Correct?

Please update this bug with progress during your evaluation, to indicate which roots you have evaluated and when you expect that the SSL and code signing trust bits can be turned off for them.

In the meantime, would it help if we provide a test build that has the SSL and Code Signing trust bits disabled for these root certs?  


> It's a very manual, expensive process that customers ask for and pay for 
> because they have no other option. 

In that case, it would seem that it should be a manageable number of customers that will have to be contacted.

I would like to note that perhaps the customers "had no other option" because all of the other CAs were actively working to transition off of their 1024-bit root certs. This could be interpreted as one CA taking advantage of the situation while other CAs were diligently trying to meet Mozilla's requests and improve security on the internet.
I would also like to note that it would have been nice if Symantec (or it's subsidiaries) had taken notice of the reasons the customers "had no other option", and determined then if these customer's certs could be issued in a private CA hierarchy.

Anyways, my goal is to move off of the 1024-bit certs as quickly as possible. If Symantec needs a little longer than Q1 2014 for certain root certs, then we can discuss this.
I created bug #936105 for tracking Symantec's 1024-bit root certs that have the Websites and/or Code Signing trust bits enabled.

So now this bug is only in regards to the following root certificates.


> == Entrust ==
> Entrust.net
> (c) 1999 Entrust.net Limited	
> Entrust.net Secure Server Certification Authority	
> 1999 May 25	
> 2019 May 25	
> SHA-1

Remove cert in Q1, 2014.


> == GoDaddy ==
> ValiCert, Inc.	
> ValiCert Class 2 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 26	
> 2019 Jun 26	
> SHA-1

Remove cert in Q1, 2014.


> == NetLock == 	
> NetLock Halozatbiztonsagi Kft.	
> Tanusitvanykiadok	
> NetLock Expressz (Class C) Tanusitvanykiado	
> 1999 Feb 25	
> 2019 Feb 20	
> MD5
> 
> NetLock Halozatbiztonsagi Kft.	
> Tanusitvanykiadok	
> NetLock Uzleti (Class B) Tanusitvanykiado	
> 1999 Feb 25	
> 2019 Feb 20	
> MD5

Turn off websites and code signing trust bits for these two NetLock root certs in Q1 2014.


> == RSA the Security Division of EMC ==
> ValiCert, Inc.	
> ValiCert Class 3 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 26	
> 2019 Jun 26	
> SHA-1

Remove cert in Q1, 2014.


> == SECOM ==	
> ValiCert, Inc.	
> ValiCert Class 1 Policy Validation Authority	
> http://www.valicert.com/	
> 1999 Jun 25	
> 2019 Jun 25	
> SHA-1

Remove cert in Q1, 2014.


> == Verizon ==
> GTE Corporation	
> GTE CyberTrust Solutions, Inc.	
> GTE CyberTrust Global Root	
> 1998 Aug 13	
> 2018 Aug 13	
> MD5

Remove cert in Q1, 2014.
Depends on: 936304
(In reply to Kathleen Wilson from comment #20)

I have filed bug #936304 against NSS for the actual changes.
Depends on: 936105
Could we please get a status update for this important change? It seems that, despite the deadlines passing, the roots remain in use. Given that breaking 1024-bit RSA key seems to be rather cheap (estimated $10m in 2003, $1m in 2013), I think it's reasonable to assume that these weak roots provide little to no security.
We decided to do compatibility testing before making the actual code changes, so we plan to group the compatibility testing as follows.

Group 1 (compatibility testing happening this week)
Bug #936304 (Non-Symantec 1024-bit roots)
Bug #986005 (VeriSign 1024-bit roots)

Group 2
Bug #986014 (Thawte 1024-bit roots)

Group 3
Bug #986019 (Equifax 1024-bit roots)
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Clearing - this is not specific to b2g.
blocking-b2g: 2.1? → ---
Now an entire year has passed since the deadline for this (2013-12-31). Is there any progress update available?
Most difficult to remove seems to be Thawte and Equifax, because they issued certificates directly from 1024-bit roots.
The Thawte roots have been removed (Bug #986014), and we're working towards the schedule for removal of the Equifax root provided in Bug #986019.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: See link in Comment #29 → The final changes for this are in Firefox 38
To be clear...

There are still 1024-bit root certificates included in NSS with only the Email trust bit enabled.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS#CA_certificates_pre-loaded_into_NSS
"Consumers of this list must consider the trust bit setting for each included root certificate."
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.