Neal H. Walfield
neal at walfield.org
Sat Jul 25 18:23:04 CEST 2015
At Wed, 22 Jul 2015 12:01:41 +0200,
Werner Koch wrote:
> On Fri, 17 Jul 2015 14:24, neal at walfield.org said:
> > Finally, we'd have to regularize names. At least for latin and
> > germanic languages, UTF-8 canonicalization, space compression and down
> > casing should be enough. But, I'm not sure about other languages
> > where letters are combined.
> Just to clarify: GnuPG only knows about UTF-8 (as per OpenPGP) and it
> does not handle IDNA etc. Any mapping to the encoding required for
> example by rfc822 has to be done outside of GnuPG.
This is related to another email that you sent in this thread and to
which I just followed up. Let's continue the discussion there.
> > Note: it is unclear what to do when the OpenPGP User ID is not in RFC
> > 2822 form or there is no email address.
> I suggest to ignore such a user id.
> See gnupg/common/mbox-util.c:mailbox_from_userid on GnuPG parses userids.
I don't see why we should implement TOFU for hostnames.
This also open an opportunity for an attack. If the attacker just
replaces the @ with a similar looking character, we'll ignore the
key. I don't think that's a good idea.
> > Verification
> > ============
> > - If no bindings contain either the email address or the key, then
> > we ask the user whether to accept the new binding.
> For TOFU alone this would be okay but TOFU is only one part of the
> story. We need to limit user interaction to the bare minimum. Thus in
> this case we need to lookup the key using DNS (PKA style CERT records)
> by th mail address. The binding should have a "Initial-Source" field to
> record that the binding has been created from
> a) PKA
> b) keyserver lookup by fingerprint
> c) a key send with a message
> d) the verification of a signed message
> e) a manually imported key with verified fingerprint (keysigning).
> This information can be useful in cae of a conflict. For example a
> manually imported key should be more trustworthy than one take from a
> keyserver. The exact rules need to be worked out but tracking the
> source needs to be there right from the beginning.
This is a good idea.
> > course, for new bindings, the key is probably not yet available and if
> > the user hasn't enabled auto-key-locate (which is disabled by
> > default), then we can't do the verification nor can we update the
> We need to change some of the defaults - at least for email use.
> Traffic patterns are anyway not protected and thus it does not sense to
> avoid network access by default. For those who need it they can use
> --disable-dirmngr to avoid all kind of network access or use the
> proposed --enable-tor option. The goal is to increase the use of
> encrypted mail and not to be safe against targeted attacks by default.
> > Export
> > ======
> > Should TOFU bindings be exportable? TOFU reveals the user's social
> No. That should be kept local like the trustdb.
I think reasonable people can disagree about this. But, as Robert
said, let's defer this discussion.
More information about the Gnupg-devel