On 09/25/2009 11:58 PM, Kyle Hamilton wrote: > 2009/9/25 Robert Relyea <rrel...@redhat.com>: > >> Because of the way the system works, deleting a cert from builtins would be >> equivalent to marking it untrusted. The user could still override our choice >> in softoken. Unfortunately the trustorder is set on the module, not the slot >> (/me mentally slapping myself for that), otherwise we could add a second >> slot in the builtins which had certs which had a lower trust order than >> softoken. We could then put disabled certs in that second token. It's >> probably not to difficult to give each slot it's own trust order that >> overrides the overall module trust order, but it would have to be added to >> NSS. >> > Huh. So you could theoretically add another module, like libnssckbi, > that has a lower trust order than softoken, and thus can override even > softoken's user-set bits. (It shouldn't be difficult to create > another PKCS#11 device that has its own slot...) >
Yes, but you couldn't get it loaded automatically, and you'd have to do something external to the token to get it to have precedence over softoken. By default it wouldn't. >> This means the feature is probably implementable without a lot of work, but >> then the question becomes, do we really want to do this? Once implemented, >> it would be very difficult to turn off (Hmm, well perhaps PSM could control >> whether or not the 'disabled certs' override the other trust flags as well >> or not. >> > If you want to get rid of the 'disabled certs' override, use secdb to > remove the disabled certs device from consideration? > This is precisely why I question whether we want to do this. It only makes sense if FF provides an option to turn off the 'disabled certs' (load the disabled cert handler at a lower precedence than softoken). Even then, I'm not sure it makes sense. I've just pointed out we could build something that would allow us to override a user's choice to trust a certificate. Before we do so, I really think we need the discussion of do we really want to. bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
