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...) > 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? > > We should probably have that discussion before we decide to do 'forced > turn-offs' on certificates. > > bob -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
