On Sun, 20 Nov 2022 17:15:06 -0500, Viktor Dukhovni wrote: > On Sun, Nov 20, 2022 at 02:12:34PM -0600, Nico Williams wrote: > > > Generally, I would expect d2i_... to automatically detect the algorithm > > > when tagged with a suitable OIDs, and so d2i_AutoPrivateKey() could > > > often work, but if you know the expected key type, you can ask for > > > that explicitly with d2i_PrivateKey(). > > > > So, d2i_PrivateKey() wants a PKCS#8 wrapper so it can figure out what > > the type of the private key blob is. > > Not exactly, PKCS#8-based typing is used in d2i_PKCS8_PRIV_KEY_INFO() > (for unencrypted PKCS#8 blobs, so no password callback). The > d2i_PrivateKey() function takes an explicit pkey_type instead. Hmmm, well, d2i_PrivateKey() takes an explicit pkey_type, yes, but it's not sufficiently informative for ECDH, being just EVP_PKEY_EC. Or are there more informative type values I've not discovered yet? When I call d2i_PrivateKey(EVP_PKEY_EC, ...) it wants a PKCS#8 encoded private key. If there's a more specific type than EVP_PKEY_EC that I could use so that d2i_PrivateKey() can decode just the raw private key, that'd be great. I couldn't find such a type. > > On the other hand, d2i_PublicKey() wants the input key to indicate the > > type of public key to import. A strange asymmetry, but it works. > > Staring at Postfix and OpenSSL code helped. > > For X.509 SPKI public keys (the ones you generally want to use) the right > interface is d2i_PUBKEY, not d2i_PublicKey(). Thanks, good to know. d2i/i2d_PUBKEY() uses the OSSL_ENCODER API internally. Where do I find out what all the supported output_type / output_struct values are. Also, the prototype for i2d_PUBKEY() does not appear in any header, public or private, but i2d_PUBKEY() _is_ documented -- is this a bug? Thanks, Nico --
