Store Mgmt and keys loading ( keyform ENG )

[Antonio Santagiuliana]

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211004/bcd00604/attachment.html>