Piotr, I can see what you mean now during debugging. I have now managed to set the flags in the RSA structure, not only in the RSA_METHOD. One point I noticed is that you need to explicitly fill in all of the methods in RSA_METHOD now , so those that you don't want to override must be got from the default and set them accordingly in RSA_METHOD structure. I still have to pass back a valid key to dgst's callback from the store mgmt's load() otherwise the call chain complains for missing key. This shouldn't be needed in my opinion if RSA_FLAG_EXT_PKEY is set .
On Tue, Oct 12, 2021 at 1:35 PM Piotr Lobacz <piotr.lob...@softgent.com> wrote: > I'm sorry i cannot help you with providers. All i can tell you, is that in > my case libpkcs11 was not setting using RSA_meth_set_flags but > RSA_set_flags and in dotnet openssl implementation, the check was being > made on the method. I was thinking that our issues may be related. > > BR > Piotr > ------------------------------ > *Od:* Antonio Santagiuliana <santantonios...@gmail.com> > *Wysłane:* wtorek, 12 października 2021 10:50 > *Do:* Piotr Lobacz <piotr.lob...@softgent.com>; openssl-users@openssl.org > <openssl-users@openssl.org> > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > in general, I think that despite what I read in previous replies, > with the operation: > dgst --provider=myprovider -sign handle:1 > is not possible to fully reproduce what was possible with engines : > dgst -keyform ENG sign -in 1 -engine=myengine. > In the case of provider the store manager's caller sets > ossl_store_handle_load_result as fixed callback method when calling the > load of store mgmt. If that callback is not called , it will complain as no > private key is possible to read. > > > On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana < > santantonios...@gmail.com> wrote: > > Thank you for the suggestion. > I am using providers though, not engine, and I can't see the higher level > checking this RSA flags before it has detected a valid key is passed back > from the store manager to ossl_store_handle_load_result() ( the callback > passed to the store mgmt load() method). > If I don't call the callback ossl_store_handle_load_result the higher > level after the store mgmt load() complains no private key can be read. > If I pass back an RSA key generated on the fly in the store mgmt load() > then the ossl_store_handle_load_result() is fine using the RSA key mgmt > load finds error in checking RSA flags , I think these flags are not set > but I don't know how to set them in the fictitious private key I generated > on the fly in the store mgmt load() with > EVP_PKEY *pkey = NULL; > pkey = EVP_RSA_gen(2048); > This produces a valid pkey without errors but I think the rsa fields are > not filled in.How can I add them to pkey ? > I think I should register a different keymgmt on my provider but I am not > sure what it should do in my case. > So , for now, the RSA keymgmt is called and in its load() function > ( rsa_load() ) at some point it wants to check RSA_check_flags() and there > it stops as the rsa struct fileds referenced are not filled in. > > > > On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, <piotr.lob...@softgent.com> wrote: > > Hi Antonio, > I was discussing about this problem about half a year ago in here. The > problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in > RSA_METHOD which is wrong. Yo can read it in here > https://github.com/dotnet/runtime/issues/53345. The clue of my problem > was that this flag was being set by the dotnet and engine was setting it in > RSA_set_flags - which is the proper way. You need to verify how the engine > sets this flag and read my issue maybe it will help you in solving yours. > > BR > Piotr > ------------------------------ > *Od:* openssl-users <openssl-users-boun...@openssl.org> w imieniu > użytkownika Antonio Santagiuliana <santantonios...@gmail.com> > *Wysłane:* piątek, 8 października 2021 10:34 > *Do:* Tomas Mraz <to...@openssl.org> > *DW:* openssl-users@openssl.org <openssl-users@openssl.org> > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > Could I ask you what is the best way to let the Openssl carry on in the > case I can't pass the private key from my store manager load() function as > key is offloaded in secure hw? > I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the > callback function from my Store Mgmt's load() where I get the uri ( the > callback func is ossl_store_handle_load_result() ) I get error "could not > read the private key". > If instead I call the callback func , I don't know how to fill in its > params , as I don't have the private key. What should I put in the params > to let the rest of call chain ( I am on the dgst command ) not caring about > private key but carry on with operation?or can I avoid calling the callback? > Thank you > > On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, < > santantonios...@gmail.com> wrote: > > 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.] > >> > >> > > <https://www.softgent.com> > > *Softgent Sp. z o.o.*, Budowlanych 31d, 80-298 Gdansk, POLAND > > KRS: 0000674406, NIP: 9581679801, REGON: 367090912 > www.softgent.com > > Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego > Rejestru Sądowego > > KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości. > > Jesteśmy uczestnikiem Programu > *RZETELNA* *Firma * > Sprawdź naszą rzetelność na > https://www.rzetelnafirma.pl/F5IA32UW > >
