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, unavailable or no longer trusted

Note that this is the case for keys which have been removed due to being insufficiently strong.

  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, 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:

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. 
Version: GnuPG v1.4.12 (GNU/Linux)


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, and will be folded into the keyring during the next update cycle.