Allowing import of pubkeys without User ID
Andrew Gallagher
andrewg at andrewg.com
Fri Jan 13 13:15:13 CET 2023
On 13 Jan 2023, at 11:50, Werner Koch <wk at gnupg.org> wrote:
>
> On Fri, 13 Jan 2023 11:00, Andrew Gallagher said:
>
>> True, it’s not a security issue - but it is a usability one. “Key not
>> found” is a temporary error, while “key revoked” is permanent. These
>> are two quite different failure modes, and it would be best to clearly
>> distinguish them.
>
> Sure. But the point here is on how to retrieve a revocation
> certificate. To do this you first need to have access to the key -
> without the key there is no need to retrieving a revocation. Without a
> key you don't know anything about a signature.
Correct. But say we’re trying to look up the key for a strange signature, and we have multiple methods to do so (several disjoint keyservers, WKD, LDAP, etc.). If we get a “key not found” error, that’s just going to encourage us (either manually or via an automated system) to keep trying the other methods. But if we get a “key revoked” error, then we have a definite answer and can stop looking. The client-side/user behaviour changes depending on the failure mode.
> In fact you could store a standalone revocation certificate on the
> server and allow accessing it by the included issuer fingerprint. A
> dedicated keyserver command to do just this might be useful too.
Yes, there are any number of alternative ways to work around it, but none of them are as straightforward and elegant as just... allowing uid-less TPKs. :-) Particularly in the case of synchronising keyservers, where the only canonical metadata is what can be stored in a self-sig, it makes sense to allow self-sigs and their primaries to be distributed regardless of whether they are “usable” in a client-side sense.
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230113/30ca5d1c/attachment-0001.sig>
More information about the Gnupg-devel
mailing list