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@xxxxxxxxxxxxxxx> 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.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
