[PATCH v3 2/2] binman: x509_cert: add PKCS#11/HSM signing support

[Quentin Schulz]

Hi Sergio,

On 5/7/26 10:09 PM, Sergio Prado wrote:
> Hi Quentin,
> 
>>> Good point. I’ll scope this more precisely to X.509 usage. Would
>>> BINMAN_X509_PKCS11_URI be appropriate, or do you have a preferred naming
>>> convention here?
>>>
>>
>> Is this really PKCS11-specific? Is there no other way to get an x509
>> than by PKCS11 or plaintext file? Trying to think about potentially
>> having other providers needing something similar and then setting
>> BINMAN_X509_PKCS11_URI for that would be confusing.
> 
> Hmmm, good point. What if we rename the variable to BINMAN_X509_KEY_URI and
> the entry argument to key-uri?
> 

We should have x509 in the entry argument as key-uri could mean the URI 
used for signing FIT images for example.

The other thing I'm worried about is "will there always be only one x509 
certificate per binman invocation or can we have more".

For signing FIT images, it's pretty simple, mkimage only supports one 
configuration for the whole FIT last time I checked so it's not a worry 
as much more plumbing needs to be added to support that. Though what 
happens when you want to sign two FITs per binman run each with their 
own key... Not sure there's a usecase for that though.

>>>   From my testing with SoftHSM2:
>>>
>>> - Provider-based flow: configuring openssl.cnf is sufficient. OpenSSL
>>> dispatches "pkcs11:" URIs via the STORE API without additional CLI
>>> arguments.
>>> - Engine-based flow: configuring the engine in openssl.cnf alone is not
>>> sufficient; "-engine pkcs11 -keyform engine" must still be passed
>>> explicitly.
>>>
>>
>> Being curious now, I'm wondering if setting the -key to
>> org.openssl.engine:pkcs11:<key> would be enough on OpenSSL 3.x? C.f.
>> https://docs.openssl.org/3.0/man1/openssl/#engine-options
> 
> Good catch! It does work.
> 
> $ OPENSSL_CONF=test_engine.cnf openssl req -new -x509 -key \
>     "org.openssl.engine:pkcs11:${PKCS11_URI}" -nodes -outform DER \
>     -out cert_engine_unified.der -subj "/CN=test-unified-engine" \
>     -sha512 && echo "exit: $?"
> exit: 0
> 
> With this, the implementation transparently supports both flows on OpenSSL
> 3.x - the user picks the URI form to match their setup. I'll document both
> URI forms in the binman documentation.
> 

I guess that's acceptable. I don't think we should bend backwards to 
support OpenSSL 1.x :)

I've realized that we have only one test for the x509-cert entry type, 
seems like it'd be nice to have more :) I don't think we need to make 
this a requirement for this series though.
We also have virtually no documentation for the arguments (they shoiuld 
be in the docstring of the Entry_x509_cert class), this we should fix 
and add the new arguments/properties to the docstring.
Finally, Entry_ti_secure and Entry_ti_secure_rom both extend 
Entry_x509_cert and both call super().<method> on the Entry_x509_cert 
mtehods so their docstring should be updated to reflect that and 
possibly add tests for pkcs11 to those entries as well.

Cheers,
Quentin