On Wed, Sep 07, 2022 at 11:58:29AM +0200, Hans Verkuil wrote: > On 07/09/2022 11:51, Laurent Pinchart wrote: > > On Wed, Sep 07, 2022 at 08:51:48AM +0200, Hans Verkuil wrote: > >> On 05/09/2022 16:44, Laurent Pinchart wrote: > >>> On Mon, Sep 05, 2022 at 01:41:11PM +0000, Sakari Ailus wrote: > >>>> On Tue, Aug 23, 2022 at 12:53:44PM +0200, Hans Verkuil wrote: > >>>>> 16:45-18:00 Anything else? > >>>> > >>>> I think it'd be great to have a GPG key signing party at the end of the > >>>> meeting. > >>> > >>> It's a good idea. Could everybody please send their GPG key fingerprint > >>> in an e-mail reply to prepare for that ? It can easily be retrieved with > >>> 'gpg -K' (make sure to pick the right key if you have multiple of them). > >>> I'll start: > >>> > >>> sec rsa4096/0xF045C2B96991256E 2014-10-09 [C] > >>> 94231B980100EC619AC10E10F045C2B96991256E > >>> uid [ultimate] Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > >>> > >>> If you're generating a key for the occasion, create a primary key with > >>> the Certify (C) capability only, and create separate sub-keys for > >>> Signature (S) and Encryption (E). There's little reason these days to > >>> use less than 4096 bits for the primary key if you opt for RSA. The > >>> subkeys should have an expiration date. > >>> > >>> The primary key can then be moved to safe storage, you will only need > >>> the subkeys for daily usage. The primary key will be used only to > >>> create new subkeys and to sign other people's keys. > >>> > >> > >> Can you also give instructions on what to do at the key signing party? > >> > >> I do this so rarely that I always forget what magic gpg commands I need > >> to make to sign keys. > >> > >> If everyone has this information at hand, then we can quickly proceed with > >> this on Monday. > > > > Good point. > > > > First of all, everybody should make sure that their key is published on > > key servers. > > Which key servers? That's never been clear to me: which key server(s) are > you supposed to use? They are supposed to mirror each other, so any of the main ones should do. hkp://keys.gnupg.net, hkp://pgp.mit.edu, hkps://keys.openpgp.org, hkp://keyserver.ubuntu.com, ... > > I will gather al the keys and print a list that I will hand out to > > everybody on Monday. This will be the authoritative source of > > information, as anything stored in digital form could theoritically be > > tampered with. > > > > We will go around the table, and everybody will check that their key ID > > matches the printed documented (to make sure I haven't tampered with the > > printed version they have received), and read it out loud for everybody > > to compare with their own printed version (to make sure I've distributed > > the same version to everybody). If any mismatch is noticed, people are > > expected to shout out loud. > > > > Then we will verify identities. If we have a laptop with a webcam that > > can be hooked up to a projector, we can simply take turns and show a > > government-issues ID that clearly displays our name, for people in the > > room to compare that with the keys. Once the fingerprints and the > > identities are checked, the corresponding keys should be marked as > > verified on the paper version. > > > > The next step is to sign keys. This is something that will happen after > > the media summit, and if you have your master key on offline storage, > > will happen after you get back home. You will need to download keys from > > key servers, verify that the fingerprints match the paper version and > > sign the keys. > > > > The final step is to publish signatures. I'll try to check what the > > latest best practices are. One option is to simply publish the > > signatures to key servers, but we can also mail them to the key owner, > > in an encrypted e-mail to make sure the recipient is the intended > > person. -- Regards, Laurent Pinchart
