On Sun, 27 May 2018 23:31:39 +0200,
Leo Gaspard wrote:
On 05/27/2018 10:58 PM, Neal H. Walfield wrote:
On Sun, 27 May 2018 19:00:04 +0200,
Leo Gaspard wrote:
Indeed it's already possible, the issue with this solution being that
people willing to rely on signatures by the master key now need to
download two keys (the master key and the trusted introducer), and
another one after any compromise, while certification subkeys are
downloaded and updated at the same time as the master key, thus making
for more easy-to-use WoT.
That's true. But, I'd argue that this is more of a tooling problem:
when the tool is computing the WoT and it encounters a trusted
introducer has tsigned a key, which is not available, it should
proactively download the key.
Hmm, I'm not sure it's possible? I mean, if I'm a user, there are 3 keys
to me:
1. The master key that I trust
2. The trusted introducer
3. The key whose validity I want to check
As a user, I have only access to 1 and 3: 1 because I signed it, and 3
because I want to check it. I have /a priori/ no access to key 2. When
could I fetch it?
Right. One thing that you can do right now is to fetch the keys that
signed the master key: it is not unusual for key validation to be
symmetric. The other thing is for the key servers to add an extension
to return all keys signed by a given key.
By policy (and I think it's reasonable for metadata protection reasons),
(most?) implementations do not fetch keys on-the-fly during things like
signature checking or encryption. So I must have had access to the key 2
before that.
Accessing the keys via Tor partially mitigates this problem. But,
there is no reason to only fetch the keys when needed. See, for
instance, parcimonie for how to do this in a privacy preserving way.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp