Dear all,

If you wish to access Arm hardware in the community lab for<> 
work, please join tomorrow’s meeting, with your keys, IDs, webcams ready, you 
will be signed virtual key.

More information how to get ready is below. Thanks Ed and Andy.

Thank you,

Begin forwarded message:

From: Ed Warnicke <<>>
Date: March 13, 2018 at 9:11:37 AM PDT
To: Andrew Grimberg 
Cc: Vanessa Valderrama 
<<>>, Tina 
Tsou <<>>,  Brian Brooks 
<<>>,  Trishan de Lanerolle 
Subject: Re:<> ARM virtual key signing Wed Mar 14 6am PST


Have you prepped the folks for tomorrows ARM call so they show up with their 
keys ready, ids at hand, and webcams blazing? :)


On Thu, Mar 8, 2018 at 6:27 PM Andrew Grimberg 
<<>> 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<> so they can get VPN access to the new 
> gear.  The current plan is to do that at 6am PST Wed Mar 14 on the 
> ARM community webconference:
> 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<>

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).



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.

Reply via email to