Hi Peter - Thanks for the response, sorry for the delay in getting back to you.
To clarify - the proposed interface is fully tooling-agnostic. I am not
proposing integration with any specific signing API or library, but rather, a
mode where mkimage’s side of the signing is limited to creating the digests
that need to be signed, and ingesting the signatures after they have been
created.
To go into a bit more detail, here are my thoughts on how this would work from
an end-to-end perspective.
Step 1: mkimage --emit-hashes
*
mkimage builds the FIT as before, computes the digest(s) that would ordinarily
be passed to EVP_DigestSignFinal, and instead writes them along with signing
metadata to a JSON file. I have attached an example of what the hash and
signature files could look like.
Step 2: External signing
*
This is left to the caller and does not require anything from mkimage. The
information given in the hash file should be very straightforward for signers
to parse and use with their remote signing service. After completing the
signing, the signers will then create a JSON file containing entries
corresponding to each entry in the JSON file produced in step 1.
Step 3: mkimage --inject-signatures
*
mkimage reads the provided JSON signature file and writes each signature into
its correct FIT node by looking up the “id” field in the JSON as the FDT node
path. Optionally, it validates the signatures if the public key/certificate is
provided with the -G option.
A couple more comments:
*
The proposed exchange format is standard JSON - nothing proprietary. It is just
a thin, flexible adapter between mkimage and whatever signing service the
caller has available.
*
My thought is that json-c could be used to handle JSON file creation and
parsing. Here are a few reasons I see json-c as a potentially acceptable
dependency to add:
*
mkimage already relies on OpenSSL as an external dependency. json-c, in
comparison, is much lighter and much more narrowly scoped.
*
JSON’s simpler structure makes parsers less error-prone to implement correctly
than binary formats like ASN.1
*
json-c is already widely packaged in many major distros and is actively
maintained
Let me know if you have any other questions.
Thanks,
Daniel Frink
Firmware Engineer - PowerVM Security
IBM Rochester, MN
Email: [email protected]
From: Peter Robinson <[email protected]>
Date: Thursday, April 23, 2026 at 11:02 AM
To: Daniel Frink <[email protected]>
Cc: [email protected] <[email protected]>; George Wilson
<[email protected]>; Chris Engel <[email protected]>; NAYNA JAIN
<[email protected]>
Subject: [EXTERNAL] Re: RFC: Remote signing support for mkimage
Hi Daniel,
> I wanted to check whether a patch I'd like to submit to mkimage to better
> support remote secure signing servers would be acceptable for upstream.
>
> Currently, we support this capability via a custom PKCS#11 module via an
> OpenSSL engine. The migration to OpenSSL 3 (and the need to upgrade our
> libp11 dependency) is going to force major changes on our end, as newer
> releases of libp11 no longer reliably support signing with our OpenSSL
> engine/custom PKCS#11 module. The libp11 maintainers have explicitly stated
> they only support OpenSSL engines on a best-effort basis.
>
> It seems to me that the ideal solution would be support for a 3-step signing
> flow in mkimage:
>
> 1. mkimage --emit-hashes — emits all hashes that need to be signed
> 2. External signing tooling produces signatures
> 3. mkimage --inject-signatures — signatures for each hash are provided,
> validated against a provided public key, and injected back into the image
>
> We're aware the OpenSSL provider system is a potential uplift path, but we
> believe a tooling-agnostic signing interface would be more accessible to
> organizations with diverse signing infrastructure, avoiding the need to
> implement and maintain custom OpenSSL plugin code entirely. We'd also prefer
> not to resort to workarounds such as signing with a throwaway key and
> manually extracting/re-injecting signatures.
>
> If this direction seems acceptable, or if you're open to the idea but have
> concerns about the approach, I'd welcome your feedback before investing time
> in a full patch.
I think the ability to do remote signing functionality would be fine.
It might be useful to go into a bit more details of what you're
thinking here, is there open standards/APIs for this sort of
integration? Most of what I'm aware of, and it's been some time since
I looked, was either using PKCS interfaces or proprietary
APIs/libraries, the later IMO would not be appropriate.
Regards,
Peter
example-signatures.json
Description: example-signatures.json
example-hashes.json
Description: example-hashes.json
