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

[Viktor Dukhovni]

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-----

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.

Is there a suitable standard DER format for generically encrypted
objects that can generalize and replace PKCS#8?

-- 
	Viktor.