WKD: conveying intent of encrypt-by-default?

[Erich Eckner]

On Mon, 3 Oct 2022, Phil Pennock via Gnupg-users wrote:

> Folks,
>
> 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
> keys.
>
> 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".
>
> -Phil
>

Hi Phil,

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?

regards,
Erich