Rules for key replacement in the Debian keyring
These are the rules governing what happens if a developer (Alice) wishes to replace her existing key (X) in the Debian keyring with a new key (Y).
When X is still considered secure
In the case where the existing key, X is still trusted, but it is desired to upgrade to a more secure key (e.g. to change to the use of a smartcard stored key, or a greater key length) then the following steps should be followed:
- Key Y must be signed by key X.
- Key Y must be signed by at least 2 keys which are part of the active Debian keyring.
- The request for replacement should be signed by key X but may be signed by any key that is part of the active Debian Developer keyring.
- Key Y should sign at least one key that is part of the active Debian keyring (and ideally at least sign both of the active keys that sign it).
Note that keyring-maint reserve the right to ask a Alice to obtain more signatures if it is deemed the key replacement will weaken the Debian web of trust without sufficient increase in the security of the key.
When X is considered to be compromised, unavailable or no longer trusted
Note that this is the case for keys which have been removed due to being insufficiently strong.
- Key Y must be signed by an active Debian developer (Bob) whose key is in the keyring.
- Alice must get a Debian developer (ideally not Bob) to sign a message requesting the replacement of key X with key Y on behalf of Alice. That statement should contain key fingerprints and Debian login details. This developer must also have performed the appropriate checks to enable them to be comfortable signing key Y.
- If the reason for replacement is 'key X is compromised or no longer valid' then the request for replacement must be accompanied by a revocation certificate for key X.
- If the reason for the replacement is 'key X was lost' then a revocation certificate should be provided if possible.
In both cases requests for key replacement should be sent to email@example.com, include the phrase "Debian RT" in the subject line (as well as something descriptive obviously) and be inline signed as RT will mangle a PGP/MIME signature (more information regarding inline-signing). The reason replacement is required should also be provided.
Please make sure all replacement mails include the full fingerprint information for the old key and the new key (and are clear about which is which). Something like the following:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please replace my old key, 0xkeyid_old: [output of gpg --fingerprint 0xkeyid_old] with the new key, 0xkeyid_new: [output of gpg --fingerprint 0xkeyid_new] as I am moving to a larger, stronger key. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTHOTlAAoJEP8WL8XPP7rR748P/iXW+lG2cwdfiu7B3bXuHcw0 syf1YDEy+pp8+z97+b/V68w/pk7Ei+6IOmn9AlqzZjeOTdPIP/Y5c2NbWL6eBjhx QCUAnrEBjOE2fy2gmMePWt59HraV8cLGA71//QxvRX2+mLjH+jshEhFOB6hTsVCm ZU9H0oGEv6pT3z+c5LY42nsOhbiGUXRl3e/I5if54ljIOwwgTMvakWxL19SSOrCR Sjq55uPEE92NNoi2iS8VgAmpc33B2AbS81zpPJb3UUxQxZ9feeZFwFOeolebXx0+ hOBdxDgdTG7pFgDxIjgy82bIIWjzxcNwoPIJG90WSdI/wkX7OMph9f6e6AIqXOyn s9hZ7j2mTIvS6kkdz2ttHQSAyemlpTavPvMX5RxFzVBDf5Ttq89jwFpqjfOfUy3z jGLF7Y+BymPjCr277gIa1JRgBUXa0W3Ahdp21h1Q0poYgM7M93DX7yV/YOfXIcvT r8Mprt5aJOXa04ypoGN0HwVve2aXB/d8IK3M/DuWStmrSqTJ73NQQzanR3CnbcHn sbxzGGoBkBXHrMcRIJxQtytn20bQRoTslTHlcH/JPh6eqSQpgpwoWgDae77Dm3ye mV+b3YAtwcm3I4wD+VVBw4JWd3IzQTkZwHireTABvSrpff631jD746L9Ct1h4tuR /5qsAyl6p3/oeeSO4Dcc =0Kb3 -----END PGP SIGNATURE-----
Make sure your message is signed by your old key, as it is the only one we "know" so far and we can trust. You can sign your mail with gpg --default-key $oldkey --clearsign filename
There is no need to include a copy of the new key but you should ensure it's available on the keyserver network.
NB:The procedures above cover the case where a key is being entirely replaced. If a key is merely being modified (e.g. expiry date updated or additional subkeys/uids being added) then it should be submitted to the HKP keyserver running on keyring.debian.org, and will be folded into the keyring during the next update cycle.