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@xxxxxxxxxxx
<mailto: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
<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
>
>
