Isn't the "normal" solution path - rather than prune, to revoke keys?
On Fri, Dec 27, 2013 at 4:53 PM, Frederick Miller <[email protected]>wrote: > Please remove me from this email list. Please unsubscribe me. Thanks. > > > On Fri, Dec 27, 2013 at 10:49 AM, Daniel Kahn Gillmor < > [email protected]> wrote: > >> On 12/26/2013 06:18 PM, Nick Kew wrote: >> > You're ahead of us. Individual Apache folks like Jim have taken >> > responsibility and moved to 4096-bit keys, but we haven't as a >> > community had the discussion that might lead to pruning KEYS. >> > My inclination is to say NO to requiring anyone to remove old keys, >> > but YES to encouraging strong keys to sign all releases. >> >> Thanks for considering this, Nick. >> >> At the moment, some of your downstreams have the impression that KEYS >> indicates all of the keys that apache might use to sign releases. For >> example, in http://bugs.debian.org/732450#22 Arno Töll writes: >> >> >> Therefore, I thought a more complete patch would be a keyring which >> >> includes all signatures of people allowed to sign and release code on >> >> behalf of the httpd project. >> >> Maybe you could update the preamble of KEYS to indicate that only strong >> keys (and please clearly define "strong" if y'all are making this >> policy) will be used to sign releases? >> >> Nick again: >> > That may be an issue for some Apache folks. For myself, my newer >> > (4096-bit) key has fewer sigs than my old 1024-bit[1], though not >> > catastrophically so. What is perhaps more of an issue is that hardly >> > any of the signatures on the new key are from Apache folks, as I have >> > (alas) not made it to Apachecon for a couple of years now. Others may >> > have a range of reasons for retaining older keys. >> >> Your 4096-bit key (0x3CE3BAC2EB7BBC624D1D22D8F3B9D88CB87F79A9) appears >> to be certified by nearly 60 other keys -- including at least a couple >> debian developers and Nikos Mavrogiannopolous (the lead GnuTLS >> developer). I can't speak for all of debian, but i think a strong key >> connected by a few paths to other established free software developers >> is more reliable than a weak key connected by dozens of paths. >> >> The keys themselves should not be the weak point in our cryptosystems. >> >> > [1] Key IDs 40581837 and B87F79A9 >> >> (i recommend using full fingerprints instead of keyids if you have to >> communicate about a specific key: >> https://www.debian-administration.org/users/dkg/weblog/105) >> >> Regards, >> >> --dkg >> >> >> >
