Store Mgmt and keys loading ( keyform ENG )

[Tomas Mraz]

No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already
modified to use OSSL_STORE API to load keys. So you do not need to
specify keyform=ENGINE if your key is provided by a provider that
supports the STORE functionality for some special URL scheme. You just
specify the right URL with that scheme to reference the key in the
provider.

Of course third party applications need to be modified to call
OSSL_STORE API in a similar way how the openssl application does it.

Tomas

On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote:
> Thank you for your comment.
> Am I wrong then in saying that dgst and possibly other apps are not
> ready to be used with providers  rather than engines in the case you
> need keyform=ENGINE ?
> 
> 
> On Mon, 4 Oct 2021, 14:13 Tomas Mraz, <tomas at openssl.org> wrote:
> > You would have to implement a STORE provider that handles your
> > special
> > url scheme and then the keys would be referenced by the
> > yourscheme://any-identifier-you-have. Of course the application
> > (i.e.,
> > the openssl application which already does this) would have to use
> > the
> > OSSL_STORE API to load the keys and not directly the OSSL_DECODER
> > API
> > or the d2i/PEM_read APIs.
> > 
> > Tomas
> > 
> > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote:
> > > I checked the sources, I found that keyform cannot be set to
> > > ENGINE
> > > if engine is not specified in the command options, this is in the
> > > function make_engine_url() called from load_key() when
> > > format==FORMAT_ENGINE. 
> > > I am not specifying engine in the dgst command options as I am
> > using
> > > a  provider.
> > > I would like to achieve the same as FORMAT_ENGINE does, but with
> > > provider.
> > > 
> > > 
> > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana,
> > > <santantonioswap at gmail.com> wrote:
> > > > Hello, 
> > > > I am doing my own provider starting from the default provider's
> > > > code.
> > > > I have now a question, I am seeing the STOREMGMT operation is
> > > > required to interpret the URI of input private key,  I would
> > > > like
> > > > that the string passed by the user for input key is not
> > > > interpret
> > > > as file to open but just my provider should save the string
> > > > value
> > > > to be used later .This is  when invoking command options such
> > > > as
> > > > dgst sign -in "text" -keyform ENG.
> > > > With engines' architecture this is possible by passing option -
> > > > keyform ENG to dgst command. The string in that case is not
> > > > interpreted as a file path and just passed through.
> > > > There was engine_set_load_privkey_function that was getting
> > > > this
> > > > string.
> > > > How can I achieve this now with the provider architecture ? If
> > > > I
> > > > pass -keyform ENG to dgst command together with --provider , it
> > > > says "no engine specified to load private key" Should I use
> > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? .
> > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I
> > don't
> > > > have a real private key info to load and use from a Filesystem.
> > > > Is there anything to set in the KEYMGMT too ? I can see there
> > > > is
> > a
> > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key
> > > > data in a key object should be considered. Not really sure if
> > this
> > > > is something I should set or not and how this keymgmt operation
> > > > relates with storemgmt operation. 
> > > > 
> > > > thank you if you can send some comment on this.
> > > > 
> > 

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