Re: Explicitly distrusted certificates in certdata.txt (NSS built-in root CA certificate list)
Robert Relyea
> After you match a trust object to a certificate, check the
> CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION, and
> CKA_TRUST_CODE_SIGNING attributes in the trust object.
>
> In the current version of certdata.txt, these attributes may have only
> three possible values:
> - CKT_NSS_TRUSTED_DELEGATOR: this means the CA is trusted for that purpose.
> - CKT_NSS_TRUST_UNKNOWN: this means the CA is not trusted for that
> purpose, but is trusted for some other purpose.
> - CKT_NSS_NOT_TRUSTED: this means the certificate (which may not be a
> CA) is explicitly distrusted.
>
> Note: I recommend that the scripts assert that these attributes only
> have these three values, so that it can detect when this assumption is
> no longer true.
>
> The scripts must exclude the certificates whose trust objects contain
> CKT_NSS_NOT_TRUSTED in any of the CKA_TRUST_SERVER_AUTH,
> CKA_TRUST_EMAIL_PROTECTION, and CKA_TRUST_CODE_SIGNING attributes.
I agree this should be the minimum processing these scripts do. Ideally
these scripts should also look at the trust fields they are interested
in, for instance CKA_TRUST_SERVER_AUTH. Not all uses have this level of
granularity, so it's not a requirement.
Scripts should also have a way to output the NSS trust values, or an
appropriate mapping thereof for So users of the output of these scripts
can see them...
At some point the users of these cert trust values will need to find
some way to encode explicitly revoked certs as well. That is starting to
get far afield from the original issue, so I think it's more of a 'throw
away' communication to them. Not really a solution to the bug.
bob
> Wan-Teh Chang
Nelson B Bolyard
> [...]
> The certdata.txt file in the NSS source tree
> (http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt)
> is the master source of the NSS built-in trusted root CA list, so
> people have written scripts to extract the trusted root CA
> certificates from this file. [...]
> After the two CA break-in incidents this year, certdata.txt started to
> contain several explicitly distrusted certificates. Scripts that
> extract trusted root CA certificates from certdata.txt must now check
> the trust objects.
>
> Here are the instructions.
I'd say it's going to be difficult for the typical scripting language to do
the recommended instructions. How about putting the distrusted certs and
their trust objects in a separate file in the CVS repository?
Gervase Markham
> I'd say it's going to be difficult for the typical scripting language to do
> the recommended instructions. How about putting the distrusted certs and
> their trust objects in a separate file in the CVS repository?
What particularly do you think is difficult about it?
Gerv
Ludwig Nussel
> Florian Weimer reported this issue to us.
>
> The certdata.txt file in the NSS source tree
> (http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt)
> is the master source of the NSS built-in trusted root CA list, so
> people have written scripts to extract the trusted root CA
> following examples:
> https://atlaswww.hep.anl.gov/twiki/bin/view/UsAtlasTier3/FetchingCA-bundle
> http://cblfs.cross-lfs.org/index.php/OpenSSL
> http://curl.haxx.se/docs/parse-certs.txt
>
> Originally certdata.txt contained only trusted root CA certificates,
> so some of those scripts may have relied on that fact and ignore the
> trust objects for certificates in that file.
>
> After the two CA break-in incidents this year, certdata.txt started to
> contain several explicitly distrusted certificates. Scripts that
> extract trusted root CA certificates from certdata.txt must now check
> the trust objects.
The MD5 collision cert was there even before those events.
Here's the script I use for openSUSE. It optionally exports the trust
settings too:
http://gitorious.org/opensuse/ca-certificates/blobs/master/extractcerts.pl
For processing outside NSS it would be easier if the certificates
were available as individual pem files in the first place of course :-)
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend�rffer, HRB 16746 (AG N�rnberg)