At the moment we have an ad hoc approach to where we store ssl
certificates and other keys. The openssl package installs
into /usr/share/ssl and some packages store their keys
in /usr/share/ssl/certs/{public,private} because of the lack of anything
better and its the closest thing we have to a standard location. Other
packages (e.g. httpd) store their keys in their own directories.
So the world is even *MORE* complicated that this.Only about half our packages use openssl to get their SSL implementations. The other half uses NSS. NSS store keys in in a keyX.db file and certs in certX.db. To make matters worst, like openSSL apps, NSS apps typically store their own copy of the database somewhere in the user's profile.
I agree we need to solve this problem, but I think we need to take a step back and understand how each application uses it's keys and certs. Just saying the keys and certs live in a particular directory
is not sufficient.I wish I had seen this discussion earlier. It appears to have completely punted on applications that use NSS.
This certainly is not going to work with existing NSS apps like evolution or Firefox.There are three major reasons to create a new uniform location, and this is a proposal to do so: 1) /usr/share is designed to be NFS mounted and shared. Private certificates and keys really should not be located by default in a directory visible to many machines on the network. /usr/share is an insecure location. 2) SELinux labeling and policy authorship would be much easier and more robust if we collected certificates and keys in one place and label those files appropriately. 3) Certificates and keys are not a property of the openssl package, there should be a package neutral location in the spirit of FHS to locate all certificate and key files which can be shared by all packages. Someplace in /etc seems ideal.Proposal: the filesystem rpm creates the following 3 new directories/etc/keys /etc/keys/public /etc/keys/private
They expect their key and cert databases to live in the same directory.
Again, I wish I were in on this discussion. It seems to have missed a major component which affectsIndividual applications can make use of these directories in whatever fashion they desire, as long as the files they install there are certificates or keys of any form. They set their own permissions and ownerships.I know this has been debated before, be we've got to make a decision and move forward (in part because this is now gating some work on my plate :-) . I've had a hallway conversation with Nalin and Dan Walsh and it was agreed this was the most palatable option at the moment (not ideal, but a workable solution).
the overall design. bob
ACK's or NCK's please!-- John Dennis <jdennis@xxxxxxxxxx> -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
