On Sun, 23 Feb 2014, Jonathan McDowell wrote: > On Sun, Feb 23, 2014 at 12:49:37PM -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 23 Feb 2014, Jonathan McDowell wrote: > > > * Requests need to include the full fingerprint of both the old and the > > > new key. Not just the key IDs. Not just the new key. We want to be > > > absolutely certain of what you're requesting replaced. I quite like > > > seeing the actual "gpg --fingerprint" output for both keys because it > > > tends to be quite easy to visually verify. > > > > > > * The new key must be signed by the old key that is being replaced. > > > > > > * The new key must be signed by 2 other keys that are present in the > > > Debian keyring. > > > > > > * The request must be signed by the old key. Signing the request with > > > the new key alone is not helpful - requests must always be signed by > > > a key that is currently in the active keyring. Signing it with both > > > is fine, but not required. > > > > > > * You should specify *why* you want to replace your key. Knowing that > > > it's because you're moving to a stronger key rather than because your > > > old key is compromised / unavailable / on fire helps us prioritise > > > things. > > > > This is not what is written here: > > http://keyring.debian.org/replacing_keys.html > > > > Please update that page. In particular, it *requires* a third party to > > request the key swap on your behalf. > > Paragraph 2 on that page states: > > | 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.
Hmm, ideed it does! My bad, I apologise. > What would you suggest as alternative wording which is clearer? Well, since I did read that page three times in separate days and failed to properly parse it, it does look like it might benefit from being a bit more clear [1]. I suggest breaking the page into two separate sections, one for each main use case: 1. Key replacement protocol to use when the original key was NOT lost/compromised/revoked/destroyed and can still be used. 2. Key replacement protocol to use when the original key *WAS* lost/compromised/revoked/destroyed and should not/cannot be used anymore. I'd also drop any language that discourages key replacements and upgrades. We *want* to get people to replace their keys more often than once every 15 years, and it is better for everyone if proper key expirity is used so that cruft in the public keyring ends up expiring eventually. Maybe we want to keep discouraging main key replacement "just because it expired", but it should be clear that only applies if the key is recent (less than two years old, IMHO). We certaily don't want to make it look like key expirity is a bad thing. Also, IMHO we do want subkeys to expire (and get replaced) a lot more often as that doesn't require expensive human oversight (IMHO subkeys should be replaced at least once every two years, and I'd prefer to do have them expire in 2 years, with the rollover done a few months after the one-year mark)[2]. [1] That paragrah does everything you must never do when trying for text clarity: it is a paragraph with an absolute/extremely strong key (first) sentence, has dense text, and a last sentence that contradicts the key sentence through a weak conditional -- it is no wonder some people will fail to grasp the desired idea unless they're paying a _lot_ of attention and reading very slowly. [2] subkey rollover is damn easy and automated: generate new subkeys, and upload the key (which should still have the old set of subkeys as well as the new set of subkeys) to the Debian keyserver and to the public keyserver network. Do that at least three months before the old set of subkeys will expire. NEVER remove the old subkeys from your own keys, even after they expired, unless you *really* know what you're doing (and always keep backups). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224014533.ga8...@khazad-dum.debian.net