On 27 April 2015 at 15:49, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> wrote:
The idea is that when someone is typing in the fingerprint, the client
can perform a parity check to see if the fingerprint data is correct
as the user is typing rather than waiting to the end.
This is getting pretty far into usability. Which I don't think is
bad, but it's just a bunch of assumptions that weren't unpacked right
away, and ignores alternatives.
There are lots of ways to compare fingerprints, some of which will not
work in the situation at hand. Goals of any fingerprint comparison
mechanism should be to reduce the level of effort required by the
user, and reduce the sharp edges of failure situations.
Some (most?) of the situations one will encounter:
a) Comparing two fingerprints that are on the same desktop computer
b) Comparing two fingerprints that are on the same mobile device
c) Comparing a fingerprint between a desktop and mobile (in either direction)
d) Comparing a fingerprint between a desktop and paper
e) Comparing a fingerprint between a mobile device and paper
(Technically, I really mean 'desktop' to mean 'any computer without a
webcam' and mobile device to mean 'any computer with a camera'. So
replace 'mobile' with 'laptop' in many instances.)
I think QR codes are excellent comparison mechanisms. Look at
situations (c) and (e). Desktop (or paper) displays a QR code, Mobile
reads the QR code and says 'They match!' What's a less user-effort
level and less error-prone mechanism?
For situation (a), I would say the answer should be 'copy-and-paste'.
I envision a key verification UI as saying (below the displayed QR
code) a text box with a label "Or paste the fingerprint beginnging
with WXYZ here:". You paste it, if it matches, you're set.
For (b).... mobile copy and paste sucks. Fortunately, I'm struggling
to come up with a feasible situation where you have a verified
fingerprint in one mobile app and you need to get it to a second. It's
more likely you have a public key 'pointer' (something that would get
you a public key, like a url or fingerprint in an email signature) and
you want to use it to get (not verify) a key.
And for (d), you have that awkward "Hold the card up to the screen and
try and compare them by shifting your eyes up and down". Typing *may*
be less error-prone. If it had a running checksum it probably would
be. But asking users to type things in feels like it would be really
jarring in a user's workflow.
-tom
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp