On Wed, 2023-08-30 at 13:26 -0600, Dr. Pala wrote: > 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: > * > https://github.com/openssl/openssl/blob/84364b9dc693a30fa55c22e684b45978a5bcc77b/crypto/asn1/a_sign.c#L183 > 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: > * > https://github.com/openssl/openssl/blob/84364b9dc693a30fa55c22e684b45978a5bcc77b/crypto/asn1/a_sign.c#L194 > 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 You get it right. However it would not be possible to transfer internal structures because that would not be truly provider-implementation- agnostic. The main goal of the provider API is to allow the provider implementation to be completely independent from the libcrypto that loads the provider. It thus cannot depend on internal libcrypto structures. The provider can be not using libcrypto at all for example. Encoding-decoding the DER structure for the algorithm ID is fairly trivial in terms of CPU cycles especially when compared with the complexity of the actual signature computation. -- Tomáš Mráz, OpenSSL
