Project:Infrastructure/OpenPGP keys
Gentoo is using OpenPGP to improve the security of services provided to our users. This document lists the policies regarding maintaining and distributing those keys to users.
Verifying service keys
All keys currently used by Gentoo Infrastructure are listed on the Gentoo website, on Release media signatures subpage. The current recommended verification method is via comparing the key's fingerprint against the one published on website.
Key types
The used keys can be split into two types, affecting the policies used:
- Signing keys are the keys used to sign data (files, commits). The actual signatures are made using a dedicated subkey, and only this subkey needs to be accessible to the automated services. Therefore, the signing subkey is subject to non-secure storage policy (as outlined below), while the relevant primary key is subject to secure storage policy.
- Certification keys are the keys used to sign other keys. To improve security, the keys are split into two layers, and only L2 keys are used in automated services, while L1 keys are only used manually to sign L2 keys. Appropriately, L2 keys are subject to non-secure storage policy, while L1 keys are subject to secure storage policy.
Storage policies
Non-secure storage
Non-secure storage is used with respect to keys that need to be accessed by an automated service without human intervention.
Currently, non-secure storage involves keeping keys unprotected on an Infrastructure server. Therefore, the keys are subject to being compromised if an attacker is able to obtain unauthorized access to the server.
Infrastructure members listed below hold revocation signatures. If there is any risk that the secret portion of the subkey (L2 key) has been compromised, they use them to revoke the relevant subkey (L2 key) ASAP. Afterwards, the primary (L1) key holders can create a replacement subkey (L2 key).
Secure storage
Secure storage is used with respect to keys that are only used manually. The policy aims to reduce the exposition of those keys in order to prevent them from being compromised.
According to the current policy, each primary key (L1 key) is held by two members of the Infrastructure team, in secure (preferably offline) storage. One of those members securely generates the key and sends an encrypted copy over off-the-record media to the other key holder. Key holders are afterwards responsible for creating subkeys (L2 keys), prolonging the keys and generating revocation signatures.
Additionally, Infra members listed below hold revocation signatures for the primary key (L1 key). If there is a valid reason to believe the key has been compromised or both key holders disappear, they can use those signatures to revoke the key. Afterwards, new (or the same) Infra members can generate a new key.
Primary (L1) key holders
The current holders of primary keys are listed in the table below.
| Key | Type | Holder 1 | Holder 2 |
|---|---|---|---|
| Gentoo Linux Release Engineering (Automated Weekly Release Key) | sign | mgorny | robbat2 |
| Gentoo ebuild repository signing key (Automated Signing Key) | sign | mgorny | robbat2 |
| Gentoo repository mirrors (automated git signing key) | sign | mgorny | robbat2 |
| Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) | sign | robbat2 | ? |