On Wed 2019-04-03 12:14:36 +0200, Wiktor Kwapisiewicz wrote:
If by "how to properly constrain" you mean configuration on the server
side then it looks something like that for nginx:
location /.well-known/openpgpkey {
add_header Access-Control-Allow-Origin '*' always;
}
or for Apache:
<Location "/.well-known/openpgpkey">
Header set Access-Control-Allow-Origin "*"
</Location>
I agree that it's a good idea to expose it as narrowly as possible,
though it doesn't give JavaScript code in the browser more power than
"curl". (I can discuss details in case anyone is interested).
thanks, this is super useful. Could you propose text to be added to
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service as
deployment guidance?
Just in case a proof-of-concept is needed I wrote a simple decentralized
encrypt-then-email page that utilizes OpenPGP.js, CORS WKD and mailto
links: https://metacode.biz/sandbox/encrypt
neat, thanks for this! It's a shame that it can't produce PGP/MIME
messages, but rather does inline PGP, but i can see that's a limitation
of mailto: itself.
I'm assuming this is yours as well:
https://metacode.biz/openpgp/web-key-directory
that's very useful testing harness. It doesn't seem to match draft -07
though, because it's missing the l= query parameter
(https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section-3..1),
and i can't tell whether it tries the "openpgpkey.*" subdomain first.
Many thanks for putting concrete testing infrastructure in place for
this, and walking through what such a tool needs to be useful in the
browser-based message composition context!
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp