If you could reply to me privately with your: (name, GPG fingerprint) that would greatly expedite the key signing today at 6am PST. Please note, I *will* have to verify your ID/fingerprint on the call, but having it in front of my as a reference helps tremendously expedite the process.
Ed On Tue, Mar 13, 2018 at 11:23 AM Tina Tsou <[email protected]> wrote: > Dear all, > > If you wish to access Arm hardware in the community lab for FD.io work, > please join tomorrow’s meeting, with your keys, IDs, webcams ready, you > will be signed virtual key. > > https://wiki.fd.io/view/VPP/AArch64 > > https://zoom.us/j/5301185804 > > > More information how to get ready is below. Thanks Ed and Andy. > > > Thank you, > Tina > > Begin forwarded message: > > *From:* Ed Warnicke <[email protected]> > *Date:* March 13, 2018 at 9:11:37 AM PDT > *To:* Andrew Grimberg <[email protected]> > *Cc:* Vanessa Valderrama <[email protected]>, Tina Tsou < > [email protected]>, Brian Brooks <[email protected]>, Trishan de > Lanerolle <[email protected]> > *Subject:* *Re: FD.io <http://FD.io> ARM virtual key signing Wed Mar 14 > 6am PST* > > Tina, > > Have you prepped the folks for tomorrows ARM call so they show up with > their keys ready, ids at hand, and webcams blazing? :) > > Ed > > On Thu, Mar 8, 2018 at 6:27 PM Andrew Grimberg < > [email protected]> wrote: > >> On 03/07/2018 03:24 PM, Ed Warnicke wrote: >> > Andy, >> > As we discussed on IM, we need to do a virtual keysigning for the >> > ARM subcommunity at FD.io so they can get VPN access to the new ARM >> > gear. The current plan is to do that at 6am PST Wed Mar 14 on the >> FD.io >> > ARM community webconference: >> > >> > https://wiki.fd.io/view/VPP/AArch64#Meeting_Details >> > >> > Could you: >> > a) Provide a pointer to documentation of how to do so (how to prep etc) >> > b) If convenient, come to the keysigning... its just not a keysigning >> > without you :) >> >> Ok, I may (or may not) be able to attend due to timing constraints on >> me. Feel free to send this mail on to whomever needs it. >> >> First let me point everyone to an excellent series [0] our resident >> security director has been writing on protecting code integrity using >> PGP. He's (currently) up to 4 parts and it sounds like a 5th (and maybea >> 6th?) is in the offing. Which, given where the series is coming from is >> likely true. The source document is here [1] if you want to read ahead ;) >> >> That series basically goes over the intro to the PGP Web of Trust (WoT) >> concepts and how to generate keys, move them to smart card devices (if >> you so desire) and how to use them with git. For a more in depth look at >> how the WoT actually functions see his much older article series (which >> he sadly never finished for reasons) here [2]. >> >> With that out of the way I will now assume people have keys and are >> ready to do a keysigning :) normally we do these sort of things in >> person and there's a major lead time component / pre-documentation step >> that is needed. However, virtual signings tend to be a little >> more....loose, I know this because we do one anytime we hire a new >> member of our systems administration, release engineering, or helpdesk >> teams here at The Linux Foundation. The basics for a virtual signing are >> as follows: >> >> 1) Have your key ready ;) >> >> 2) Have your key published to a key server that is part of the overall >> keyserver mesh. No, having a key on keybase isn't the best as it doesn't >> participate in the mesh. Having your key there is just useful for other >> things :D >> >> 3) Have a form of valid identification: >> >> a) Two forms of valid identification available (drivers license, >> passport basically some method of getting to 100 points according to >> this [3] Wikipedia article (yes that's information related to Australia >> as they're the ones that came up with this very useful metric). I >> normally use my current passport and drivers license. >> >> b) Alternative to 100 points documents. Have someone that people trust >> vouch for you. The problem here is that everyone would have to agree >> that said party vouching for you is a good form of trust ;) >> >> 4) Have a webcam for your virtual signing. You cannot participate if >> people cannot see you. Yes, video feeds can be faked, but still, it's >> required :P >> >> During your virtual signing >> 5) Provide the short and/or full keygrip of your key into your video >> conference chat channel (after all participants have joined!!!!) >> >> 6) Wait for everyone to retrieve the key(s) from the keyservers >> >> 7) For each person that is needing to have their key signed they will do >> the following: >> >> a) State their full name (as on the key being signed) >> >> b) Provide to the camera their forms of identification that in some way >> connect said name to said person and the key(s) in question. Give enough >> time for participants to look over the material (15 - 30 seconds is >> generally enough per article) Be willing to re-display if so asked. >> >> c) They will then _READ_ their entire fingerprint that they have locally >> and did not just download from the keyserver mesh. It's best if they can >> do it phonetically ex: >> >> My keygrip is 3360FFB703A9DA1F with a fingerprint of: >> FA4D B93E B903 4BBF B853 2A26 3360 FFB7 03A9 DA1F >> >> Obtained as follows from my GPG keyring: >> >> gpg --fingerprint [email protected] >> >> I would proceed to read that to everyone as follows: >> >> Foxtrot Alpha Four Delta... >> >> d) Participants will validate that the key that they acquired from the >> keyserver mesh is the same one as the signee has read. They are now free >> to sign the key and set any sort of trust that they wish on it. >> >> 8) Participants will do one of the following for the getting their >> signatures back in the keyserver mesh >> >> a) Sign the keys that were validated in step 7 and just push back to the >> mesh (gpg --send-keys $KEYGRIP) >> >> b) Use a utility like the Debian caff (CA Fire and Forget) application >> (pgp-tools on RedHat based distros as opposed to singing-party on Debian >> based distros) to appropriately do the signing and send an encrypted >> email to the signee to have _them_ upload the signatures. >> >> Personally I generally use option 8.b as it ensures that anyone that has >> my signature on their key in the mesh knows how to (or at least knew how >> to) deal with encrypted email which, to be honest is the whole point of >> y'all wanting / needing this signing party and not the code integrity >> reason that I previously linked you too! >> >> It's much less entertaining than the hockey-pokey that you may have >> heard Ed talk about for the initial OpenDaylight keysigning that I ran ;) >> >> One thing I'll note. We here at LF use this particular method >> semi-regularly (as I already stated) we do so out of necessity given >> that we're a distributed work force. Our _preference_ is for an in >> person keysigning. Either just single parties, or like we did when we >> first brought our internal WoT online, a more formal in person meeting >> with over 50% of the team present. >> >> Procedures for doing something like that are more stringent on the >> lead-up but they have a much higher certainty of being _true_ (or truer) >> validations of identity. >> >> Please let me know if there is any sort of clarification that is needed. >> If at all possible I will join the meeting and can run cat herder for it >> as I've done it numerous times, but I'm very much time boxed that >> morning and if there are a lot of participants and I'm running it I may >> have to hand the reigns over to someone else to finish if it's getting >> close to my required drop time. >> >> Before you ask, why do we require the signee to read their key to >> everyone the basic reason is that we want them to verbally acknowledge >> the key that they are requesting people to sign. The best method of this >> is to have them to a) not be downloading it from the keymesh and b) read >> the fingerprint out. For very large gatherings this does not work very >> well and there are alternative methods that require more setup and >> coordination (see reference to my comment about more stringent lead-up >> for in person parties). >> >> -Andy- >> >> [0] >> >> https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-4-moving-your-master-key-offline-storage >> [1] >> https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md >> [2] >> >> https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication >> [3] https://en.wikipedia.org/wiki/100_point_check >> >> -- >> Andrew J Grimberg >> Lead, IT Release Engineering >> The Linux Foundation >> >> IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > >
