On 27/10/2015 03:42, Viktor Dukhovni wrote:
On Tue, Oct 27, 2015 at 02:21:13AM +0100, Jakob Bohm wrote:
More specifically, the issue is that the currently
recommended command "openssl pkey", allegedly silently
omits the encryption when told not to Base64 encode the
encrypted key.
I agree this is a bug, and needs to be fixed. A fatal error seems
best for now.
Encrypting the DER object is more difficult, since the result needs
to be able carry algorithm and IV metadata, which in the PEM version
is *not* part of the base64 encoding.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,BCD9FB9A94F887A6CD391BBB244D01FC
... base64 bits...
-----END RSA PRIVATE KEY-----
I forgot about the IV (the others could be automagically guessed
by code trying each in turn or based on options).
For this to be generically possible with DER payloads, we'd need
a new ASN.1 type for this type of encapsulation, which starts to
look rather like a generalization of PKCS#8. Below is asn1parse
output for a v2 pkcs8 object that uses aes-128-cbc.
0:d=0 hl=4 l= 719 cons: SEQUENCE
4:d=1 hl=2 l= 73 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :PBES2
17:d=2 hl=2 l= 60 cons: SEQUENCE
19:d=3 hl=2 l= 27 cons: SEQUENCE
21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2
32:d=4 hl=2 l= 14 cons: SEQUENCE
34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:C81795B560A892AA
44:d=5 hl=2 l= 2 prim: INTEGER :0800
48:d=3 hl=2 l= 29 cons: SEQUENCE
50:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc
...
That would not be a simple or compatible change, so "pkey" would
need to automatically switch to "pkcs8" when DER output is requested
in combination with encryption, and there'd need to be some logic
around automatically selecting v1.5 vs. v2.0 PBE algorithms.
Automatically switching methods would be just as big a
surprise (but at least not as insecure) as the current
behavior,so as long as pkey produces the "old SSLeay"
PEM-needing format by default, the best solution would
be to fatally reject attempts to produce that format is
DER.
Of cause there should be no fatal error if other options
indicate a request for an unencrypted key (e.g. -nodes)
or a format that works without extra PEM fields (e.g.
PKCS#8).
However to the extent not already there, there really
should be an option to select between "old SSLeay" and
PKCS#8 with various PBE algorithms. Preferably based
on similar options in other openssl subcommands (apps),
such as the -v1 and -v2 options to the pkcs8 subcommand,
the additions would be -v0 alg for the old format and
-nodes for not encrypting on output.
Ideally, this could go in shared code used by all the
private key file writing subcommands (apps).
This is needed because some programs require the old
input format for encrypted keys, while others require
PKCS#8 (and a few accept either with autodetect).
Transition proposal:
Initially, a patch for supported OpenSSL versions would
simply add the fatal error when trying to output the old
encrypted private key format as DER.
Next the version after 1.0.2 could add consistent private
key encryption options to all the affected apps, while
keeping the historic defaults of each command.
Documentation would encourage explicitly specifying the
desired format even if it happens to be the current default.
Then after a long transition period (to get all manner of
administrator scripts, tutorials and distribution tools
updated), the defaults could change to something more
consistent, but this would be years into the future.
Think time between "LTS" distribution releases (varies by
vendor), plus the traditional 5 year upgrade cycle in
professional enterprises.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
