Dear all, If you wish to access Arm hardware in the community lab for FD.io<http://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 <hagb...@gmail.com<mailto:hagb...@gmail.com>> Date: March 13, 2018 at 9:11:37 AM PDT To: Andrew Grimberg <agrimb...@linuxfoundation.org<mailto:agrimb...@linuxfoundation.org>> Cc: Vanessa Valderrama <vvalderr...@linuxfoundation.org<mailto:vvalderr...@linuxfoundation.org>>, Tina Tsou <tina.t...@arm.com<mailto:tina.t...@arm.com>>, Brian Brooks <brian.bro...@arm.com<mailto:brian.bro...@arm.com>>, Trishan de Lanerolle <tdelanero...@linuxfoundation.org<mailto:tdelanero...@linuxfoundation.org>> 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 <agrimb...@linuxfoundation.org<mailto:agrimb...@linuxfoundation.org>> 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<http://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<http://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 agrimb...@linuxfoundation.org<mailto:agrimb...@linuxfoundation.org> 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.
