TOFU not affected by Key deletion
Open, NormalPublic
Actions

Assigned To

None

Authored By

	• aheinecke
	Dec 1 2016, 4:24 PM

Description

Hi Neal,

I tested with TOFU Conflict and got an unexpected result which I think is a bug.
If I delete a key the TOFU binding is still around and subsequent verifications will
still result in conflict.

I also get messages about the deleted key:
gpg: key "B0C3D4105EFEB59FF6844A6F87252BE27FF7506D" not found: Not found

Imo it might be common to delete a key after a tofu conflict. "Oh this isn't
your key? Ok, I'll delete it."

Console log:

(kf5) aheinecke@esus ~> GNUPGHOME=$(mktemp -d)
(kf5) aheinecke@esus ~> export GNUPGHOME=$(mktemp -d)
(kf5) aheinecke@esus ~> gpg2 --import arbeit/gpg4win/zertifikate/aheinecke3.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.eZWNJPSRGE/pubring.kbx' created
gpg: /tmp/tmp.eZWNJPSRGE/trustdb.gpg: trustdb created
gpg: key 87252BE27FF7506D: public key "Andre Heinecke (This is a Test key)
<aheinecke3@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
(kf5) aheinecke@esus ~> gpg2 --import
arbeit/gpg4win/zertifikate/aheinecke3-conflict.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 58E583B9012747A5: public key "aheinecke3 for conflic (Test key)
<aheinecke3@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
(kf5) aheinecke@esus ~>
(kf5) aheinecke@esus ~> gpg2 --trust-model tofu --verify /tmp/msg1

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Signature made Thu 01 Dec 2016 04:13:07 PM CET
gpg: using EDDSA key B0C3D4105EFEB59FF6844A6F87252BE27FF7506D
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: Good signature from "Andre Heinecke (This is a Test key)
<aheinecke3@example.com>" [marginal]
gpg: aheinecke3@example.com: Verified 1 signature in the past 0 seconds, and

encrypted 0 messages.

gpg: Warning: we've only seen one message signed using this key and user id!
gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user

id, then this key might be a forgery!  Carefully examine the email address
for small variations.  If the key is suspect, then use
  gpg --tofu-policy bad B0C3D4105EFEB59FF6844A6F87252BE27FF7506D
to mark it as being bad.

gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: B0C3 D410 5EFE B59F F684 4A6F 8725 2BE2 7FF7 506D
(kf5) aheinecke@esus ~> gpg2 --trust-model tofu --verify /tmp/msg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Signature made Thu 01 Dec 2016 04:13:18 PM CET
gpg: using EDDSA key 535EE3A49BB8F14C1622B64358E583B9012747A5
gpg: Good signature from "aheinecke3 for conflic (Test key)
<aheinecke3@example.com>" [undefined]
The email address "aheinecke3@example.com" is associated with 2 keys!
Please indicate whether this email address should be associated with key
535EE3A49BB8F14C1622B64358E583B9012747A5 or whether you think someone is
impersonating "aheinecke3@example.com".

This key's user IDs:

  aheinecke3 for conflic (Test key) <aheinecke3@example.com> (policy: ask)

Statistics for keys with the email address "aheinecke3@example.com":

  535E E3A4 9BB8 F14C 1622  B643 58E5 83B9 0127 47A5 (this key):
    Encrypted 0 messages.
    Verified 1 message over the past day.
  B0C3 D410 5EFE B59F F684  4A6F 8725 2BE2 7FF7 506D (policy: ask):
    Encrypted 0 messages.
    Verified 1 message over the past day.

Normally, an email address is associated with a single key. However,
people sometimes generate a new key if their key is too old or they think
it might be compromised. Alternatively, a new key may indicate a
man-in-the-middle attack! Before accepting this association, you should
talk to or call the person to make sure this new key is legitimate.

(G)ood, (A)ccept once, (U)nknown, (R)eject once, (B)ad?
gpg: signal Interrupt caught ... exiting

(kf5) aheinecke@esus ~> gpg2 --trust-model tofu --batch --verify /tmp/msg2

gpg: Signature made Thu 01 Dec 2016 04:13:18 PM CET
gpg: using EDDSA key 535EE3A49BB8F14C1622B64358E583B9012747A5
gpg: Good signature from "aheinecke3 for conflic (Test key)
<aheinecke3@example.com>" [undefined]
gpg: aheinecke3@example.com: Verified 1 signature in the past 19 seconds, and

encrypted 0 messages.

gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 535E E3A4 9BB8 F14C 1622 B643 58E5 83B9 0127 47A5
(kf5) aheinecke@esus ~> gpg2 --trust-model tofu --batch --verify /tmp/msg1
gpg: Signature made Thu 01 Dec 2016 04:13:07 PM CET
gpg: using EDDSA key B0C3D4105EFEB59FF6844A6F87252BE27FF7506D
gpg: Good signature from "Andre Heinecke (This is a Test key)
<aheinecke3@example.com>" [undefined]
gpg: aheinecke3@example.com: Verified 1 signature in the past 45 seconds, and

encrypted 0 messages.

gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B0C3 D410 5EFE B59F F684 4A6F 8725 2BE2 7FF7 506D
(kf5) aheinecke@esus ~> gpg2 --delete-key B0C3D4105EFEB59FF6844A6F87252BE27FF7506D
gpg (GnuPG) 2.1.16-beta394; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
pub ed25519/87252BE27FF7506D 2016-10-14 Andre Heinecke (This is a Test key)
<aheinecke3@example.com>

Delete this key from the keyring? (y/N) y
(kf5) aheinecke@esus ~> gpg2 --trust-model tofu --batch --verify /tmp/msg2
gpg: Signature made Thu 01 Dec 2016 04:13:18 PM CET
gpg: using EDDSA key 535EE3A49BB8F14C1622B64358E583B9012747A5
gpg: key "B0C3D4105EFEB59FF6844A6F87252BE27FF7506D" not found: Not found
gpg: Good signature from "aheinecke3 for conflic (Test key)
<aheinecke3@example.com>" [undefined]
gpg: key "B0C3D4105EFEB59FF6844A6F87252BE27FF7506D" not found: Not found
gpg: key "B0C3D4105EFEB59FF6844A6F87252BE27FF7506D" not found: Not found
gpg: aheinecke3@example.com: Verified 1 signature in the past 1 minute, and

encrypted 0 messages.

Related Objects

Mentioned In: T2742: tofu confused when keys are deleted from keyring
Mentioned Here: T2742: tofu confused when keys are deleted from keyring

Event Timeline

• aheinecke added projects: gnupg, Bug Report.Dec 1 2016, 4:24 PM

• aheinecke added subscribers: neal, • aheinecke.

That is consistent with the WoT behaviour. Deleting a key is no solution to a
faked key. It might be re-imported as any time.

What you should do instead is to disable the key so that it won't be used again.

Note: this is a dup of T2742

I tend to agree with Werner: if we discover a conflict, it needs to be resolved
and deleting a key is not a sufficient resolution.

• werner mentioned this in T2742: tofu confused when keys are deleted from keyring.Mar 30 2017, 7:19 PM

Sorry for the duplicated bug. Although the other issue is older I got more
response here so I keep the discussion here.

In my Optionion it's completely natural for a User to think (I thought this):

Oh I have two keys that are in conflict: I'll delete the bad one then I don't

have a conflict anymore.

This is very intuitive behavior.

I'm not looking for a solution that works for me but for a solution that I think
would work for other users.

So for me your response ("what you should do") would mean that in Kleopatra on
Key deletion I would need to check for conflicting keys and change their policy
to auto again. Maybe even mark the deleted key as bad before deletion. I would
much prefer it if GnuPG handled this. For me it seems just like an unhandled
state as the error messages also indicate. "Key not found" etc so It's a bug or
maybe missing feature / functionality.

Fwiw I don't see how this can be consistent with WoT behavior as I don't think
WoT has a comparable problem. Can you explain what a comparable problem in WoT is?

If you meant hat the validity of all keys is not updated immediately after key
deletion, and you had some ownertrust to the deleted key ok yes thats probably
also another issue. :-)

No need to apologize for the dup; I was just noting it here for the record.

I think that your assumption is that the local keyring is somehow trusted. In
that case, I think it make sense that deleted keys would clear conflicts.

I'm curious when you think people delete keys. My intuition is that it is not a
very common pattern. Do you have any thoughts on this?

I encourage you to first try and find a consensus before implementing a
different policy at the higher level.

Hi,

I think that your assumption is that the local keyring is somehow trusted. In

that case, I think it make sense that deleted keys would clear conflicts.

No, not really I don't think trust plays a role here. It's just a way I think
users may resolve conflicts when they don't know about policies or how things
work internally.

I'm curious when you think people delete keys. My intuition is that it is not

a very common pattern. Do you have any thoughts on this?

As an example: You get a new lock in your front door. Would you remove the key
for the old lock from your keyring or would you paint the old one red as a
marker not to use the old key.

I know that this is not totally applicable because the old key can still be used
for verification etc. But I think that this is the intuitive behavior if a key
changes.

Maybe if GUI offers conflict resolution better this might not be such a big deal
but currently (Kleopatra does not yet have conflict resolution) but for me
during tofu testing I thought I could resolve a the conflict by deleting one of
the keys and found the behavior unexpected.

I encourage you to first try and find a consensus before implementing a

different policy at the higher level.

Indeed. Let's try :-)

marcus added a project: Stalled.Jul 26 2017, 2:56 PM

marcus removed neal as the assignee of this task.Aug 14 2017, 10:35 AM

I experienced this issue today while cleaning up my keychain. I recently switched from pgp to tofu+pgp trustmodel and this caused me the above error when doing:

gpg --list-keys | awk '/^pub.* \[expired\: / {id=$2; sub(/^.*\//, "", id); print id}' | fmt -w 999 | sed 's/^/gpg --delete-keys /;'

The keys are removed but there seems to be some hooks left the the tofu database because when doing a simple:

gpg --list-keys

I would then get the

not found: Not found

but only for a very few number of them including an old DSA1024 key from Werner (0x5DE249965B0358A2) ;)

So when refreshing my keychain with the following command I would also get the same kind of error:

gpg --no-options --keyserver pool.sks-keyservers.net --keyserver-options no-honor-keyserver-url,import-clean,export-clean --refresh-keys

So to get it working I used a backup of my .gnupg directory, switched back to pgp trustmodel only and performed the above operations. Then I removed my tofu.db and switched back to tofu+pgp trust model. I had to perform such operations because accessing my keychain had become slower and slower over time. I cut down its size from 54MB to 15MB.

gpg: Total number processed: 245
gpg:              unchanged: 20
gpg:           new user IDs: 12
gpg:            new subkeys: 26
gpg:         new signatures: 227
gpg:     signatures cleaned: 68755
gpg:       user IDs cleaned: 234

TOFU not affected by Key deletionOpen, NormalPublicActions

Description

Related Objects

Event Timeline

TOFU not affected by Key deletion
Open, NormalPublic
Actions