Proposed procedure for certifying ssh keys

Proposed procedure for certifying ssh keys

[Konstantin Ryabitsev]

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.:

        contributor@example.com namespaces="git" ssh-rsa AAAAX1...
        contributor2@example.net 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

Re: Proposed procedure for certifying ssh keys

[Carlos O'Donell]

On Thu, Nov 30, 2023 at 3:05 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> 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:

My apologies for the delay in review.

> # 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.

I agree with this concept.

There is no way I know to bootstrap without an initial web of trust.

In general I would say that ALL of the TAC members are well
established enough to be trusted parties to certify authenticity.

At a minimum bootstrap I'd say Joseph Myers, David Edelsohn, Siddhesh
Poyarekar and myself would work.

It would be very hard to forge our interactions online in a video conference.

> # 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.:
>
>         contributor@example.com namespaces="git" ssh-rsa AAAAX1...
>         contributor2@example.net namespaces="git" ssh-ed25519 AAAAC3N...

OK. So after the meeting we double check this matches the notes we
took in the meeting?

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

OK. So we follow this for off-boarding TAC members.

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

How do we onboard and offboard trusted introducers?

> # 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.

OK.

> 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)

OK.

> 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).

I assume you mean LF helpdesk here?

> 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.

OK. Agreed.

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

OK. Agreed, since the key addition by the trusted introducer allows
this access anyway.

> # 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.

OK.

> # 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?

In general this works for me.

I would like there to be a further description of how we onboard and offboard
trusted introducers using the existing trusted introducers.

We have a CTI TAC meeting tomorrow at 11am EDT, which we could use to
discuss the process. I'll raise all of these items there.

Cheers,
Carlos.