[openssl-users] suggested enhancement documentation or warning for pkey command line tool

[Jakob Bohm]

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