On 07/09/2022 12:06, Laurent Pinchart wrote: > 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, ... Well, hkp://keys.gnupg.net for one is dead, it no longer exists. The other three are still alive. keys.openpgp.org and keyserver.ubuntu.com do find my keys, but pgp.mit.edu doesn't appear to have it. In fact, I can't find your key there either. That suggests that that one doesn't mirror from others. So the only two that appear to be reliable are hkps://keys.openpgp.org and hkp://keyserver.ubuntu.com. Regards, Hans > >>> 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. >
