It is because of prototypes of methods..
On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <santantonios...@gmail.com>
wrote:
> Hello,
> just continuing on this..
> I defined my store mgmt as :
> static const OSSL_ALGORITHM test_store[] = {
> { "handle", "provider=test", mystore_functions},
> {NULL, NULL, NULL}
> };
>
> echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst
> --provider-path=./providers --provider=test --sign handle:1 -out
> messa.encrypted.bin
>
> Could not open file or uri for loading private key from handle:1
>
> C0628C24787F0000:error:16000069:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=file
>
> C0628C24787F0000:error:1608010C:STORE
> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
> store loader found. For standard store loaders you need at least one
> of the default or base providers available. Did you forget to load
> them? Info: Global default library context, Scheme (file : 0),
> Properties (<null>)
>
> C0628C24787F0000:error:16000069:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=handle
>
> 1) It firstly looks for a provider for scheme file: and it doesn't
> find as I haven't set up any store mgmt for file: .
>
> 2) It looks like on second attempt it tries to look for handle: but it
> finds it not registered. What does this error mean ? Does it look for
> registered uri schemes online ? if that is the case how can this works
> instead : https://github.com/tpm2-software/tpm2-openssl ? They use
> handle: scheme as well.
>
> Does this mean it's a problem of the methods I registered for the
> store or is something related to the uri scheme I am using ?
> Sorry but I couldn't find more info on this in the sources/docs .
>
>
> thank you
>
>
>
> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana
> <santantonios...@gmail.com> wrote:
> >
> > OK, thank you very much for your comments, that's clear.
> >
> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, <to...@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, <to...@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,
> >> > > > <santantonios...@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.]
> >>
> >>
>
