Store Mgmt and keys loading ( keyform ENG )

[Antonio Santagiuliana]

OK, thank you very much for your comments, that's clear.

On Mon, 4 Oct 2021, 15:45 Tomas Mraz, <tomas at openssl.org> wrote:

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