<div dir="ltr">At the risk of being a "me-too", I think there is a real concrete use case for better integrating the p11-kit/nssckbi diversion.<div><br></div><div>Currently, NSS ( <a href="http://packages.debian.org/wheezy/libnss3">http://packages.debian.org/wheezy/libnss3</a> ) carries a patch to add certificates for SPI and CACert ( <a href="http://patch-tracker.debian.org/package/nss/2:3.14.5-1">http://patch-tracker.debian.org/package/nss/2:3.14.5-1</a> ). These add two certificate authorities that are not audited nor do they participate in any root store program. While I can understand and respect the ideological reasons for their inclusions, administrators of Debian and Debian-derived systems may have a desire to remove or restrict such certificates, as they open up all NSS-using applications to the risk of MITM or compromise that would not (generally) be detected by root store operators.</div>
<div><br></div><div>Using the p11-kit-trust module as a diversion for nssckbi would allow the patches to nssckbi.so removed, and moved into p11-kit. p11-kit-trust would then allow administrators to disable or remove such trust, without having to recompile or repackage either NSS or p11-kit - simply by modifying the trust entries on disk.</div>
<div><br></div><div>Fedora and Red Hat have already integrated NSS and p11-kit in this way - see <a href="http://pkgs.fedoraproject.org/cgit/p11-kit.git/tree/p11-kit.spec">http://pkgs.fedoraproject.org/cgit/p11-kit.git/tree/p11-kit.spec</a> , which on post-inst sets p11-kit to be a diversion for the nssckbi trust module via update-alternatives.</div>
<div><br></div><div>On a concrete level, what are the steps we can take to move forward to such a system? Is this something the maintainers could add, is this something patches would be welcome for, or are there fundamental oppositions to allowing administrators full control over their root stores, without requiring a repackaging of NSS to mask out the patches?</div>
</div>