Tuesday, June 23, 2015

June 23, 2015 Microsoft Certificate Trust List Update (Unofficial)

Microsoft June 23, 2015 Certificate Trust List Update

Updated June 27 to reformat New Certificates section

I was reading Mozilla's Bugzilla, in which a gentleman from Keynectis/Opentrust stated:

We have been included in Microsoft root store. This has been confirmed by Jody. 5 new root CAs will be available in Microsoft June release, planned on the 23rd.

If you read my previous post on the Microsoft Certificate Trust List you'd know that it's hard to anticipate Microsoft certificate trust list changes.

To Download a mirror of the Microsoft Certificate Trust List:

md .\wu
certutil.exe -syncwithwu .\wu

I checked this afternoon, yes, the CTL was updated. Some quick analysis of this change, which added 17 Root Certificates and removed 1.
Update:

Several of the new certificates are not trusted for Server Authentication.
There are a few new Certificate Authorities, of which I don't have much information.

I wrote a script to build a MSCACERT.PEM file using the MS Certificate Trust List with just certificates trusted for server authentication, available here:

https://github.com/plaintextcity/MSCTL/blob/master/mscacert.cmd

Microsoft Used to document these changes, for example linked below. Maybe they will start announcing trust changes again soon.

http://social.technet.microsoft.com/wiki/contents/articles/1658.windows-root-certificate-program-members.aspx

The last update is a PDF released in September 2014, which welcomed Saudi Arabia's CA. sha1sum "Windows Root Certificate Program Members - Sept 2014.pdf"

Windows Root Certificate Program Members - Sept 2014.pdf
3a488ca0a3e2e03c452ea559f8fd3882ccc6be74

For an earlier update on Microsoft's trust list changes this year see:
http://www.plaintextcity.com/2015/04/monitoring-microsoft-certificate-trust.html

Update, three of these are ECC 384 bit Roots.

5 2048 bit / sha256WithRSAEncryption
6 4096 bit / sha256WithRSAEncryption
1 4096 bit / sha384WithRSAEncryption
2 4096 bit / sha512WithRSAEncryption
3 384 bit / ecdsa-with-SHA384

The ECC Roots with with links to their test website:

C=FR, O=OpenTrust, CN=OpenTrust Root CA G3
C=FR, O=Certplus, CN=Certplus Root CA G2
C=CN, O=WoSign CA Limited, CN=CA WoSign ECC Root

Note (6/28) the WoSign new certificates are included in the Mozilla renewal request

New Certificate Authorities

Notarius Inc of Canada - http://www.notarius.com
     Trusted for Client Authentication, Secure Email, and Document Signing.

     "Notarius is a non-profit organization founded on 19 June 1996 by the Chambre des notaires du Québec (CNQ). Certified ISO 27001:2005, ISO 9001:2008 and recognized by the Conseil du trésor du Québec, Notarius issues digital signatures to Canadian professionals and their business partners."

GUANG DONG CERTIFICATE AUTHORITY CO.,LTD. OF China
    http://www.gdca.com.cn/
    WebTust Seal: https://cert.webtrust.org/SealFile?seal=1859&file=pdf

Deutscher Sparkassen Verlag GmbH of Germany (6/28: not new)

Swedish Social Insurance Agency of Sweden
  Trusted for all.

  http://www.forsakringskassan.se

  "Försäkringskassan’s role is to administer social insurance and to ensure that you get the benefits and allowances you are entitled to."

MULTICERT - Servi\xC3\xA7os de Certifica\xC3\xA7\xC3\xA3o Electr\xC3\xB3nica S.A. of Portugal
   Trusted for all.
   https://www.multicert.com

   "MULTICERT has started its business activity in 2002 with a group of 16 employees. Over the years, we have consolidated ourselves as project developers and as a digital security solutions company, bringing our expertise and technical knowledge into the electronic certification field. Our expertise has been acquired in several projects in which we participated, both in the banking and government sectors."   Submitted to Mozilla

National Digital Certification Agency of Tunisia (6/28: Not new)

   https://www.certification.tn/en

   Home page is anchored to old revoked root.

   https://www.certification.tn/fr/content/certificats-racine

New Root Certificates (17)

SHA1 Thumbprint	Current CA Owner	Country	Root CA Name	Algorithm	Expiration	Trusted For
1f3f1486b531882802e87b624d420295a0fc721a	Notarius Inc	Canada	Notarius Root Certificate Authority	RSA4096	12-2034	Client
0f36385b811a25c39b314e83cae9346670cc74b4	GUANG DONG CERTIFICATE AUTHORITY CO.,LTD.	China	GDCA TrustAUTH R5 ROOT	RSA4096	12-2040	Server Client Code Time
fbeddc9065b7272037bc550c9c56debbf27894e1	WoSign CA Limited	China	Certification Authority of WoSign G2	RSA2048	11-2044	Server Client Code Time
d27ad2beed94c0a13cc72521ea5d71be8119f32b	WoSign CA Limited	China	CA WoSign ECC Root	ECDSA384	11-2044	Server Client Code Time
22fdd0b7fda24e0dac492ca0aca67b6a1fe3f766	OpenTrust	France	Certplus Root CA G1	RSA4096	1-2038	Server Client Code
4f658e1fe906d82802e9544741c954255d69cc1a	OpenTrust	France	Certplus Root CA G2	ECDSA384	1-2038	Server Client Code
7991e834f7e2eedd08950152e9552d14e958d57e	OpenTrust	France	OpenTrust Root CA G1	RSA4096	1-2038	Server Client Code
795f8860c5ab7c3d92e6cbf48de145cd11ef600b	OpenTrust	France	OpenTrust Root CA G2	RSA4096	1-2038	Server Client Code
6e2664f356bf3455bfd1933f7c01ded813da8aa6	OpenTrust	France	OpenTrust Root CA G3	ECDSA384	1-2038	Server Client Code
1b3d1114ea7a0f9558544195bf6b2582ab40ce9a	Deutscher Sparkassen Verlag GmbH	Germany	S-TRUST Universal Root CA	RSA2048	10-2038	Server Client Time
3bc6dce00307bd676041ebd85970c62f8fda5109	India PKI	India	CCA India 2015 SPL	RSA2048	1-2025	Client Time
a2b86b5a68d92819d9ce5dd6d7969a4968e11991	India PKI	India	CCA India 2014	RSA2048	3-2024	Client Time
46af7a31b599460d469d6041145b13651df9170a	MULTICERT	Portugal	MULTICERT Root Certification Authority 01	RSA4096	4-2039	Server Client Code Time
32f442093b36d7031b75ca4daddcb327faa02b9c	Swedish Social Insurance Agency	Sweden	Swedish Government Root Authority v2	RSA4096	5-2040	Server Client Code Time
9638633c9056ae8814a065d23bdc60a0ee702fa7	Tunisian National Digital Certification Agency	Tunisia	Tunisian Root Certificate Authority - TunRootCA2	RSA4096	5-2027	Server Client Code Time
2c8affce966430ba04c04f81dd4b49c71b5b81a0	Cisco Systems	USA	Cisco RXC-R2	RSA2048	7-2034	Server Client
8094640eb5a7a1ca119c1fddd59f810263a7fbd1	GlobalSign	USA	GlobalSign Root CA - R6	RSA4096	12-2034	Code Time

Notes: (1)

"GlobalSign is a WebTrust-certified certificate authority and provider of Identity Services. Founded in 1996. and presently a subsidiary of GMO CLOUD K.K. in Japan, the company offers a diverse range of Identity service solutions."

9.1.4 Issuer Country Name Field
Certificate Field: issuer:countryName (OID 2.5.4.6)
Required/Optional: Required
Contents: This field MUST contain the two-letter ISO 3166-1 country code for the country in which the issuer’s place of business is located.

Removed/Retired Root Certificates

This is the 1024bit Equifax root.

SHA1 Fingerprint=DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41
subject= /C=US/O=Equifax Secure Inc./CN=Equifax Secure eBusiness CA-1

Saturday, June 13, 2015

Elliptic Curve Certificate Authority Ecosystem

This week (June 11-12) saw a lot of buzz around the Workshop on Elliptic Curve Cryptography Standards #ECCWorkshop held at the United States NIST. This provided a dramatic mixture of high math, high drama, public policy, and painful attempts to avoid mentioning Edward Snowden.

One very interesting presentation was given by a CA:

Symantec's view on current state of ECC
Presented by: Rick Andrews, Symantec (audio out of sync)

In his presentation, Rick mentioned the number ECC Roots that are currently supported by browsers. These are all signed using the old NIST curves P384 and P256 (GlobalSign R4). While it might seem that the (hopefully) new standard curves would make these irrelevant, in fact they are probably going to be used to sign new intermediates to bootstrap the trust, to avoid IP issues with the RSA roots (or the other way around).

All of the ECDSA certificate authorities are based in the United States (Entrust appears to have a Canadian parent). Symantec owns Verisign and Thawte, so there are really only 5 Certificate Authorities that offer ECDSA certificates. All of the CAs belong to the CA Security Council , which is appears to be a marketing council not very unlike the National Dairy Council.

The presentation is comprehensive (go watch it, I'll wait), but while he summarizes the certificates and roots he didn't provide a table listing them, so here is one, along with Test URLs where I could find them.

Status	Root CA Name	SHA1 Thumbprint
AMND	Entrust RootCertification Authority- EC1	20D80640DF9B25F512253A11EAF7598AEB14B547
MND	COMODO ****	9F744E9F2B4DBAEC0F312C50B6563B8E2D93C311
MN	USERTrust ****	D1CBCA5DB2D52A7F693B674DE5F05A1D0C957DF0
AMND	DigiCert Assured ID Root G3	F517A24F9A48C6C9F8A200269FDC0F482CAB3089
AMND	DigiCert Global RootG3	7E04DE896A3E666D00E687D33FFAD93BE83D349E
AMN	GlobalSign ECC RootCA - R4 *5	6969562E4080F424A1E7199F14BAF3EE58AB6ABB
AMN	GlobalSign ECC RootCA - R5 *5	1F24C630CDA418EF2069FFAD4FDD5F463A1B69AA
AMND	GeoTrust Primary Certification Authority- G2	8D1784D537F3037DEC70FE578B519A99E610D7B0
AM	Symantec Class 1 Public Primary Certification Authority - G4 ***	84F2E3DD83133EA91D19527F02D729BFC15FE667
AM	Symantec Class 2 Public Primary Certification Authority - G4 ***	6724902E4801B02296401046B4B1672CA975FD2B
AM	Symantec Class 3 Public Primary Certification Authority - G4	58D52DB93301A4FD291A8C9645A08FEE7F529282
AMND	thawte Primary RootCA - G2	AADBBC22238FC401A127BB38DDF41DDB089EF012
AMND	VeriSign Class 3 Public Primary Certification Authority - G4 *	22D5D8DF8F0231D18DF79DB7CF8A2D64C93F6C3A
AMND	Trend Micro **	B8236B002F1D16865301556C11A437CAEBFFC3BB

A= Apple
M = Microsoft
N = Mozilla NSS
D = anDroid

Also, just since it's always handy: Symantec SHA256 Test Page

Symantec has 5 trusted roots, I don't see the G4 roots on their roots page, and can't find test urls for them. They don't appear to have submitted them to Mozilla or Android which would make the test urls public. The Verisign root is documented as not being in use.

* "VeriSign Class 3 Public Primary CA - G4 Description: While this root is not being used today for Symantec's commercial certificate offerings, it is an ECC (Eliptic Curve Cryptography) root that will be used in the future to as the root of Trust for Class1, 2 and 3 certificates ECC certificates and should be included in root stores. ?"

** AffirmTrust ECC root test page uses the wrong hostname (commercial.affirmtrust.com) rather than "premiumecc.affirmtrust.com"

*** The Symantec Class 1&2 G4 certificates don't have test URLs listed in the bugzilla submissions, suggesting they are "non-SSL" roots. This can be confirmed with certutil on Windows.

certutil -verify 6724902e4801b02296401046b4b1672ca975fd2b.crt
..
------------------------------------
Verified Issuance Policies: All
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.4 Secure Email
Cert is a CA certificate
Cannot check leaf certificate revocation status

CertUtil: -verify command completed successfully.

**** The Comodo & UserTrust ECC roots are not directly trusted by Android or Apple. However, Comodo has cross signed intermediates to other roots that are trusted, so these links work, but the trust is asserted using sha384withRSA.

https://www.ssllabs.com/ssltest/analyze.html?d=comodoecccertificationauthority-ev.comodoca.com
https://www.ssllabs.com/ssltest/analyze.html?d=usertrustecccertificationauthority-ev.comodoca.com

*5 GlobalSign says "ECC Certificates (Not yet in use.)".
https://support.globalsign.com/customer/portal/articles/1426602-globalsign-root-certificates

Friday, June 5, 2015

June 9 Update:

In what is probably just a case of great minds thinking alike, the US House of Representatives Energy & Commerce committee sent letters to the browser vendors asking about restricting government CAs.

http://energycommerce.house.gov/letter/letters-browsers-regarding-government-certificate-authorities

On June 5, 2015, Microsoft updated the

"Microsoft Trusted Root Certificate: Program Requirements"

I think so this is when it was changed. There is no date or version on the page, unlike the former version you can't tell when it changed or view revision history.

https://technet.microsoft.com/en-us/library/cc751157.aspx

The previous version was at the link below, which shows the history which was updated to redirect to the page above.

http://social.technet.microsoft.com/wiki/contents/articles/3281.introduction-to-the-microsoft-root-certificate-program.aspx

The second to last word on the current page is a typo "thhhe", when that is fixed we'll know something changed, but what... (I archived it).

WHAT CHANGED?

A lot has changed, some notable and welcome changes:

"7. All roots that are being used to issue new certificates, and which directly or transitively chain to a certificate included in the Program, must either be limited or be publicly disclosed and audited."

This seems to mean Intermediate Certificate Authority Certs require WebTrust / ETSI audits, or constraints. This is great news, many of the breaches in the past have been from sub-CAs, including the recent CNNIC incident.

"8. Government CAs must restrict server authentication to .gov domains and may only issues other certificates to the ISO3166 country codes that the country has sovereign control over (see http://aka.ms/auditreqs section III for the definition of a “Government CA”).

9. Government CAs that also operate as commercial, non-profit, or other publicly-issuing entities must use a different root for all such certificate issuances (see http://aka.ms/auditreqs section III for the definition of a “Commercial CA”)."

These are changes that people have been clamoring for, for example concern about US and other government Certificate Authorities being able to issue general server authentication certificates.

WHAT'S MISSING?

Transparency. Mozilla provides a good example, everything is transparent. Microsoft might want to allow applications to remain non-public during the initial process. However, this is PUBLIC Key Infrastructure, customers have given MS their trust. Once a CA is accepted and scheduled for distribution, customers should have the opportunity to review the criteria and decide whether to accept or block the trust. NIST.SP.800-52r1 section 4.5.2 requires administrators to manage the certificate trust list.

Minimum transparency would include a public notice after Step 2 of the intake process, along with public comment period. Public comments are normal for IETF, NIST, and other standards discussions, and could occur here. There is a possibility that the public may have strong, even misguided opinions but a robust public process can survive public discourse.

When the new update to the Root Certificate Trust list is released, it should include advance customer notification such as through the Security Bulletin process.