SSL and "custom" EVP_KEY

[Tomas Mraz]

On Tue, 2021-11-02 at 11:42 +0700, Alex Dankow wrote:
> Matt, 
> 
> 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

It should not have a type "MYTYPE" if it is really an RSA key. There
are some pecularities with how the openssl-3.0.0 works however 3.0.1
will contain a fix that should make this work correctly for
unexportable private keys of any common type. Your provider will be
invoked for operations with the private key.

> part, "openssl ca" works and a cert request can be signed with such a
> handle.
> As I understand, Openssl doesn't handle it completely yet. 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>
> 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
> > certificates 
> > > installed in Windows storage.
> > Nice!
> > 
> > > 
> > > 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
> > declined. 
> > > OpenSSL compares strings and expects "rsaEncryption", and so on
> > instead 
> > > 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
> > have 
> > discussed a "pluggable" signature scheme mechanism which would
> > enable
> > plugging in arbitrary algorithms but it didn't make it for 3.0:
> > 
> > https://github.com/openssl/openssl/issues/10512
> > 
> > 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.
> > 
> > https://github.com/openssl/openssl/pull/11914
> > https://github.com/openssl/openssl/pull/13018
> > 
> > 
> > Matt
> > 
> > > Maybe I'm missing something, but if you built a key management
> > system, 
> > > 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
> > > 
> > > 

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]