Nelson Bolyard wrote:
There is a certain tool that makes PEM files that contain unencrypted
private keys. The tool can be made to encrypt them, but does not
require that, and many users simply choose to skip it. Since we're trying
to promote real security, and not the willy-nilly use of keys, we want
to discourage the use of files of plaintext private keys as a key
transport mechanism. That, in a nutshell, is why mozilla only imports
private keys
in PKCS12 format, which format does not define or allow the transport of
unencrypted private keys.
If this tool is a popular tool, then the decision to not
accept its output format may well do more security damage
than good.
If users find that dealing with mozilla products is difficult,
they are far more likely to either not deal with the product,
or not set it up to use keys at all. Hence, they have lost
any security benefit, and only the very few who go through
the trouble and jump through all the security hoops to use
the more difficult tools will enjoy any protection.
In general, if Mozilla wants to provide people protection, it
should bend over backwards to help. Even to the extent of
opening up weaknesses and apparent security holes - if it
helps more people to use it. It's much more useful to say
that we have millions that are being protected, but there
are weaknesses, than we have thousands that are being protected,
and there are no weaknesses (that we admit to).
The notion that an unencrypted key is insecure is rather an
unsupportable statement. If the PEM-producing tool is on
the same machine, and the machine hasn't been compromised,
then it matters not if it is encrypted. Such an unencrypted
key is secure - leaving us with the bad situation that valid,
secure activity is not permitted. "Sometimes might be insecure"
is generally weak security design, as the open source developer
rarely has a way of measuring that "sometimes." (The same goes
for most corporate networks which are locally secure - but mail
needs to be secured for outgoing.)
Only if the platforms have been compromised *and* the compromise
inserts some trojan that scans for unencrypted keys would there
be any issue here. Although this is highly unlikely, it is a
plausible issue: it should be dealt with in the first instance
by warnings and/or advices, not by not permitting this activity.
For the most part, users are far more adept at making these
sorts of security decisions than developers give them credit
for. They are also far more adept at ignoring crypto that
is too hard to use that we want...
And, when they do get it wrong, then they start to learn. But,
at least they had the chance to be wrong, and be protected for
those parts of the activity where an unencrypted key can still
protect.
iang
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
