adding TOFU/POP to GnuPG
hans at guardianproject.info
Fri Mar 14 22:03:56 CET 2014
On 03/14/2014 01:25 PM, Werner Koch wrote:
> On Fri, 14 Mar 2014 16:10, hans at guardianproject.info said:
>> * full SSH style TOFU/POP keyring: the process of adding a key to your local
>> keyring marks it as trusted. signatures also mark keys as trusted
> You can't compare ssh's key management to GnuPG's. Indeed ssh works the
> way you describe it but ssh also uses the only the bare key without any
> In our Steed paper  we looked in how to implement a TOFC (aka TOFU)
> system into OpenPGP and S/MIME. In Steed we do not want to talk about
> key ids or fingerprints but use only the mail address to identify the
> key. To evaluate whether a MitM has been mounted we will need to keep a
> list of recent contacts. That requires closer interaction with the MUAs
> and can't be done by gpg alone. However, to make things easier GnuPG
> should keep that list of contacts.
I think that STEED definitely represents an improvement and has a solid ideas
in it. Requiring involvement with MUAs makes it a lot harder to get adoption.
>> * or a more GnuPG style: adding a key to the local keyring adds some trust,
>> but not as much as a signature.
> Not a good idea because the keyring has always been used as white pages
> or as a cache for the keyservers. Redefining it to gpg's known_hosts is
> not a good idea at all.
I propose using this trust model for people starting new, or for people
willing to switch to it. It would not be compatible with standard OpenPGP habits.
> Further the notion of different trust levels is hard to define and to
> explain. For that reason we basically use only 3 levels:
> - Bad
> - Might be good but needs manual inspection due to expiration,
> revocation, no computed trust.
> - Good
> GPGME uses flags named red, yellow, and green for tehse levels and some
> MUAs put a such colored frame around the message.
That makes sense. This is what OTR clients generally do, and it seems
workable. But I think most OTR users are always chatting in "might be good"
mode. So "might be good" mode might be not all that useful. I think
expiration for email is not that useful. Just revokation should handle that all.
> With Steed a mail would be rendered yellow on the very first (few)
> contact(s) and latter either green or red. In case a key has been
> superseded due to a lost passphrase, the mail would be rendered red but
> a list of previous contacts will be displayed to help the user to
> evaluate what might have happened. Unfortunately certain circumstances
> delayed the development of a prototype but there is still a lot of
> interest in such a system.
>> does provide a benefit. It also does not prevent users from doing
>> stricter verification at any time.
> Users won't do that.
I agree, a good system should not rely on it, but it should provide the
opportunity for the at-risk users who will actually do that. We work with a
lot of people who actually verify PGP and OTR fingerprints, and we are
involved in trainings to teach at-risk people how to do that.
>> OpenPGP is so over-complicated, and seemingly only getting more so. And that
> Compared to CMS OpenPGP is a quite lean and stable protocol. Changes to
> the protocol are very rare: We only have a few RFCs adding new cipher or
> public key algorithms.
Oh yes, there are definitely far worse culprits. X.509/TLS comes to mind as well.
> The thing is that OpenPGP provides a lot of _optional features_ which
> can be used to model any kind of PKI. Most of them are not in real use
> and for GnuPG I try to limit the options presented to users. Still
> there are too many of them and I agree that the interaction of the user
> with the software should be limited to the bare needs. We experts can
> still to play or use with almost everything from the standard and even
> exchange encrypted messages with all users.
I view GnuPG has a toolbox of trusted crypto components. That is why I think
it is a good system to base such a system on
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
More information about the Gnupg-devel