Asfaload Concepts

This document introduces concepts and terminology as used by the Asfaload project.

Individual signature

The signature generated by a user controlling an Asfaload keypair.

Multisig system

A system defining the combination of individual signatures from pre-defined groups of signers, each group specifying a threshold of participants as a completeness criterion.

Aggregate signature

A group of individual signatures in the Asfaload Multisig system. An aggregate signature is pending until its completeness criteria is met, at which time it transition to complete. This completeness criteria is dependent on the group and the operation the aggregate signature is applied to.

Signers file

The signers file is a json document that defines multiple role-based groups of signers, such as artifact_signers, admin_keys, revocation_keys, master_keys. Only the artifact_signers group is mandatory: to enable easy setup in simple environments, there are groups fallbacks if not all of these are defined. Each group has a specific purpose: artifact_signers applies to normal operations (e.g. release signing), while others apply to specific operations.

Groups

Artifact signers

Lists the public keys of the signers authorised and expected to sign an artifact, for example a Github Release. This group is mandatory.

Admin keys

Lists the public keys of signers authorised to update the signers file. Falls back to artifact_signers if absent or empty.

Revocation keys

Lists public keys of signers authorised to revoke an aggregate signature. The aggregate signature can be pending, in which case it cannot be completed anymore, or complete, in which case it is rendered obsolete. Falls back to admin keys if absent.

Master keys

These keys cannot be present in another group, and they are meant to be used in emergency operations when admin keys are not usable. We encourage keeping these keys offline. Optional, but does not fall back to another group if absent.

Trust anchor

When verifying signatures, you need to have an anchor of trust that enables to say: because the persons publishing the signers file have done it at that location, I trust the fact that they control that location. It is similar to Let’s Encrypt trusting the fact that you publishing information on your domain’s website or DNS entry show you are controlling that domain. With Asfaload we have a similar trust anchor: we trust that when you publish a signers file in your Github repository (or any other publishing platform supported), it shows you control that repository. This is because only a person controlling the repository can create a branch and publish a file there.