Request for authority-id documentation or explanation

snapd
1

Can someone explain how the authority-id fits into the assertion picture and what role it plays. I’m a bit confused by exactly what it means.

I can see the authority-id and brand-id must match (at least for models). So in the case of the generic model they match.

Is this purely a backend implementation detail with no realization on the client except that they must match in model assertions?

Thanks.

2

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.

3

Jamesh- thanks so much for taking the time to provide some information. I appreciate it.

Can you tell me also if there is any realization on the snapd side for behavior that is determined by authority id?

Thanks.

4

There are two aspects where it is important:

  1. snapd is not going to trust an assertion if it can’t trace the authority back to an assertion signed by the trust root (i.e. authority-id: canonical).
  2. snapd requires that model definition assertions be signed by the the account referenced by brand-id. This in effect requires authority-id == brand-id for model assertions.
1 Like