Hello Tomas, All,
thanks for the link! I did some more investigation last night and
I think I tracked how things are supposed to work...
Specifically, as you say, the X509_ALGOR
(already DER encoded) is to be returned from the provider to the
openssl's library code via the get_ctx_param
function. The ASN1_item_sign_ctx()
calls the EVP_PKEY_CTX_get_params()
that, in turns, calls the provider's function where the parameter
that is queried is the OSSL_SIGNATURE_PARAM_ALGORITHM_ID.
At this point, the X509_ALGOR is
first serialized into its DER encoding:
And then the ASN1_item_sign_ctx() de-serializes it into the internal structure again, thus integrating the new value in the ASN1 structure that is being signed:
My guess this is needed because of the types of the parameters are limited and I wonder if it would it be feasible to define a parameter type that would allow to transfer internal representations instead of having to encode/decode the data to/from DER ... ?
Cheers,
Max
On Tue, 2023-08-29 at 13:56 -0600, Dr. Pala wrote:[...]The algorithm-id parameter is gettable only. I.e. the application is supposed to get the algorithm-id in the DER encoded from by using EVP_PKEY_CTX_get_params() which in turn calls the get_ctx_params function from your proovider. Generating the algorithm-id is a responsibility of your provider based on the algorithm parameters set by the application. You can look at the existing provider code for an inspiration. https://github.com/openssl/openssl/tree/master/providers/common/der
OpenCA Labs Director
