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@xxxxxxxxxxx> > 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.]
