Design for contact handling for encryption/authentication support

[conradoplg]

Context: the encryption&authentication itself was designed here, but the requirement of registering other people's public key ripples through all the solution.

In the design below I created a frost-client tool which will handle most of the things; we could also extend it to incorporate the trusted-dealer, dkg, participant and coordinator tools as subcommands.

These are a bit rough and might need cleanup.

Design

Assumptions

• Each participant will need a "comms key pair" to authenticate communications
  with other participants.
• Each participant will download other participant's public keys out-of-band
  (or download in-band and verify fingerprint out-of-band).
• It should be possible for a participant to use different public keys for
  different groups if they wish (to be confirmed). (Otherwise they
  can be linked across groups)
• User registration should be optional (to be confirmed).
• Password usage should be optional and the comms key pair could be used for
  authentication (to be confirmed)
• Usernames are specific to server instances
• Comm pubkeys can be reused across servers

Server goals

The FROST server has the following goals:

• Allowing people to communicate which each other. This is the main goal.
  This can be done without user registration, by creating a session with a list
  of public keys, and by either sharing the session ID out-of-band, or by
  allowing getting the list of sessions you're in (which will require authentication
  by key pair).
  • Managing user registration. This might make it easier to create sessions
    (pass a list of users instead of pubkeys) and easier to get sessions you're
    in (authenticate with the password and get the list of sessions linked to
    the user).

This means that are 3 possible ways to use the server:

• Without authenticating with the server. Requires sharing session ID out-of-band.
• Authenticating with comms key pair.
• Authenticating with username/password.

Design

Inspired by cargo login, which authenticates with a server and saves
authentication token to $CARGO_HOME/credentials.toml.

In this case, information will be stored in $HOME/.frost/credentials.toml
which I'll refer to as "config".

• frost-client init [--username USERNAME] [--server-url SERVER_URl]
  • Creates a key pair, saves to config.
  • If USERNAME & SERVER_URL where specified, prompts for password, and
    registers user in the server. Saves USERNAME in the config, in a map keyed
    by SERVER_URL.
  • Different key pairs could be supported by simply pointing to a different
    config file via a new flag? (TODO: decide)
• frost-client login --username USERNAME --server-url SERVER_URl
  • Prompts for password and logs in to the server, saving authentication token
    in the config, in the same map keyed by SERVER_URL.
  • Keypair-authentication could be done by omitting username, and adding a new
    authentication mechanism to the server.
• frost-client export --name NAME [--server-url] SERVER_URL
  • Exports (by printing an encoded string, the "contact") the user's pubkey
    along with the (text) NAME specified, and the username associated with the
    given server-url, if any.
  • Should NAME be registered in init instead? (TODO: decide)
• frost-client import CONTACT
  • Imports the contact, which will save: name, pubkey, and possibly server-url
    and username
• frost-client contacts
  • Prints contact list, to make it easier to pick contacts for other commands
• frost-client dkg [--users USERS] [--pubkeys PUBKEYS] [...more DKG params]
  • Runs DKG for the given participants. USERs will use regular
    username/password auth, while PUBKEYS will allow keypair auth.
  • When it finishes, it saves group data (KeyPackage, PublicKeyPackage,
    USERS/PUBKEYS->identifier mapping)
  • We can derive identifier from username or pubkey. Otherwise, if identifier
    should be freely chosen, then participants will be required to send them
    when starting the process.
• frost-client groups
  • Print group list, to make it easier to pick groups for other commands
• participant or coordinator:
  • Will require somehow selecting which group to use (how to identify groups?
    Use a group name? Or simply the group public key?)
  • Like dkg could use USERs os PUBKEYs