certdata2pem.py doesn't handle CKT_NSS_MUST_VERIFY_TRUST

Bug #1207004 reported by Christian Heimes
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ca-certificates (Debian)
Fix Released
Unknown
ca-certificates (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hello,

I'm a Python core developer and hobbyist security researcher. While I
was working on my own parser for Mozillas certdata.txt [1] I found
an issue in curls mk-ca-bundle.pl script. Today I found the same issue in
Debian's and Ubuntu's script.

The Python script ./mozilla/certdata2pem.py of ca-certificates-20120623
 doesn't handle the flag CKT_NSS_MUST_VERIFY_TRUST.
The flag was introduced in revision 1.84 of certdata.txt, see [2]

The PKCS#11 glue documentation [3] of the freedesktop.org project has
some background information on the flag, too. Quote:
---
The certificate is not a trusted anchor (even if a later trust record
in another PKCS #11 module says this cert should be trusted). If the
marked certificate is self-signed, then this is semantically
equivalent to CKT_NSS_NOT_TRUSTED, except NSS will return a different
error code (unknown CA for CKT_NSS_MUST_VERIFY_TRUST versus untrusted
CA for CKT_NSS_NOT_TRUSTED).
---

May I suggest that you reverse the check and distrust any certificate
unless it was explicitly flagged as a trusted delegator and root CA
cert? In the context of cryptography and TLS it more secure to omit a
root CA cert than to wrongly ship a bogus cert. By the way Adam
Langley [4] uses the same approach [5].

My Ubuntu box has files like Verisign_Class_1_Public_Primary_Certification_Authority.pem
in the /etc/ssl/certs/ directory. According to my script "Verisign Class 1 Public Primary Certification Authority"
is flagged as CKT_NSS_MUST_VERIFY_TRUST for CKA_TRUST_SERVER_AUTH [6].

$ LC_ALL=C apt-cache policy ca-certificates
ca-certificates:
  Installed: 20120623
  Candidate: 20120623
  Version table:
 *** 20120623 0
        500 http://de.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

$ LC_ALL=C lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

Regards,
Christian

[1] https://bitbucket.org/tiran/storeroom/
[2] http://lists.debian.org/debian-release/2012/11/msg00411.html
[3]
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html
[4] https://www.imperialviolet.org/2012/01/30/mozillaroots.html
[5]
https://github.com/agl/extract-nss-root-certs/blob/master/convert_mozilla_certdata.go#L251
[6] https://bitbucket.org/tiran/storeroom/src/e24eef16ff64041ab7792a907f0d69f7b19cd624/certdata/certs.py?at=default#cl-4411

Revision history for this message
Christian Heimes (heimes) wrote :

curl has updated their script today. I notified the developers a couple of weeks ago.

https://github.com/bagder/curl/commit/51f0b798f
http://curl.haxx.se/docs/caextract.html

SuSE's certdata.txt parsing script handles the flag correctly

https://github.com/openSUSE/ca-certificates/blob/master/extractcerts.pl

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Thanks for the bug report, I'll investigate this issue.

Changed in ca-certificates (Ubuntu):
assignee: nobody → Marc Deslauriers (mdeslaur)
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

So, I've looking into this. The relevant code in certdata2pem.py is:

    elif obj['CKA_TRUST_SERVER_AUTH'] in ('CKT_NETSCAPE_TRUSTED_DELEGATOR',
                                          'CKT_NSS_TRUSTED_DELEGATOR'):
        trust[obj['CKA_LABEL']] = True
    elif obj['CKA_TRUST_EMAIL_PROTECTION'] in ('CKT_NETSCAPE_TRUSTED_DELEGATOR',
                                               'CKT_NSS_TRUSTED_DELEGATOR'):
        trust[obj['CKA_LABEL']] = True

In Debian and Ubuntu, ca-certificates is not only used for web certificates, but also for email certificates.

Even if Verisign_Class_1_Public_Primary_Certification_Authority.pem is marked as CKT_NSS_MUST_VERIFY_TRUST for CKA_TRUST_SERVER_AUTH, it is marked as CKT_NSS_TRUSTED_DELEGATOR for CKA_TRUST_EMAIL_PROTECTION, which is why it is included.

I believe omitting certs that are valid for CKA_TRUST_EMAIL_PROTECTION will break email S/MIME verification.

information type: Private Security → Public Security
Revision history for this message
Christian Heimes (heimes) wrote :

I had long discussion with Marc-Andre Lemburg about the issue. He maintains the eGenix pyOpenSSL distribution which also contains root CA certs. He did some tests with TRUST settings but apparently OpenSSL ignores them. Eventually we came up with the idea to split the CA bundle into multiple files: a separate file for each purpose. See http://www.egenix.com/products/python/pyOpenSSL/

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I've filed an upstream bug with Debian.

Changed in ca-certificates (Ubuntu):
status: New → Confirmed
Changed in ca-certificates (Debian):
status: Unknown → New
Changed in ca-certificates (Ubuntu):
assignee: Marc Deslauriers (mdeslaur) → nobody
Revision history for this message
Christian Heimes (heimes) wrote :

Please request a CVE number for this issue.

Changed in ca-certificates (Debian):
status: New → Fix Committed
Changed in ca-certificates (Debian):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.