[Freedombox-discuss] Follow up to the FreedomBox 'bump/hi-five' challenge
On 06/23/2011 02:46 PM, Stefano Maffulli wrote:
> The updated status of 'we met, we have noted each other's
> identity, we like each other' can be then transmitted [...]
I think it is a mistake to mix "we like each other" into the identity
verification process here.
The crucial thing is to verify *identity*. If i meet someone who i
don't like, as long as i'm sure of who they are, i should be able to use
the same process.
I not need to decide "do i really like this person enough?" to be able
to verify their identity.
And, most importantly, identity certifications should *not* be
misconstrued as a badge of "friendship" or "vouching".
> Jane and Ken run the same app with screen showing a QR code with
> their respective vcards, including the PGP key ID+fingerprint.
> They get their phones close, activate their camera and, in turn,
> scan the other's QR code. After the scan, the app shows the data
> in a human-readable format for confirmation: if confirmed, the
> data goes into the addressbook. Once Jane goes home and connects
> the phone to the FreedomBox in a secure manner (private network?
> cable?), the FreedomBox software greets Jane with a message
> asking her if she wants to sign Ken's PGP key. If she confirms
> it, the key is retrieved from a keyserver and signed with Jane's
> secret key,
Note that the thing being signed here is actually both the Public Key
and the User ID (UID); note also that a given public key can have more
than one User ID, and users are under no obligation to certify all of them.
If you meet me in person, i can prove to you that I am dkg; if i also
happen to have a User ID on my key that says "stefano maffulli", you
probably don't want to certify that User ID.
There are also potentially User Attributes (UAT) associated with each
key -- these are commonly expected to be photos of the keyholder. Jane
should be presented with each UAT independently for certification of
that photo, just like each User ID.
Something as simple as a list of UIDs and UATs, with a checkbox next to
each element (by default un-checked) would be a reasonable first pass at
a GUI.
> the new signature is sent to Ken.
A couple more points of nuance: First, we want ken's key to have a
valid, encryption-capable subkey. That way, we can encrypt our
certifications before sending them to Ken, so that we can confirm that
the address we're sending to is controlled by the same party that
controls the key.
We also want to make sure that for each User ID signed, we send the
signature to the e-mail address associated with that User ID. For User
IDs which do not contain e-mail addresses (and for UATs), it's not clear
what the best thing to do is. Current common practice is to send those
non-addressable certifications to each addressable User ID that is present.
Please see the steps taken by caff (in the signing-party package) for a
difficult UI that ultimately does roughly the right thing.
> Using bluetooth or some other form of wireless communication doesn't
> guarantee from snooping or spoofing, so we better stick to QRcode.
> QRCode also has other advantages: it works if the phones are offline,
> can be printed on business cards, too (not both parties need to have a
> phone), it forces users to be mindful (scan, see the data on your
> screen; instead of 'push a button, something magic happens on the radio
> waves').
yes; note that the device should also probably know about its own key,
so that it can take a picture of a printed business card, and be able to
confirm "yep, that's me!"
> Monkeysign currently displays a qrcode representing your PGP fingerprint
> and it also tries to read the other's fingerprint. The piece that
> manages the key signature protocol is missing. Monkeysign assumes
> internet access as it downloads the key, so the web of trust should just
> propagate through that. The monkeysign's git repository
> git://git.monkeysphere.info/monkeysign holds the python code. I believe
> this can be expanded to cover the use case for laptops and other
> GNU/Linux based mobile devices (Meego comes to mind).
it'd be great to see monkeysign fleshed out to meet this challenge.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110623/85f322f8/attachment-0001.pgp>
Reply to: