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).
NB: Key expiry (by itself) is never a reason to replace a key - instead just change the expiry time on the existent key. See gpg --edit-key and then just submit the updated key to the keyserver as normal.
- 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 key X is still valid then Alice may sign the request using that key, but must ensure key Y is signed by key X as well as at least 2 other active Debian developers whose keys are in the keyring.
- 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.
- If the reason is 'I wanted a new key' then the new key must be strictly more secure than the old key and 'reasonably' connected where 'reasonably' is left up to keyring-maint and varies depending on the circumstances of the developer in question.
- Anything else is at keyring-maint's discretion and, in general, arbitrary key replacements without good cause will be rejected.
Requests for key replacement should be sent to firstname.lastname@example.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). There is no need to include a copy of the new key but you should ensure it's available on the keyserver network.