SSL and "custom" EVP_KEY
matt at openssl.org
Tue Nov 2 11:43:14 UTC 2021
On 02/11/2021 04:42, Alex Dankow wrote:
> Thank you very much for your response. I understand that the FIPS
> certified OpenSSL module is long awaited and the team was quite limited
> in time to complete all features.
> I tried Windows certificates +Openssl because it implements the most
> common scenario: you can get a certificate to Openssl in DER format, but
> you can't get the private key. HSMs, KMIP servers or Windows don't let
> you export the private key. It can be only virtualized (You sure know
> it, but I'm writing it also for our readers.)
> So, when I load X509 from storage it is handled by OpenSSL directly and
> gets type "RSA".When the private key is supplied, it has type of
> "MYTYPE" and actually represents a handle. If I skip the key matching
> part, "openssl ca" works and a cert request can be signed with such a
As per Tomas's comment if it really is an RSA key then you should call
it that. It does not matter that the private key cannot be extracted -
it is perfectly valid to have a provider that does not export its
private keys. We make no requirements on provider authors as to how keys
should be represented internally to the provider. If its a handle rather
than an "RSA" structure - then that's fine - OpenSSL doesn't care.
> As I understand, Openssl doesn't handle it completely yet.
OpenSSL doesn't handle "pluggable" signatures. So you can't add a
signature algorithm that libssl doesn't know about and get it to work.
It should work just fine for RSA keys though since libssl knows what to
do with those.
> But it was
> planned so and maybe we will see it in the future.
> If ENGINE is now deprecated (is it?), what HSM vendors should do?
> Alex Dankow
> On Fri, Oct 29, 2021 at 10:11 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> Hi Alex,
> On 29/10/2021 14:32, Alex Dankow wrote:
> > Hi OpenSSL team!
> > I wrote a provider for Windows certificates and implemented
> "openssl ca".
> > Now, I think it would be fun to see a HTTPS server using
> > installed in Windows storage.
> > Certificate is loaded using load_cert_pass (taken from apps.c) with
> > custom uri "wincert://11:22:33....", private key is loaded with
> > load_key from apps.c too. It works, but ...
> > When I use SSL_CTX_use_PrivateKey(ctx, myprivk) the key is
> > OpenSSL compares strings and expects "rsaEncryption", and so on
> > of "MYKEY". Why ?
> It's not entirely clear to me what you are attempting here. Are your
> certificates/keys stored in Windows storage standard RSA/ECDSA etc
> certs? Or are they using some custom algorithm?
> If they are standard RSA/ECSDA certs then you should be using the
> correct standard algorithm names in you keymgmt etc and it should all
> "just work".
> Unfortunately, in 3.0, libssl only supports standard algorithms. We
> discussed a "pluggable" signature scheme mechanism which would enable
> plugging in arbitrary algorithms but it didn't make it for 3.0:
> I'd still like to get back to that at some point but we don't have it
> yet. It should be entirely possible with the new provider
> architecture -
> and in fact we *did* add pluggable kex/kem support for libssl. But we
> just ran out of time with pluggable signatures.
> > Maybe I'm missing something, but if you built a key management
> > sign interface, ciphers that allows key virtualization, why not go
> > further ? I'm ready to implement the encryption interface, but why
> > OpenSSL still care about key type name. In the new era of version
> 3, it
> > can check if the key provides necessary interfaces.
> > --
> > Alex Dankow
More information about the openssl-users