A request for those attending key signing parties
 

At the most recent Linux.conf.au pgp keysigning, I noticed a number of
Debian developers present. Like me, they had new keys that they offered
up for signing, presumably so they could start replacing their 1024DSA
keys with stronger keys.

If you are signing keys where you've verified the identity of fellow
Debian developers at a key signing party, please do us all a favor and
don't just sign it with your brand-new key --- but *also* sign the DD's
key with whatever key you you currently have currently in the Debian
keyring.

Otherwise, you could end up with a situation where a whole group of DD's
have each other's keys certified, but only signed with their new keys
--- which isn't useful when they are submitting their keys to the Debian
keyring maintainer for inclusion.

What I did was I signed the keys that I verified with *both* my new key
and the key I currently have in the Debian keyring. However, to date,
although I've received key signatures from multiple people whom I know
to be Debian developers, my new key is only signed by one key which is
currently in the debian keyring. (Thanks to Brendan O'Dea!) At the
moment my new 4096 bit RSA key is waiting until I get more signatures,
or some of the new DDs' keys that have signed my key get accepted into
the Debian keyring.

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1PjyoY-0003xV-OQ@tytso-glaptop">http://lists.debian.org/E1PjyoY-0003xV-OQ@tytso-glaptop

A request for those attending key signing parties
 

On Mon, Jan 31, 2011 at 01:49:26PM -0500, Theodore Ts'o wrote:
> If you are signing keys where you've verified the identity of fellow
> Debian developers at a key signing party, please do us all a favor and
> don't just sign it with your brand-new key --- but *also* sign the DD's
> key with whatever key you you currently have currently in the Debian
> keyring.

As I've been recently hit by this gotcha and as a memo for others, note
that if you are using caff, the following is *not* enough to fulfill the
above requirement:

zack@usha:~$ grep keyid .caffrc
$CONFIG{'keyid'} = [ qw{D5CA9B04F2C423BC 9C31503C6D866396} ];

you also need something like:

zack@usha:~$ grep keyid .caffrc
$CONFIG{'local-user'} = [ qw{D5CA9B04F2C423BC 9C31503C6D866396} ];

... or you need to remember passing "-u $KEYID,$OLDKEYID" to caff (yes,
I've defined the two environment variable for the transition period and
they come pretty handy).

Cheers


PS too bad LCA's signing party was at the same time of Tridge's talk :-(

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams

A request for those attending key signing parties
 

Hi,

a more theoretical question quite related to this:

If one plans to have the key replaced in the keyring, and we have a
fellow DD in the keyring who's only trust path to other Debian
Developers goes via that key (this might become a real scenario when we
do a bigger round of key replacements) will that key replacement really
happen? Thus CCing keyring maintainers.

Cheers,
Martin
--
Martin Zobel-Helas <zobel@debian.org> | Debian System Administrator
Debian & GNU/Linux Developer | Debian Listmaster
Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870
GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110131201818.GK13497@ftbfs.de">http://lists.debian.org/20110131201818.GK13497@ftbfs.de

A request for those attending key signing parties
 

On Mon, January 31, 2011 21:18, Martin Zobel-Helas wrote:
> a more theoretical question quite related to this:
>
> If one plans to have the key replaced in the keyring, and we have a
> fellow DD in the keyring who's only trust path to other Debian
> Developers goes via that key (this might become a real scenario when we
> do a bigger round of key replacements) will that key replacement really
> happen? Thus CCing keyring maintainers.

(I'm not a keyring maintainer.)

Currently connectedness has only been used to decide on entry into the
keyring. In a similar scenario, if you are signed by just one DD and that
DD retires from Debian, you are not removed from the keyring, even though
you're no longer connected to other DD's by trust paths. And that is not a
problem, because the process is used to establish identity. Your identity
has been established upon entry, and this fact is not lost when
connectedness of your key is reduced. Thus it's not essential to keep the
keys internally connected.


Cheers,
Thijs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 906938246402b2893e33b381b2fe3747.squirrel@wm.kinkh orst.nl">http://lists.debian.org/906938246402b2893e33b381b2fe3747.squirrel@wm.kinkh orst.nl

A request for those attending key signing parties
 

On Mon, Jan 31, 2011 at 09:18:18PM +0100, Martin Zobel-Helas wrote:
> a more theoretical question quite related to this:
>
> If one plans to have the key replaced in the keyring, and we have a
> fellow DD in the keyring who's only trust path to other Debian
> Developers goes via that key (this might become a real scenario when we
> do a bigger round of key replacements) will that key replacement really
> happen? Thus CCing keyring maintainers.

I've had a few conversations with developers who are known to be the
single path to many DDs about holding off on their key replacements, and
been keeping an eye in general on our connectedness over time. In some
occasions we have pushed back on developers who want to replace their
keys with a minimal number of signatures when their old keys are well
integrated.

Overall the connectedness seems to have stayed about level; in January
2009 we had 89.6% of the keys is in the reachable subset and 84.0% in
the strong subset. By the end of 2010 these numbers had increased to
91.1%/85.2%. Yes, some of that is because we've removed inactive keys,
but I think it's an indicator that (so far) the key replacements have
not been weakening our web of trust.

J.

--
Web [ If I hold really still maybe all of this will just go away. ]
site: http:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.24


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110201173635.GC30815@earth.li">http://lists.debian.org/20110201173635.GC30815@earth.li

A request for those attending key signing parties
 

Martin Zobel-Helas dijo [Mon, Jan 31, 2011 at 09:18:18PM +0100]:
> a more theoretical question quite related to this:
>
> If one plans to have the key replaced in the keyring, and we have a
> fellow DD in the keyring who's only trust path to other Debian
> Developers goes via that key (this might become a real scenario when we
> do a bigger round of key replacements) will that key replacement really
> happen? Thus CCing keyring maintainers.

<hat kind="keyring>
We have requested some people to hold their keys' transition in cases
where the older key had a vast amount of signatures and the new key
didn't. True, we do not check for every key update whether we are
creating islands, and we possibly are - And that's one of the reasons
we often encourage people to get more signatures (i.e. one signature
is too marginal, two or more are strongly encouraged). Of course, it
is not free of controversies - I am not naming specific cases on
public lists, but some people have been cut off from getting a key in
(after having lost access or trust to their previous keys) as they
were in no way connected to the keyring. And that sucks.

Still, I'd welcome additions to our suite telling us any adverse
effects (mainly, the creation of islands) done by a key replacement. I
fear it will be computationally intensive... But worth it. Of course,
assuming we will _not_ block somebody because they fell out of the WoT
(as their identity has already been checked in the past), but just
advising them to get more in contact.
</hat>

Greetings,


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110201183448.GF24832@gwolf.org">http://lists.debian.org/20110201183448.GF24832@gwolf.org