Tomas Mraz wrote in
<
57e1834035e9a9e603f916f...@openssl.org>:
|On Fri, 2025-08-22 at 17:07 -0400, Michael Richardson wrote:
...
|> Okay, step back.
|> What we really want to know is: can this EVP_PKEY perform a signature
|> operation.
...
|There is a EVP_PKEY_can_sign(const EVP_PKEY *pkey) function which will
|give you answer, whether the key type can be used for signing. However
|it won't check whether there actually is a private key held by the pkey
|object.
|
|We do have a provider API call (the has() function) to discover that
|but that is not directly exposed via EVP API. Furthermore there might
|be other reasons (in 3rd party providers) why a key cannot be used for
|signing such as access rights or similar.
|
|You can use EVP_PKEY_can_sign() as a sort of pre-check but then you
|still need to check the result of EVP_DigestSignInit() which can only
|give you the definitive answer.
|
|> EVP_DigestSignInit() still has ENGINE* argument.
|> While EVP_DigestSignInit_ex() has OSSL_LIB_CTX.
|> I find this confusing!
|
|The EVP_DigestSignInit() function pre-dates the providers and library
|contexts, but it will still work with provider-based keys (with the
|default library context).
|
|EVP_DigestSignInit_ex() has to be used if you need non-default library
|context.
Is there any plan on making EVP_DIGESTSIGNINIT(3ssl)'s
Note that not all providers support continuation, in case the selected
provider does not allow to duplicate contexts EVP_DigestSignFinal() will
finalize the digest context and attempting to process additional data
via EVP_DigestSignUpdate() will result in an error.
automatically detectable? Or is a call to
EVP_MD_CTX_test_flags(CTX, EVP_MD_CTX_FLAG_FINALISE)
the way to go? And if so, couldn't this become documented?
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)