<div dir="auto">Thank you for your comment.<div dir="auto">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 ?</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Oct 2021, 14:13 Tomas Mraz, <<a href="mailto:tomas@openssl.org">tomas@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You would have to implement a STORE provider that handles your special<br>
url scheme and then the keys would be referenced by the<br>
yourscheme://any-identifier-you-have. Of course the application (i.e.,<br>
the openssl application which already does this) would have to use the<br>
OSSL_STORE API to load the keys and not directly the OSSL_DECODER API<br>
or the d2i/PEM_read APIs.<br>
<br>
Tomas<br>
<br>
On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote:<br>
> I checked the sources, I found that keyform cannot be set to ENGINE<br>
> if engine is not specified in the command options, this is in the<br>
> function make_engine_url() called from load_key() when<br>
> format==FORMAT_ENGINE. <br>
> I am not specifying engine in the dgst command options as I am using<br>
> a  provider.<br>
> I would like to achieve the same as FORMAT_ENGINE does, but with<br>
> provider.<br>
> <br>
> <br>
> On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana,<br>
> <<a href="mailto:santantonioswap@gmail.com" target="_blank" rel="noreferrer">santantonioswap@gmail.com</a>> wrote:<br>
> > Hello, <br>
> > I am doing my own provider starting from the default provider's<br>
> > code.<br>
> > I have now a question, I am seeing the STOREMGMT operation is<br>
> > required to interpret the URI of input private key,  I would like<br>
> > that the string passed by the user for input key is not interpret<br>
> > as file to open but just my provider should save the string value<br>
> > to be used later .This is  when invoking command options such as<br>
> > dgst sign -in "text" -keyform ENG.<br>
> > With engines' architecture this is possible by passing option -<br>
> > keyform ENG to dgst command. The string in that case is not<br>
> > interpreted as a file path and just passed through.<br>
> > There was engine_set_load_privkey_function that was getting this<br>
> > string.<br>
> > How can I achieve this now with the provider architecture ? If I<br>
> > pass -keyform ENG to dgst command together with --provider , it<br>
> > says "no engine specified to load private key" Should I use<br>
> > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? .<br>
> > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't<br>
> > have a real private key info to load and use from a Filesystem.<br>
> > Is there anything to set in the KEYMGMT too ? I can see there is a<br>
> > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key<br>
> > data in a key object should be considered. Not really sure if this<br>
> > is something I should set or not and how this keymgmt operation<br>
> > relates with storemgmt operation. <br>
> > <br>
> > thank you if you can send some comment on this.<br>
> > <br>
<br>
-- <br>
Tomáš Mráz<br>
No matter how far down the wrong road you've gone, turn back.<br>
                                              Turkish proverb<br>
[You'll know whether the road is wrong if you carefully listen to your<br>
conscience.]<br>
<br>
<br>
</blockquote></div>