On Tue, 2015-04-28 at 11:12 -0400, Phillip Hallam-Baker wrote:
There are many other cases where devices will be exchanging
fingerprints under the covers.
And most of the time they should probably work with the keys themselves,
than using the fingerprint.
But I don't expect the user to ever see
those. If we meet at IETF and bump iPhones then I don't expect to see
a fingerprint unless I open up an 'advanced' tab.
I'd generally refuse to design the next version of OpenPGP targeted
around use cases which inherently have very questionable security.
Especially smartphones are not really trustworthy for doing secure
crpyto,... so you need more reason than "it would be nice for
Apple/Android/Smartphone/JavaScript based E2E crypto/etc." in order to
convince me.
Same for email. Lets imagine this email had a header that said:
Fingerprint: ufi:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx;
holder=phill(_at_)hallambaker(_dot_)com
Your email client could collect that automatically and take it as
probable cause to suspect that the specified fingerprint might be
associated with phill(_at_)hallambaker(_dot_)com.
And what's the use/benefit of this? The sender of an email is already
identified by it's From: header, an in order to trust that it needs to
match a properly signed UID on the key.
Works already fine?!
Further, this shouldn't be part of an OpenPGP standard,... we're not
defining mail.
It's ok if we define a fingerprint format, perhaps even URI schemas, but
that's it.
Now as stated, that would not be proof but we can add in mechanisms
that would enable a challenge-response verification to be performed
automatically and transparently. that is slightly more complex than it
sounds because we have to avoid getting fooled by mailing lists, etc.
But at this point any mailing list that isn't giving the correct SMTP
headers is likely being spam filtered away anyhow.
What kind of challenge response? I.e. what should it prove?
But for these applications we can use a 256 or even 512 bit
fingerprint and it isn't necessary to base32 encode it either unless
we think it might get translated to a little-fingerprint at some
point.
Same goes for QR codes. There really is no need for the QR code to be
based on the base32 encoding, it can be calculated from the binary or
base64.
I don't think we should define too much fingerprint formats, especially
the "short" are always kinda dangerous... it's like with the key IDs,..
people use it in insecure ways.
I'm also highly sceptical towards any formats that are not human
readable (e.g. QR).
When it comes down to it, business cards and legal documents are the
only places I expect the base32 fingerprint to be seen.
?? Every piece of software which deals with the keys and shows their FPs
for verification?
That said, I am really on the fence on Base32C.
Does it have any big advantages over plain BASE32?
Cheers,
Chris
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp