Digest and signature?

[Dionna Amalie Glaze]

I've come here from the UEFI Plugfest 2021 talk on the firmware bill of materials. I studied the RIM specification from the TCG, the official tool that you link to, and this code base, and in all places I can't answer the question of how to compute the digest of RIM over which to create a signature. The specification example digest is 88F21D8E44D4271149297404DF91CAF207130BFA116582408ABD04EDE6DB7F51 and I just don't see it. Where do you stand as a tool provider on this issue? Should firmware manufacturers create CoSWID objects without a digest or signature, hash and sign that, and reconstruct the object with the digest and signature added? That unfortunately changes to digest depending on the RIM representation choice (CBOR or XML), so I've asked the trusted computing group for clarification. For a two year old document I feel I might have missed the boat.

[Richard Hughes]

Where do you stand as a tool provider on this issue

Hey. I've deliberately left out signatures from all this; the idea being that the EFI coSWID data will be signed by the existing AuthentiCode signature, and the external header+coSWID blobs for immutable data will be part of the FV that's also signed for SecureBoot.

That unfortunately changes to digest

I think the general idea for uSWID is that the metadata gets included in the best case when the EFI binary is generated, rather than "added" after the fact. Does that help?

[Dionna Amalie Glaze]

OK I may have misunderstood the use of this tool. I'm coming out this from the viewpoint of the provider of first mutable code, i.e., SEC stage UEFI, so I'm trying to understand how to create a signed reference measurement the implements SecureBoot. The measurement to verify would either be in PCR0 or in a TEE launch measurement. Please close it that's not an intended use case.