Hi Michael,
Have you given any more thought to a redesign of ca-certificates that
separates the email certificates from the TLS certificates? I suspect
that the vast majority of packages that depend on ca-certificates use
it for TLS server auth, and yet there are currently 21 roots in the NSS
store that are trusted for email but distrusted for TLS server auth:
1 AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.
2 ComSign CA
3 Equifax Secure CA (1024-bit)
4 Equifax Secure Global eBusiness CA (1024-bit)
5 Equifax Secure eBusiness CA 1 (1024-bit)
6 NetLock Business (1024-bit)
7 NetLock Express (1024-bit)
8 NetLock Qualified
9 S-TRUST Authentication and Encryption Root CA 2005 PN
10 S-TRUST Universal Root CA
11 Sonera Class 1 Root CA
12 SwissSign Platinum CA - G2
13 TC TrustCenter Class 3 CA II
14 UTN USERFirst Email Root CA
15 Verisign Class 1 Public Primary Certification Authority (1024-bit)
16 Verisign Class 1 Public Primary Certification Authority - G2 (1024-bit)
17 Verisign Class 1 Public Primary Certification Authority - G3
18 Verisign Class 2 Public Primary Certification Authority - G2 (1024-bit)
19 Verisign Class 2 Public Primary Certification Authority - G3
20 Verisign Class 3 Public Primary Certification Authority (1024-bit)
(non-BR-compliant)
21 Verisign Class 3 Public Primary Certification Authority - G2 (1024-bit)
Ten of these are 1024-bit RSA roots. Over the past year, Mozilla has
been removing the TLS trust bit from 1024-bit roots, and at long last
the NSS root store no longer contains any 1024-bit roots trusted for
TLS. Unfortunately, Debian applications continue to trust them for TLS.
This reduces the security of TLS authentication down to the cost of
factoring just one of these 1024-bit roots. It would be great to bring
the security level of Debian's root store up to 2048 bits for TLS.
In addition, the "Verisign Class 3 Public Primary Certification
Authority" root (owned by Symantec) is still trusted despite its TLS
trust bit being removed in NSS. As of December 1, 2015, this root is
being used to issue certificates that don't comply with the Baseline
Requirements:
https://googleonlinesecurity.blogspot.com/2015/12/proactive-measures-in-digital.html
As such, this root should be distrusted ASAP.
As always, let me know if you could use any help. I'm going to start
looking through the reverse depends for ca-certificates to identify
packages that might be relying on roots for email authentication.
Thanks,
Andrew
