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?
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.
However, there is no way (as far as I know) to fetch key 2 when I have
only key 1, as the information of which key a key has tsigned is not
stored in the tsigning key.
So the only moment left for the tooling to download key 2 is when
fetching key 3: when downloading a key, it would automatically download
all keys that have signed it. I think that's possible, but not
necessarily reasonable, as it'd lead to surprising behaviour (importing
more keys than expected), and thus potentially to vulnerabilities on
other tools that wouldn't expect this behaviour.
Now, I was putting this forward mostly for giving another use case that
would naturally benefit from certification-able subkeys, I agree that it
certainly wouldn't deserve the added complexity were it the only use
case of them :)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp