Hi Erik, Odd,

I'm also CC:ing the st-discuss list to loop in other folks.

This email relates to the following accepted proposal:

  https://git.glasklar.is/system-transparency/project/documentation/-/blob/main/proposals/2024-12-17-decrypt-ospkg.md

Which has been implemented and documented, and it is currently on track
to be included in the upcoming st-v1.2.0 collection release.

During today's weekly meet it was raised that there's one important
aspect of the proposal that (maybe?) wasn't discussed, see:

  https://git.glasklar.is/system-transparency/project/documentation/-/blob/main/archive/2025-01-20-meeting-minutes.md#other

TL;DR: the stboot image (which contains the trust policy) didn't contain
any secrets before, but it does if the optional decrypt key is added.

This is possibly annoying in a future scenario when there's remote
attestation, since the stboot image would likely be measured (and so
also need to be public in order to predict expected PCRs values).

It also makes key rotation harder, i.e., a new stboot image is needed.

It might be an annoyance that the stboot image needs to be secret.

Is this something you considered and are not bothered by?  I'm asking
because otherwise it's not too late to do a follow-up proposal and
update the implementation to use EFI NVRAM (provisioned by stprov).

Some possile options moving forward:

  - Do nothing, if you're OS package needs to be secret you're also okay
    with the stboot image needing to be secret (the accepted proposal).
  - Make a follow-up proposal and update what was already merged, to
    instead move the secret from stboot's trust policy to EFI NVRAM.
  - Make a follow-up proposal later if someone wants it.  Then stboot
    would have to have a semantic for optionally locating decrypt keys
    in both the trust policy and EFI NVRAM.  Perhaps a bit ugly, but not
    a major complication when seeing the forest for the trees.

I think all of the above would be okay.  What's your preference?

-Rasmus