On Fri, 16 Apr 2021 18:31:01 +0200,
vedaal(_at_)nym(_dot_)hush(_dot_)com wrote:
On 4/16/2021 at 10:24 AM, "Neal H. Walfield" <neal(_at_)walfield(_dot_)org>
wrote:
Why would Alice want to import M's key?
In the software that I'm working on the "keyring" is simply a cache.
We aggresively harvest all keys that we encounter (storage is cheap),
and rely on our trust model to separate the wheat from the chaff.
Still, in order for her to Import M' as a new key by M, she would check
first if M' was also signed by M.
If she then sees a decryption problem, she would (thanks to your pointing
this out),
check for duplicate subkey S in her keyring, and then find out that M does
bear her ill will.
In my opinion, we should shift as little complexity as possible to the
user. In our case, this means that Sequoia has to worry about a lot
more corner cases, such as this one, but I think it is worth it.
As most users are familiar with their encryption subkey's
fingerprint, it would be a good idea to check any prospective
public key for an encryption subkey fingerprint, before importing
it.
The user population that I'm targetting doesn't understand how to do
this nor do they want to learn about these nuances.
Thanks for pointing this out.
(Doesn't affect me though, as am from old school that doesn't use subkeys,
where the primary certificate signs, decrypts and authenticates).
Thanks for the feedback!
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp