WKD: conveying intent of encrypt-by-default?
gnupg at eckner.net
Tue Oct 4 07:00:48 CEST 2022
On Mon, 3 Oct 2022, Phil Pennock via Gnupg-users wrote:
> I setup WKD for work a while back, to publish the PGP keys for those who
> had them. Then in November I removed the first key because it was
> causing Protonmail users to keep sending encrypted to the recipient and
> a lot of his communications turned out to be with Protonmail users.
> Now we've had this happening again, with someone else, and one very
> plausible outcome at this point is that we remove almost everyones' keys
> from WKD, leaving only those who sign security advisories, because WKD
> and the ecosystem right now is causing bigger problems than it solves.
> I think that there's a perfectly reasonable conflation of semantic
> intent. I'm not sure what the solution is, although I'm thinking that
> _perhaps_ the answer is to extend the allowed values in the "policy"
> file, to convey intent to a different audience than those uploading
> Problem: we use PGP for signing and for certain transactions which need
> high confidentiality, but for the most part, for most of our staff,
> setting up a PGP-capable mail client with our mail-provider is a pain
> and we're not interested. We want the PGP keys _available_ for people
> to have a trusted path to the key, but that does _not_ mean that we want
> people to default to using PGP for all communications with us.
> While Protonmail is the triggering party here, I don't think that
> they're at fault: for their model, what they've set up is probably a
> reasonable implementation. So please, no rants about Protonmail.
> Am I right in thinking that WKD was not really intended to be a trigger
> for opportunistic upgrade to PGP-encryption for messaging?
> Does it seem reasonable to add a directive to WELLKNOWN/policy, so that
> any WKD client can see what a general domain policy is?
> I could see individual users having other preferences, and I guess
> there's no reason that an additional binary PGP packet, not signed by
> the key, couldn't be served up together with the key from the WKD
> server. But that's more extensive coding to handle and interpret.
> Tentatively, perhaps:
> email-encrypt-by-default: yes
> email-encrypt-by-default: no
> and then if not present, then the intent is unspecified. We would then
> add "email-encrypt-by-default: no" and then the WKD draft could clarify
> as an implementation consideration that "availability of the key does
> not imply routine use of the key is desired".
ignoring your proposal (it sounds valid to me), would it be an option to
make the key a pure signing key? What's the use case to have an encryption
key but not receive encrypted email by default?
More information about the Gnupg-users