Subject: Re: [openpgp] Web Key Directory and CORS

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 3 Apr 2019 12:14:36 +0200

Hi Daniel,

On 01.04.2019 01:22, Daniel Kahn Gillmor wrote:
> I don't know CORS well enough to know how to properly constrain such a
> header, but if we do add guidance, i'd want to make sure it is narrowly
> scoped so that an administrator deploying WKD doesn't accidentally open
> up the rest of the site's data to external cross-origin requests.

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).

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

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Apr 2019 07:47:08 -0400

> "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?

> 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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 3 Apr 2019 14:07:25 +0200

Hi Daniel,

> https://tools.ietf.org/html/draft-koch-openpgp-webkey-service as

Sure. I'll check out other RFCs for a formal language and I'll be back 
with a patch.

> messages, but rather does inline PGP, but i can see that's a limitation

Yes, lack of PGP/MIME is sadly not there, on the other hand the entire 
page has just 7 lines of readable JavaScript (not counting OpenPGP.js of 
course).

> and i can't tell whether it tries the "openpgpkey.*" subdomain first.

Yes, that's mine and yes it hasn't been updated to match latest drafts. 
Sadly the amount of time I can spend on it is very scarce but bringing 
it up to date is definitely on my TODO list.

> browser-based message composition context!

No problem. Actually that's what I like in standards - implementations 
work in a wide variety of environments and still interoperate with each 
other.

Kind regards,
Wiktor