470994 - (distrust) Complete the implementation of active DIStrust in NSS

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P5)

Description

[Nelson Bolyard (seldom reads bugmail)]

Bug 4708957 demonstrates the need for a real DIStrust flag, a flag that
causes a cert to be DIStrusted, even if it was issued by a trusted issuer.

NSS already has definitions of representations of active distrust.
In some part of NSS, which predate project Stan, trust is represented 
by a set of trust flags.  In other parts, trust is represented as a single
integer trust state variable with 6 enumerated values.  They are seen at:
http://mxr.mozilla.org/security/ident?i=CERTDB_NOT_TRUSTED
http://mxr.mozilla.org/security/ident?i=CKT_NSS_UNTRUSTED 
http://mxr.mozilla.org/security/ident?i=CKT_NETSCAPE_UNTRUSTED 
http://mxr.mozilla.org/security/ident?i=nssTrustLevel_NotTrusted

CERTDB_NOT_TRUSTED names one of the 16 NSS 3.x style trust flags. 
It maps directly to the nssTrustLevel_NotTrusted state, which is one
of the 6 trust states defined in project Stan. It is also known 
(in the PKCS#11 API) as CKT_NSS_UNTRUSTED and CKT_NETSCAPE_UNTRUSTED,
which are synonyms.

As can be seen at the above URLs, there is virtually no implementation 
of these states/flags.  There is code inside softoken that maps back and 
forth between trust flags and trust state, but that's about it.  There's 
no code that ever tests or uses these untrusted states/flags in NSS's cert 
validation logic, no code in any utilities to display, set or clear the 
untrusted state/flag, and no test scripts that attempt to test the 
untrusted state/flag's functionality on cert path validation.  

The CERTDB_NOT_TRUSTED trust flag is unknown outside of softoken's 
"legacy DB" code. It is defined in softoken's private header file
lib/softoken/legacydb/pcertt.h but not in NSS's public header file
lib/certdb/certdb.h.  It appears that it was intended solely as a way
of representing Stan's nssTrustLevel_NotTrusted state in the old cert8.db
file, which stores trust as flags, not as states.  

I've taken some initial steps to try to implement this outside of softoken.
See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.95&mark=2134-2138,2143-2146,2151-2155#2121
But there is much more to be done, since CERTDB_NOT_TRUSTED is not even 
defined as a symbol outside of softoken.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

> Bug 4708957 demonstrates the need for a real DIStrust flag,
That was a typo.  It should read: bug 470897

Comment 2

[Robert Relyea]

> But there is much more to be done, since CERTDB_NOT_TRUSTED is not even 
> defined as a symbol outside of softoken.

There's not problem adding a define to cert.h to indicate untrusted. These are two different data structures now, and only have similar names do to historic reasons.

Besided your given patch, we would also need to fix
 nss/security/pki/pki3hack.c to include CERTDB_NOT_TRUSTED in our mapping.

We should also test it in either our verify code or our 'isCA' code so that intermediates don't chain forward.

bob

Comment 4

[Kaspar]

(In reply to comment #3)
> *** Bug 585352 has been marked as a duplicate of this bug. ***

If 585352 is a duplicate of this one, is there a specific reason why it needs to be kept private?

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #4)
> If 585352 is a duplicate of this one, is there a specific reason why it needs
> to be kept private?

I changed bug 585352 to be about the UI.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

During the NSS conference cal l today, there was some agreement that we probably want to do distrust based on the DN of the issuer, instead of a particular certificate. Otherwise, when a particular cert is blocked, another root (from the same CA or a different one) could issue an intermediate CA cert with the same DN and keypair, and all the EE certs we would be trying to block would validate. We should also verify that key ids and public keys are used for certificate matching after a DN match has been done.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Also, libpkix keeps trying different chains until one succeeds, and then stops looking for chains. Changing libpkix to try every possible chain to make sure none involve a distrusted cert won't work from a performance standpoint and also isn't what we want (because there might be a valid path that doesn't involve any distrusted certs).

Comment 8

[Robert Relyea]

I should be clear. I think both methods may be necessary.

bob

Comment 9

[Peter Eckersley]

As I implied in #585352 (but I'll repeat it more clearly here), there can and do exist multiple CA certificates, with different Subjects/Distinguished Names, that share the same public keys.  When you distrust one of those, you should be distrusting all of them.

Jesse Burns was interested in the extent of key reuse and wrote a small script, KeyReuse.py that's available in the SSL Observatory source code.

I've pasted its output on the December 2010 scan data here:

https://www.eff.org/observatory/key_reuse_dec_2010

Comment 10

[Robert Relyea]

> As I implied in #585352 (but I'll repeat it more clearly here), there can and
> do exist multiple CA certificates, with different Subjects/Distinguished Names,
> that share the same public keys.

I'm thinking the same thing, but for a different issue. There is a desire to bound the validity time of one of our trust records. The issue of this is removing trust doesn't prevent pkix from falling back through chaining around the root CA. A KRL (key revocation List) is definitely a good way to do this. I just need to work out which of the many ways of identifying a particular key is the best method for doing this.

bob

Comment 11

[Peter Eckersley]

There is also a theoretical question about whether the UI should do anything about situations where multiple CA certs are controlled by the same organisation.  For instance, if a user for some reason wanted to not trust Verisign, perhaps they would want to know that Thawte's CA certs were controlled by Verisign.  It seems to me that this would require some proactive data collection from the CAs by Mozilla, however.

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #10)
> I'm thinking the same thing, but for a different issue. There is a desire to
> bound the validity time of one of our trust records. The issue of this is
> removing trust doesn't prevent pkix from falling back through chaining around
> the root CA. A KRL (key revocation List) is definitely a good way to do this. 
> I just need to work out which of the many ways of identifying a 
> particular key is the best method for doing this.

I'm prepared to be shown otherwise, but I would expect that "always distrust" and "distrust since date X" should work the same way; "always distrust" seems like the same thing as "distrust since 1/1/0001-00:00:00.000".

Another issue is whether we want to distrust for specific usages. Some CAs use the same key to sign certificates and to sign OCSP responses and/or CRLs. We would need to be able to accept signed OCSP responses signed today for a cert issued yesterday, even though we might not want to accept a cert issued today signed with the same key.

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

When a certificate is actively trusted, any active distrust of certs above it (issuing certs) must be ignored? I.e. actively trusting a cert for a specific usage must make it act like a trust anchor for that usage. Right?

Comment 14

[Peter Eckersley]

Yes, that seems correct to me.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

If a CA's private key is compromised on date X, then "distrust since date X" is trivially defeated.  The attacker simply gives all his new certs a not-before
date that is before date X.

Comment 16

[Robert Relyea]

Nelson, you are quite correct.

The issue isn't to deal with a private key compromise of a CA... it's to deal with a compromise of a CA's authentication process.

If the private key of a CA is compromised, then complete revocation of the key is clearly called for. We can use this same mechanism to say that this key has no validity time (or infinite revocation time).

Comment 17

[Robert Relyea]

> I'm prepared to be shown otherwise, but I would expect that "always distrust"
> and "distrust since date X" should work the same way;

So the issue is how much churn you want to make in the existing code. We already have a mechanism for trusting/distrusting certificates. That mechanism requires only minor tweaks to distrust the certificate, which I've done in bug 6420503.

 That mechanism has no provision for either distrusting the key (only the cert) nor distrusting a certificate after date X. It's relatively easy to add a new mechanism that handles date based key revocation. Back adding date base cert distrust could be done, but it would be more complex and slow down getting something implemented. It would be worth doing if there is a specific benefit, but I don't really see one yet.

> When a certificate is actively trusted, any active distrust of certs above it
> (issuing certs) must be ignored? I.e. actively trusting a cert for a specific
> usage must make it act like a trust anchor for that usage. Right?

That is how the patch in bug 6420503 works for those operations that don't have specific trust bits (like OCSP). You can explicitly distrust a cert for only Object Signing (for instance), but trust it for SSL or Email.

bob

Comment 18

[Gervase Markham [:gerv]]

Bob: you appear to have typoed "bug 6420503". Can you tell us which bug you were referring to?

Gerv

Comment 19

[Kaspar]

Should read bug 642503, I think (on which this one depends).

Comment 20

[Kyle Hamilton]

blocks? 699923

Comment 21

[Wan-Teh Chang]

Bob: I believe this bug is fixed now (the work was done in bug 642503
and bug 727204).  Is there anything else we need to do for active
distrust in NSS?

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

Is there a "how to" for active distrust?  
A web page telling how to add actively distrusted certs, and any gotchas to avoid?

Comment 23

[Wan-Teh Chang]

Kai enhanced the addbuiltin tool so it can generate a trust
record for nssckbi to distrust a certificate.

But I am not sure if there is an NSS function for adding a
trust record to the NSS cert db to distrust a certificate,
without also adding the certificate.

Comment 24

[My1]

This really needs to be addressed, considering that bluecoat got an intermediate fpr "testing" (from symantec, no joke)

Comment 25

[Benjamin Beurdouche [:beurdouche]]

Bob, could you please check my triaging for this bug and update if needed ? : ) Thank you !

Comment 26

[Robert Relyea]

There are a lot of ideas in this bug, but the original request has been completed quite some time ago. Some of the ideas in here have also been somewhat implemented. A generic ability to add cert extensions which restrict trust (domain restrictions, etc.) have not been implemented, but that should be a different bug. The only thing that's really missing it the active test to make sure certain well known distrusted certs are still marked distrusted explicitly. That's a separate bug, so I think this one can be closed.