Re: State of the debian keyring
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
Reply to: