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:

  1. Key Y must be signed by key X.
  2. Key Y must be signed by at least 2 keys which are part of the active Debian keyring.
  3. 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.
  4. 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 or is unavailable

  1. Key Y must be signed by an active Debian developer (Bob) whose key is in the keyring.
  2. 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.
  3. 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.
  4. 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 keyring@rt.debian.org, 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. 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-----
    

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.