TOFU - motivation
wk at gnupg.org
Sat Apr 4 12:19:00 CEST 2015
On Tue, 31 Mar 2015 21:51, rjh at sixdemonbag.org said:
> GnuPG is a toolbox. TOFU is a policy. Keep 'em separated and everyone
> will be happier. That isn't to say you can't do TOFU, just don't expect
> people to be cheerful about the prospect of putting policy into GnuPG.
Sorry, but we already have a policy in GnuPG: --trust-model=foo. The
default is the WoT but many users resort to --trust-model=always which
does only protect against passive attacks and not against any kind of
active attacks (e.g. MitM).
GnuPG allows to override this policy and many frontends have their own
override features or simply implement their own thing. Nobody will be
forced to use a --trust-model=tofu but it is very likely that it will
eventually be the default.
> No, we don't. One email system might be TOFU, and another email system
> might require strong identity checks. Or what about the case of two
> TOFU systems: should system A be required to trust the certificates
> entered by system B? They're both writing to the same GnuPG trust DB,
> after all.
The idea is not to throw away the WoT which is stored in trustdb.gpg but
to implement an additional systems. Whether this will also the same
file or a different one is a technical question and not a policy issue.
> As it currently stands, TOFU would (should) be done at the MUA level.
> When the MUA receives a message, it can call GnuPG to discover the
> certificate used for signing. If the certificate used is not what the
> MUA expects, it can ask the dialog what to do: no upcall required.
Right, this is the idea. What we will implement in GnuPG is just a
database and functions to update and query a database. Now, if a MUA
decides to use a different set of keys and mail addresses (which are our
identities) it is free to use a different --homedir.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel