what's necessary before new OpenPGP keys are used?

Kai Engert kaie at kuix.de
Fri Dec 6 06:46:07 UTC 2019

Hi Wiktor,

On 05.12.19 19:10, Wiktor Kwapisiewicz wrote:
> On 05.12.2019 18:33, Kai Engert wrote:
>> Further I suggest: As soon as Alice has opted in to use Bob's key for 
>> encryption (with or without doing a full verification), then Alice's 
>> Thunderbird will continue to use Bob's key for future outgoing 
>> encrypted email, without further need to confirm.
> That's a good idea. I hope "the same key" will mean the same primary key 
> fingerprint and that updating other components (like subkeys) won't 
> trigger the "key ambiguity" logic.

Yes, that seems reasonable.

However, I'd keep the approval tied to the key's email address. If 
another identity is added to a key, we'd still need a confirmation for 
using that key with the new email address.

> Additionally some WKD clients (such as GnuPG) automatically re-fetch 
> keys via WKD when they expire. It would be nice to at least consider the 
> case that the recipient key expired and that's nothing bad it just needs 
> to be refreshed. (That's of course not the same as key being revoked).

IIUC changing (extending) the validation period doesn't influence the 
fingerprint. I agree that using a refreshed key with a different 
validation period shouldn't trigger an ambiguity warning for that key.

However, if Bob's key gets extended and distributed only after it has 
expired, and in the meantime Alice's Thunderbird found some other key 
for Bob, then Alice might have already been asked to make decisions 
about an alternative key. If this happened, once the refreshed older key 
is received, an ambiguity interaction might get triggered again.

>> As part of the request to resolve the ambiguity, we could show 
>> statistical information, like, that the previous key has already been 
>> used 20 times for sending encrypted email to Bob, and the new key 
>> having never been used yet.
> This seems similar to GnuPG's "tofu" trust model:
> http://gnupg.10057.n7.nabble.com/TOFU-for-GnuPG-td44857.html

True. My current thinking is to use a TOFU model, which requires 
confirmation for the initial use, combined with encouraging users to 
perform full key verification. The user interface would indicate that 
encryption (or a signature) related to a fully verified key has a higher 
security level than the use of a previously accepted, but unverified key.


More information about the tb-planning mailing list