[openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

Viktor,

Thank you for this in-depth explanation.

I have talked to a number of large potential customers where certs are 
important but they are highly constrained.  This includes the auto 
sector with ECUs that are really pressed to the wall (like on the engine 
block and already running at 130C!)

A PEM ECDSA private key file (not passworded) is 241 bytes.  The DER 
equivalent is 121 bytes.  Even if we follow the ANIMA model that allows 
both the iDevID and lDevID certs to use the same key (shudder), a 120 
bytes of secure store savings is a big issue. Otherwise we double this 
storage cost.   Ed25519 should be smaller, as the public key is 32 
bytes, not the 64 of P256.  But I don't like that they used SHA512 for 
Ed25519 rather than SPAKE128 (they used SPAKE256 for Ed488).

And then there is the cert store in regular storage, plus whatever 
support (like chains) needed.  As I think more of this, 802.1AR-2009 
only expects to device to have its iDevID cert, not also the cert chain 
to the root.  It never has to verify its cert, the manufacturer stuffed 
it in at built time into read only memory with an expiry date of 
forever.  It is the lDevID part that ANIMA is building into a complex 
bootstrap process that I don't totally agree with.  And NETCONF is doing 
their flavor of it.  Sigh.

The IETF CORE wg is looking at this too.

I have to munch on this problem a lot more.

Bob

On 08/22/2017 10:19 AM, Viktor Dukhovni wrote:
>> On Aug 21, 2017, at 9:02 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>>
>> openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
>> -in $dir/csr/intermediate.csr.$format -outform $format -out $dir/certs/intermediate.cert.$format\
>> -CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
>> -CA $cadir/certs/ca.cert.$format
>>
>> Where format=der and got that der is an invalid option.  Plus the 'help' reported:
> It is trivial to convert a PEM certificate to DER, just pipe the output through
> "openssl x509 -outform DER".  Mind you this is often the wrong thing to do, because
> the DER form of an X.509 certificate holds *exactly* one certificate, while users
> often need a certificate *chain*, that also includes the requisite intermediate
> certificates.  With PEM, the certificate file can just all the certificates back
> to back.  With DER only the EE certificate appears in the file.
>
> While PKCS#7 can hold a bunch of certificates in DER form, it is not typically
> used a certificate chain file by any applications, and IIRC there's no indication
> of which of the certificates is the end-entity certificate in a PKCS#7 file.
>
> The only widely used DER form for chains is PKCS#12 which holds the private
> key as well as the certificate chain, and has a mandatory passphrase.  I use
> PKCS#12 (instead of JKS) for Java TLS server applications, set the file
> access mode to 0600, and since there's no point in prompting batch applications
> for a passphrase, set the passphrase to "umask 077", since that's the only
> effective protection for the private key.
>
> It is not clear that PKCS#12 is compellingly more compact than PEM, the only
> reason I use it is that Java supports JKS and PKCS#12, but not PEM.
>
>> Note that -CAkeyform is invalid and that -CAkey can only be PEM.
> As explained before, the API for DER PrivateKey objects does not
> support passwords, and the CLI does not have a way to indicate
> the use PKCS8PrivateKey instead.  The PrivateKey interface can
> read only unencrypted PKCS#8 in PEM form.
>
>> Even when I used my pem CA key, I still got errors.  -config is
>> not an option, where does this command get the config file from?
>> -extensions says it looks to the config file for that label!
> The config file for "x509 -req" is specified with "-extfile ...".
>
>> SHA256 is not listed as a valid hash.
> Many more X.509 digest algorithms are supported in this context
> than (sadly) are listed in the manpage.  Perhaps there should
> be a command that lists all supported x.509 hash algorithms,
> and the documentation for commands that take any of the
> supported algorithms can just refer the reader to the output
> of that command.
>