Proposed procedure for certifying ssh keys

Hello, all:

During the last meeting we talked about establishing the procedure for
certifying ssh keys when granting access to the CTI git repositories. Here's
the procedure I propose we follow:

# Establishing trusted introducers

Members of the CTI will establish who will be the trusted parties to certify
the authenticity of the keys. These members will then hold a video conference
with LF IT to authenticate their own SSH keys, which will be used as "trusted
introducers" for any other ssh keys provided to LF IT.

# Setting up the keyring repository

LF IT will set up a git repository under keyrings/cti that will contain:

- an "allowed-signers" file in the format dictated by ssh-keygen(1) "ALLOWED
  SIGNERS" section, e.g.:

        [email protected] namespaces="git" ssh-rsa AAAAX1...
        [email protected] namespaces="git" ssh-ed25519 AAAAC3N...

- a "revoked-keys" file in the format dictated by ssh-keygen(1) "KEY
  REVOCATION LIST" section, e.g.:

        sha256:cf5PvYZmyAWySqWVvbuSRvve3uXrZblwcSaOU/wNJ68

The only people allowed to push to this repository will be the trusted
introducers from the previous step.

# Procedure for adding new keys to the project

1. New members who need to get access to CTI managed repositories will first
   submit their keys to the trusted introducers (e.g. via a special
   access-requests@ mailing list). The trusted introducers can validate these
   keys via some means established within the CTI community, such as via a
   video call or in person.

2. Once the key is validated with the trusted introducers, one of them will
   add that key to the allowed-signers file and commit that change to the
   keyring repository. The commit should:

   - describe how the identity was verified and by whom
   - provide the link to the key submission message in the archives
   - carry a cryptographic signature on the commit itself (via git commit -S)

3. The new member will then send a request to the CIT helpdesk to request
   access to gitolite (the exact template to be established, and will include
   username selection and gitolite group membership details).

4. Members of LF IT will use the allowed-signers file in the keyring
   repository for the source of the public key data. The signature on the
   commit will not be checked (it's there for repository integrity
   verification purposes) -- being able to push to the repository provides
   sufficient verification of introducer's identity.

5. For group membership and username approval a simple "ack" via email from a
   trusted introducer will be sufficient.

# Procedure for revoking keys from the project

A trusted introducer will remove the key from the allowed-signers file and add
an entry to the revoked-keys file, then follow with a request to the helpesk
to remove repository access.

# Other benefits

The keyring repository can also work as a mechanism to verify git commits in
any of the project's other repositories if git commit verification is properly
configured.

Does that work for everyone?

-K