Model definitions are one example of what snapd calls “assertions”. An assertion is essentially a yaml document with a digital signature appended that covers the contents that came previously.
There are a number of “meta headers” that can appear in the assertion that are common to all assertion types. These include:
-
type
is the type of the assertion. This indicates how all the non-meta headers should be interpreted. For model definitions, this is set to model
.
-
authority-id
identifies who owns the key that signed this assertion.
-
sign-key-sha3-384
identifies the public key used to sign the assertion.
We can use the snap command to look up the signing key for the assertion based on the key fingerprint identified by sign-key-sha3-384
:
snap known --remote account-key public-key-sha3-384=$fingerprint
This will return an assertion of the account-key
type, which includes a copy of the associated public key. It also identifies the account-id
that owns the key. So we can use this to validate the signature on our first assertion, and verify that the account associated with the key matches the authority-id
of the assertion.
As the account-key
assertion is also signed, we could also verify this assertion. In this case, the assertion is signed with authority-id: canonical
, who has signed their own related account-key
assertion. This is in fact the root of trust baked into snapd, used to verify everything else.
We can also learn more about an account identified by authority-id
header by downloading its account
assertion:
snap known --remote account account-id=$authority_id
So that’s what authority-id
is. The brand-id
header is specific to type: model
assertions, and identifies the account that created this particular type of device. At present such an assertion needs to be signed by the brand-id
account, hence the requirement that authority-id == brand-id
.
That begs the question of why the brand ID isn’t just inferred from the authority that signed the assertion. I’m not sure of the details behind that but I’d guess it was to future proof the design, if in future we wanted to allow brand accounts to delegate the authority to sign model definitions on their behalf. That would introduce an extra assertion in the chain of trust needed to verify the model definition.