define TUF metadata layout

[jku]

• docs/TUF-CLIENT-DESIGN.md talks about some constraints the client puts on the metadata structure (or the way targets delegations must work).
• PEP-480 defines a metadata structure that is likely quite close to what we want (although I'm not sure if supporting the "unclaimed" delegation makes sense here)...
• ... but at least the issue of developer key changes likely requires some modifications to PEP-480

We might not have all the information we need to create a final metadata structure but I think we should still go ahead and build one: It would be good to have actual metadata in a repository ASAP.

[jku]

I'm trying to create a layout that provides the sort of delegation that the client features requires, and that I think could be maintained by the (so far vague) developer tool mechanisms and admin processes we've discussed.

Maintainer keys

There are two levels of maintainer keys. This is not something maintainers need to manage themselves or even care about much: they only need to know that the ability to approve key changes has a delay (because repository admins only promote keys as part of a periodical admin signing).

Maintainer key types:

1. new: An existing maintainer has added a key into keys-X. This gives the new key permissions to sign targets changes in targets-X
2. promoted: A repository admin has taken the keys from keys-X and promoted (copied) them to the delegating bin-NNN. This gives the keys permssion to sign key changes in keys-X

So a maintainer only ever needs one key: first it is added to keys-X by an existing maintainer and later the same key is also promoted (copied) to bin-NNNN (this is automatic from maintainers POV, just takes some time). The purpose of the two levels is to make sure that maintainers can do immediate key changes without forcing repository/admin targets keys to be online.

Admin processes

This layout requires repository admins to resign the bins-layer once in a while to

• promote maintainer key changes
• remove project delegations (?)
• move project delegations from recently-claimed to claimed

Delegation layout

Metadata layout should have:

• a claimed/recently-claimed layer to allow adding new projects
• a succinct delegation layer to keep metadata file sizes reasonable
• a project key layer to separate "added" and "promoted" keys (see Maintainer keys)
• a project targets layer to contain the actual target file lists

The layout should make sure the role name never starts with a project-specific variant: this allows the layout to change in future as new prefixes are safe to use.

Potential example:

• root
  • timestamp
  • snapshot
  • targets (delegates all to claimed, then to recently-claimed)
    • claimed (delegates all with succinct delegation)
      • claimedbin-0001 (delegates specific paths to specific projects with termination)
        • keys-PROJECTA (delegates all to targets-PROJECTA)
          • targets-PROJECTA
      • claimedbin-0002
        • keys-PROJECTB
          • targets-PROJECTB
        • keys-PROJECTC
          • targets-PROJECTC
      • claimedbin-NNNN ...
    • recently-claimed (delegates all with succinct delegation)
      • recentbin-0001 (delegates specific paths to specific projects)
        • keys-PROJECTD (delegates all to targets-PROJECTD)
          • targets-PROJECTD
      • recentbin-NNNN ...

In this example these roles are signed by

• root signed by offline root keys
• timestamp signed by online timestamp key
• snapshot signed by online snapshot key
• targets, claimed, recentlyclaimed and claimedbin-NNNN signed by offline targets keys
• recentbin-NNNN signed by online recent key
• keys-X and targets-X signed by offline or ephemeral maintainer keys