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
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
Attached Files:
-
signature.asc (0.22 KB)