Because of #11242, I had a closer look at how the SM2 ID is being set, and why. It's a bit of a hack, really, and it shouldn't be necessary to give it this special treatment... it should be something settable with EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() alongside any other key operation control, i.e. after EVP_DigestSignInit() and other similar functions.

By consequence, the apps shouldn't need separate -sm2-id options, they should able to specify the SM2 ID, with options such as -sigopt sm2id:ABC or -sigopt hexsm2id:414243.

I suspect that the major driving force behind this special treatment is this:

In other words, the call of digest_custom in EVP_DigestSignInit() forces everyone to have special knowledge about SM2 IDs (which makes it hard to have it as a configurable option among others).

This call could be moved to the corresponding Update (and Final in case Update wasn't called first) functions, and be subject of a flag set in the EVP_PKEY_CTX so it's only called once.

The above isn't very tricky at all. openssl verify and X509_verify() are, however, because they don't touch keys, at least directly, so calling EVP_PKEY_CTX_ctrl() isn't the first thing that comes to mind. An idea would be to have a similar mechanism to set optional data, something like X509_STORE_CTX_ctrl() and X509_STORE_CTX_ctrl_str(), and then have a X509_verify_ctx() that takes an extra X509_STORE_CTX * argument that it can pilfer data from.

Do note that with provider side implementations, there is no early processing support à la digest_custom, and I would rather see that it doesn't get added either. This will force "early processing" to happen as part of the update (or final if no update was called) calls.