From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: cti-tac@lists.linuxfoundation.org
Subject: Proposed procedure for certifying ssh keys
Date: Thu, 30 Nov 2023 14:56:51 -0500 [thread overview]
Message-ID: <20231130-hopping-innocent-labrador-40d2ab@nitro> (raw)
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
next reply other threads:[~2023-11-30 19:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 19:56 Konstantin Ryabitsev [this message]
2024-01-31 1:55 ` Proposed procedure for certifying ssh keys Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231130-hopping-innocent-labrador-40d2ab@nitro \
--to=konstantin@linuxfoundation.org \
--cc=cti-tac@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).