Open Bug 470994 (distrust) Opened 16 years ago Updated 2 years ago

Complete the implementation of active DIStrust in NSS

Categories

(NSS :: Libraries, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: nelson, Assigned: rrelyea)

References

(Depends on 1 open bug)

Details

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.
Alias: distrust
Summary: Complete the implementation of an active DIStrust flag in NSS → Complete the implementation of active DIStrust in NSS
Blocks: 471715
> Bug 4708957 demonstrates the need for a real DIStrust flag, That was a typo. It should read: bug 470897
> 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
(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?
(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.
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.
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).
I should be clear. I think both methods may be necessary. bob
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
Depends on: 642503
> 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
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.
(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.
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?
Yes, that seems correct to me.
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.
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).
> 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
Bob: you appear to have typoed "bug 6420503". Can you tell us which bug you were referring to? Gerv
Should read bug 642503, I think (on which this one depends).
Depends on: 727204
Depends on: 727316
blocks? 699923
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?
Assignee: nobody → rrelyea
Is there a "how to" for active distrust? A web page telling how to add actively distrusted certs, and any gotchas to avoid?
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.
This really needs to be addressed, considering that bluecoat got an intermediate fpr "testing" (from symantec, no joke)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.