On 05/10/2009 10:42 PM, Paul Wise wrote: > On Sun, May 10, 2009 at 6:27 PM, Salvatore Bonaccorso > <salvatore.bonaccorso@gmail.com> wrote: > >> My GnuPG key 518DA394 is signed by the Debian Developers: > > 0x518DA394 is a 1024-bit DSA key, you might want to switch to a new key: > > http://www.debian-administration.org/users/dkg/weblog/48 As the author of this blog post (and as a DM, and as someone currently in NM), i'd certainly be happy if new DMs (and those in process) would consider it. It'll put us all in a better position should SHA-1 become more severely compromised. But it shouldn't be any sort of binding requirement unless we're willing to go through the usual policy procedure, so that reasonable people have a chance to discuss the requirements. We haven't seen anything like a specific, demonstrated attack against our infrastructure, and rushing into a requirement without discussion seems just as likely to end up with poor requirements as it does more robust infrastructure. Since the DM process has a mandatory 1-year renewal period (the "DM ping"), any change in policy could take effect in a relatively short time anyway. So Salvatore, please consider the recommendations, but also feel free to continue on the DM process (i believe you still need an advocate) with the key you have (since it's already signed by two DDs), and consider having a new key available before you get the chance to meet up with any other DDs, so that you can have a stronger key in the DM keyring when you get a chance. > In addition, you may want to set a key expiry date. I agree that reasonable adoption of key expiry is a minorly useful way to stay on top of managing your digital identity, in particular to protect it against an infinitely-valid-yet-unusable key in the event of major hardware failure with no revocation certificate available. However, due to the fact that a malicious keyholder can always extend the expiration date, expiry doesn't do much against compromised keys. Holding a revocation certificate in reserve is really the Right Way to implement such a "kill switch" against a potentially-compromised key, but i see no way to ensure that people do that responsibly without just asking them if they have such a rev cert available and believing their answer. And for the purposes of becoming a DM, i think an expiration date (while advisable) should not be required because we already have the (stronger) "DM ping" requirement. --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature