Questions regarding WKD/WKS

[Andreas Heinlein]

Am 02.12.22 um 14:59 schrieb Werner Koch:
> On Thu,  1 Dec 2022 14:45, Andreas Heinlein said:
>
>> 1. If I follow the guidelines for creating the directory
>> /var/lib/gnupg/wkd, it has ownership webkey:webkey and permissions
>> 2750. So there ist no chance for the apache user to be able to read
> That does not look right.  You should have o+rx for the directories and
> o+r for the files.
If I do that, I get:
gpg-wks-server: directory '/var/lib/gnupg/wks' has too relaxed permissions
gpg-wks-server: Fix by running: chmod o-rw '/var/lib/gnupg/wks'

This is gpg-wks-server version 2.2.27, as packaged with Debian 11. If this is a (known) bug, I may try to get it fixed.
>
>> suggested and I am submitting the key encrypted and signed with the
> You should not sign the message.
>
>    The key to be published MUST be submitted using a PGP/MIME encrypted
>    message ({{{RFC(3156)}}}, section 4).  The message MUST NOT be signed
>    (because the authenticity of the signing key has not yet been
>    confirmed).
>
> I would also strongly suggest to use gpg-wks-client.
Thanks, I overlooked that. I find it a little difficult to instruct normal users to configure their client to sign mails, but make an exception when submitting their mail to the wks.

I cannot use gpg-wks-client here - our folks are using thunderbird. This is a known missing feature in thunderbird, WKS client support got lost when moving from Enigmail to their own implementation. See here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1695048

For the moment it would be nice if we could "stretch" the RFC a little and just ignore any signatures. Any way to achieve that, or would it be necessary to patch the wks server?
>
>> gpg-wks-server: gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
> GnuPG 1.4 - really?  Don't do this.  And in particialr not a 12 year old
> version.
Yeah, I know. This was from an old testing machine, I wouldn't do that in real life ;-)
>
>> 3. What is the behaviour when the WKS server receives a key for an
>> address for which it already has a (different) key? Will it replace
>> the old key, will it refuse or ignore the new one?
> The old key will be replaced after the confirmation has been received.
That's what I expected.

Thank you,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20221202/85800858/attachment-0001.html>