Comment 10 for bug 1214016

Adding the commit message from the proposed patch which provides further information:

Keys are generated with the genrsa command. The key is only password
protected if the -des -des3 or -idea argument is provided (encrypted
with DES, triple-DES, or IDEA respectively). The password must be
supplied via the --passout argument otherwise it will be interactively
prompted for.

ISSUE: genrsa is never called with -des, -des3 or -idea therefore it's
never password protected. Nor is the -passout argument
provided. Therefore the ca_password option is pointless. If the
ca_password were actually used then genrsa should have been called
with "-des3 -passout pass:%(ca_password)s".

The key is then provided to the openssl req command. In order for the
req command to be able to read the key the password must be provided
via the -passin argument or it will be interactively prompted for.

ISSUE: -passin is never passed to the req command therefore it cannot
read a passord protected key non-interactively.

The openssl req command will attempt to password protect any key it
output's unless it's passed the -nodes argument. It only generates a
key if a key is not supplied via the -key argument.

ISSUE: The req command used when generating the signing cert is passed
-nodes but since req is not generating a key it has nothing to
encrypt hence it's pointless.

The openssl ca command needs the ca key in order to sign requests. The
ca may be encrypted with a password, if so it will need the ca
password to decrypt the key. The key password is passed via the
-passin argument, if the -passin argument is not provided it will
prompt for it interactively.

ISSUE: The openssl ca command is not passed the key password, if it
did it would need to so like this: "-passin pass:%(ca_password)s".
Since the ca_password is not passed to the ca command it's not
doing anything.

Passwords used by openssl are either prompted for interactively or
obtained non-interactively via a comman line argument, an environment
variable, a file, read from a file descriptor (e.g. pipe) or read from
stdin.

ISSUE: Since OpenStack components are meant to run non-interactively
(at least not requiring admins to type in passwords at random prompts)
we must store the password in the file system, typically inside a
config file. The only thing that protects that password are
DAC (Discretionary Access Control) commonly known as file
system protections and/or MAC (Mandatory Access Control) typically
implemented via SELinux. Since the protection on the key file is not
fundamentally different than the protection on the file containing the
password it's dubious as to what extra protection is being provided by
password protecting the key. In a properly configured system the same
protections should be applied to both the key file and the password
file. If an attacker has access to the one of the files he almost
certainly has access to the other file. This begs the question as to
what actual protection is being afforded via key passwords. In fact an
argument can be made that having to carefully protect configuration
files containing passwords is an additional security item which has to
be verified, something which adds complexity with marginal
benefit. More to the point many admins are not likely to understand
the critical importance of protecting a config file, while on the
other hand the necessity to protect a key file is obvious. Another
justification for removing the ca pasword is the keystone
configuration documentation (doc/source/configuration.rst) states keys
provided by an external source must not be password protected. So if
externally provided keys are not password protected they why would
keys generated by keystone-manage be password protected? It's
inconsistent.

Summary:

Given numerous mistakes in using key passwords in the current
implementation and the marginal value key password protection afford
it is recommended to eliminate password protection with the added
benefit of reducing the complexity of the system. Less complexity
usually results in greater security because there are fewer moving
parts to track and validate. As Bruce Schneier says "Complexity is the
worst enemy of security". The numerous mistakes in utilizing the
openssl password options is a testament to the complexity argument
especially considering the existing code passed a peer review
process.