SSL and "custom" EVP_KEY

[Matt Caswell]

On 02/11/2021 04:42, 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 
> part, "openssl ca" works and a cert request can be signed with such a 
> handle.

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.

Matt


> 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
>     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
>     <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/11914>
>     https://github.com/openssl/openssl/pull/13018
>     <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
>      >
>      >
>