On 06/23/2011 08:58 PM, [email protected] wrote: > I think this is perfectly reasonable. My reason for going back to the nonce > is, while qr codes can hold an unsigned 2048 bit public key, the qr code will > be unwieldy and hard to photograph. Extra onscreen verifiable information is > great, I just want to prevent huge qr codes if possible since I've had > trouble with those.
sure. i think if both parties share some other local means of
communication, the QRCode could be as simple as containing the following
three items:
0) an OpenPGP key fingerprint or message digest for all offered info
1) a (list of) local address(es) of where to fetch the offered info
2) an ephemeral symmetric encryption key (and a specification of the
symmetric algorithm, padding form, and mode used, if we can't settle on
a single standard)
However, if we don't want to assume that the alternate communications
mechanisms are present, we might also want to include the standard
vcard-type info as well (so various fallback forms, including offline
checks, etc, can be done later by the user).
Yes, a less-dense QRcode is ultimately easier to reliably display and
scan; however, having to show one simple QR code, then find that the
devices can't actually exchange data via these other mechanisms, then
trying again with a denser QR-code doesn't sound like it would be very
fun from the usability side of things.
I suggest we focus on the simple, universal usability case first: a
VCard-type set of data with the OpenPGP fingerprint.
Then, if someone wants to work on extending that to include local
large-data-transmission (optionally with an ephemeral session key),
that'd be lovely.
But let's start with the simple case first: a device with a camera and a
connection to the upstream internet (which includes keyservers) and work
from there.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
