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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
