Comment 2 for bug 1214016

Whatever the resolution is with respect to whether we use passwords on keys or not I can make the fix pretty quickly. You can assign the bug to me and once a consensus is reached I can provide a patch very quickly.

This issue was discovered while we were working on a proof-of-concept using NSS as the crypto provider instead of OpenSSL (blueprint for this will be published shortly). I means I've been all over how certs are created and managed. FWIW NSS also has an (optional) key password. However in the case of NSS there is one password that protects all keys as opposed to OpenSSL for which you can apply a unique password to all key files (or of course you could use the same password on all key files).

If we do remove key passwords from config files I believe key protection is going to come back again as feature in some form, likely in conjunction with hardware based key storage. Exactly how this will be implemented to be generic across a range of devices and interacting with specific trusted processes is an open topic. Even when these devices utilize a password it's clear that password should never be stored in a configuration file. But for the time being, until we start using (hardware or kernel) locked key storage I see little point in storing key passwords in config files, except for ...

If an organization already has an existing key file they want to use and they've encrypted it, then they probably will want to use the encrypted key file, which means they have to put the password somewhere and right now the only place is the config file :-(.

So ...

maybe we can't just get rid of the key password from the config files, but if we keep the password option in the config file then we had better attempt to use it when creating keys instead of ignoring it, which would argue for not removing the key password option but rather keeping it and providing the implementation to use it.