what's necessary before new OpenPGP keys are used?
kaie at kuix.de
Fri Dec 6 06:46:07 UTC 2019
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:
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