[Discuss] privacy with pgp keys

[abreauj at gmail.com (John Abreau)]

The process we use at the BLU keysignings is as follows, and with less than
a week before the meeting, there's not enough time to revise and debug a
new process, so for this year's keysigning party, we'll be sticking with
this process.

1. Participants enter their keyid on the registration page on the BLU
webserver
2. The script on the BLU webserver fetches the key with that keyid from the
keyserver "pgp.mit.edu" and adds it to the local keyring on the BLU
webserver
3. On the afternoon of the keysigning party, a volunteer creates an
official checksheet from the keyring and prints 30 copies to bring to the
meeting.
4. At the meeting, we start with a process that allows each participant to
verify that their copy of the checksheet is valid, and then we follow that
with a process where each participant personally examines all other
participants' photo ids.
5. Each participant leaves the meeting with their own copy of the
checksheet that they have personally verified, which they can refer to
after the meeting when they're ready to sign the keys that they're
confident are valid. We provide a shell script to simplify the keysigning
process; the script retrieves each key from the keyserver "pgp.mit.edu",
signs and encrypts the key with itself so that only the owner of that key
can retrieve the signature, and generates a shell script to email each key
to all email addresses found in the key.

To verify the checksheets, the Keymaster reads down the list of
participants on the checksheet, and each participant in turn confirm that
they are present, then reads aloud their keyid and fingerprint (from their
own source, not from the checksheet), and everyone else verifies that the
keyid and fingerprint on their copy of the checksheet matches what is being
read aloud.

If anyone on the list is not present, everyone should cross them off the
list and not sign their key later.

If anyone discovers that their copy of the checksheet is invalid, they
should speak up. This has never occurred yet in our keysigning parties, but
in principle it's a necessary step for detecting efforts to do something
nefarious.

To verify photo ids, all participants line up in two rows facing each
other, in the order that they appear on the checksheet. Each facing pair
examines each other's photo ids and confirms that they match the
corresponding name on the checksheet. Then everyone moves to the side to
face the next participant, and repeat until each participant has verified
everyone else's photo ids.

Without a valid name and email address in the copy of the key on the
keyserver, this process won't work.




On Thu, Sep 10, 2015 at 4:23 PM, Mayuresh Rajwadkar <m.m.rajwadkar at ieee.org>
wrote:

> hi
>
> http://pgp.mit.edu/pks/lookup?search=b5d1f0f4&op=index
>
> That uploaded key as a MD5 and SHA224 of the ID aka email...
> One can verify that the email and fingerprint I provide will match up to
> those hashes..
> Its not entirely impossible...
>
> I do appreciate Derek's concern...
>
> In my example I have used a UUID, which is the ultimate but one can use a
> FirstName/LastName
> which can be a little bit liberal, than providing an email address,
> embedding a thumb-print jpeg, or
> a IRIS-scan jpeg, or providing some kind of  DNA fingerprint/sequence would
> be kind a overly  liberal  ? than
> just an email address, which is also possible... if privacy is no
> concern...
>
> Mayuresh
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 10, 2015 at 1:30 PM, Derek Martin <invalid at pizzashack.org>
> wrote:
>
> > On Thu, Sep 10, 2015 at 12:52:55PM -0400, John Abreau wrote:
> > > If a key has been stripped of all traces of the owner's identity, I
> don't
> > > see how it would be possible to adequately verify trust of that key
> > during
> > > the keysigning party.
> >
> > Or when you are sending them e-mail.  Or at any other time.  Positive
> > identification of the recipient is generally part of what is required,
> > so that you do not, say, encrypt company secrets to your competitor,
> > instead of your coworker, for example.
> >
> > --
> > Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
> > -=-=-=-=-
> > This message is posted from an invalid address.  Replying to it will
> > result in
> > undeliverable mail due to spam prevention.  Sorry for the inconvenience.
> >
> >
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6