Key management

[trishankatdatadog]

Key management in TUF

There are five design principles for key management in TUF that we believe would be useful in a wide variety of use cases in Notary v2.

Separation of duties

The first principle is the separation of duties, or using different sets of keys to sign different sets of metadata. The notion of a role, whether man or machine, is used to distinguish between different sets of keys. This ensures that a compromise of a set of keys belonging to any one role is generally insufficient to compromise the security of the entire system.

Notary v1 has already implemented this principle.

Threshold signatures

The second principle is allowing for threshold signatures, or m out of n keys, to sign any piece of metadata. This is so that a compromise of less than m keys is insufficient to cause false metadata to be signed.

Notary v1 has already implemented this principle.

Diversity of cryptographic algorithms

The third principle is allowing for using a diversity of cryptographic hashing and signing algorithms at the same time. This is so that a compromise of any signing or hashing algorithm is insufficient to cause false metadata to be trusted.

Notary v1 has somewhat implemented this principle. RSA, ECDSA and Ed25519 signatures are allowed, but hashes appear to be limited to SHA2-256.

Built-in key revocation

The fourth principle is building key rotation and revocation into the system. Keys will inevitably be lost or somehow compromised (e.g., reverse-engineered or stolen), and so there needs to be a way to revoke these keys and replace them with new ones. There are two ways to revoke keys in TUF: explicitly (using old keys to sign for new keys in new pieces of metadata) and implicitly (setting expiration timestamps on pieces of metadata so that keys are not necessarily trusted indefinitely).

Notary v1 has already implemented this principle.

Delegations: built-in decentralized key distribution

Last but not least, the fifth principle is not usually explicitly discussed, but is nevertheless crucial to the scaling of key distribution, rotation, and revocation in the system.

The use of delegations is a powerful strategy that has successfully been used in a variety of contexts, including distributed systems, role-based access control, and software repositories. In the context of software repositories, delegations are specifically used to distribute permissions to sign packages across different administrators and developers. If A can sign a package K, then A can delegate this permission to B so that B can sign K on behalf of A. The delegation is an indirect package signature, where B "speaks for" A about K.

Consider the following example discussed in the Diplomat paper. In the figure above, there is a "projects" role may sign packages because it is the root of trust for all packages. However, it has instead delegated the Django project (or the package path Django-*) to the public keys belonging to the developer Alice. Similarly, the Scapy project has been delegated to Sue. A delegation is simply a trusted map of which developer keys are responsible for signing which projects (or sets of packages). Based on this delegation, users would trust only Alice’s signature on a Django package. Developers can further delegate entrusted packages to other developers. In this case, Alice has delegated some packages (any package matching the path Django-*.tar.gz) to the developer Bob. Thus, Bob speaks for Alice for only the Django-*.tar.gz packages, whereas Alice’s signature on Django-1.7.1.exe (not shown) would be trusted instead of Bob’s.

Although Notary v1 has implemented some notion of delegations, it has unfortunately not implemented it in a way that matches the TUF semantics. The semantics of delegations in Notary v1 is not rich enough to capture the semantics of delegations in TUF which are needed for some security use cases, such as the one needed for CNAB. In particular, we will need both:

1. Prioritized delegations, where delegations are listed and searched in listed order of decreasing priority. While delegations are prioritized in Notary v1, the semantics appears to use a breadth-first search instead of a pre-order depth-first search, which means changing security models between Notary and other TUF implementations.
2. Terminating delegations, wherein clients are instructed to terminate the search when a particular delegation has not signed for a target. Notary v1 does not appear to support these, which means that some security models cannot be implemented.

[justincormack]

Factual correction, Notary v1 supports RSA, ECDSA and ed25519.

This does not cover keys being online or offline, nor how public keys are managed and disseminated.

[SteveLasker]

Moving to a discussion to capture the info, while enabling closure and cleanup of active issues.