Re: [PATCH 0/3] mkimage: allow to specify signing algorithm

Jan Kiszka
2022-01-14T09:22:24Z

On 14.01.22 00:28, Dhananjay Phadke wrote:
> On 1/13/2022 4:38 AM, Jan Kiszka wrote:
>> On 25.11.21 20:03, Jan Kiszka wrote:
>>> Another step to decouple the FIT image specification from the actual
>>> signing: With these changes, the signature nodes can leave out an algo
>>> property, mkimage will initialize that as well while signing. This way,
>>> in-tree FIT source files can be prepared for gaining signatures without
>>> defining the key type or size upfront, forcing users to patch the code
>>> to change that.
>
> [resend to the list]
>
> While encryption algo (rsa2048 vs rsa4096, etc) shouldn't need to be
> explicitly specified as you noted below, how does it help to add it to
> (already exhaustive) mkimage args? Parsing OID / length from keyfile
> would be real change.
>
> While rotating keys is common, how often algo is changed?
>

The use case is decoupling of signature preparation from actual signing.
Means, we would like to prepare binman image device trees for applying
signature but without making the decision which key type and width
should be used. That shall be up to the user (integrator) of the
firmware image.

This series will enable a patch like
https://github.com/siemens/u-boot/commit/1215a357ec1f58acde56c8ca4085aa43f8fdbf5a
and a signature workflow that does not require to patch the U-Boot
source anymore. It still makes the decision of using hash algo SHA256,
but that is acceptable.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux