Re: Proposed procedure for certifying ssh keys

"Carlos O'Donell" <[email protected]> Tue, 30 Jan 2024 20:55:10 -0500
Newsgroups org.linuxfoundation.lists.cti-tac
Message-ID <CAEMqeSoE4Y+M-_kL_9eXwcN_H+8aJ3JFVLuKrN=g-TMeWk3zmw@mail.gmail.com>
On Thu, Nov 30, 2023 at 3:05 PM Konstantin Ryabitsev
<[email protected]> 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.:
>
>         [email protected] namespaces="git" ssh-rsa AAAAX1...
>         [email protected] 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.