ietf-openpgp
[Top] [All Lists]

Re: [openpgp] OpenPGP Web Key Directory I-D

2018-11-09 17:50:30
I also wanted to clarify in the WKD I-D that requests should follow HTTP 
redirects (301, 302). As I provider we would like this so that a client using 
us to host their email could just set up a redirect to our WKD server. It needs 
to be at the HTTP level rather than using a CNAME record because we do not want 
to have to host our clients' TLS certificates.

-Bart Butler

Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 9, 2018 3:18 PM, Bart Butler 
<bartbutler=40protonmail(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:

Hi all,


Based on discussions in Brussels, our current plan at ProtonMail is to 
implement, on the 'serving' side:


..well-known/openpgpkey/hu/<hash>?l=Joe(_dot_)Doe(_at_)example(_dot_)org


accepting everything including and empty string for the hash and using the 
'l' query string parameter exclusively for lookup for all the reasons 
previously mentioned in this thread and discussed in Brussels (case 
sensitivity, +aliases/subaddresses, Unicode, catch-all addresses). The hash 
would be ignored.


I think that long-term, two parameters that do the same thing and could 
conflict is bad and that while compatibility is a good short-term goal, we 
should try drop the hash and to migrate to this final form as soon as 
possible:


..well-known/openpgpkey/hu/?l=Joe(_dot_)Doe(_at_)example(_dot_)org


While this doesn't allow a filesystem to serve WKD directly, I'm fairly 
certain that one could do it reasonably easily with, say mod_rewrite and some 
minimal transformations or use RewriteMap with a script which does whichever 
transformation you'd like (lowercase, remove subaddresses, etc).


As for the SRV record discussion, I agree that JS support is a problem and 
unfortunately that means supporting HTTPS. I'm wondering if we should 
simplify this and simply mandate the 'wkd' subdomain, full stop, rather than 
having a fallback mechanism to the main domain. The reason for this is that a 
client could determine whether the HTTP lookup is worth doing from whether 
the WKD subdomain resolves rather than making an experimental HTTP request 
for every domain periodically and contributing to the internet's 404 rate.


With the current scheme, relatively high-volume clients like us would 
probably need to do requests for the policy document periodically for each 
domain we send to and cache the result to avoid getting banned for generating 
too many 404s. The TTL for that caching would be decided by the us, the 
client. With the 'wkd' subdomain all clients would get that kind of caching 
for free via DNS, with a TTL controlled by the WKD server, which is both 
simpler and more logical I think.


-Bart Butler


Sent from ProtonMail, encrypted email based in Switzerland.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, November 8, 2018 4:00 AM, Werner Koch wk(_at_)gnupg(_dot_)org 
wrote:


On Thu, 8 Nov 2018 12:08, paul(_at_)fluidkeys(_dot_)com said:


The requirement for the client to filter the return key for matching
user IDs is a fairly big blocker for us.


We can't request a certain address and then work with any address
returned from the server. I am pretty sure that there will be server's
which store the entire key and not used the key stripped off all other
user-ids. Thus the filtering on the client site is important.


We (and previous large organisations I've worked in) use + aliases
feature extensively to distinguish different services, for example:


Yes, I know. We discussed this withe protonmail folks. One idea was to
ask the server for the rules it uses to canonicalize the address. That
will be quite complex and needs additional roundtrips. So the other
idea is to simply go with the '+' separator and have a special case for
it. Implementation wise it this requires changes at several palce to
have a consistent user experience.


To stay compatible, keep supporting static files and resolve the case
and aliasing issues, I'd support:


1.  keep supporting sha1-z-base-32 identifier


Already doing that.


2.  additionally start supporting z-base-32 identifier with no SHA1
    2.a maybe put them at different path
    2.b don't lowercase anything before searching for these
    







GnuPG 2.2.11 does this as descipned in my last mail.
For example the URI to lookup the key for 
Joe(_dot_)Doe(_at_)Example(_dot_)ORG is now


https://example.org/.well-known/openpgpkey/
hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe(_dot_)Doe(_at_)example(_dot_)org


No hashing is required, the case is not changed; the parameters undergo
the usual percent-quoting.


2.c in the client, don't filter on the user id for these


That is the harder part. The matching in gpg is anyway case-insensitive
and I would like to implement '+' style sub-addresses; that is ignoring
everything from '+' to '@'.


Given that SRV records can't be accessed by Javascript implementations,
I don't think we can point to that as a solution


It is a pity that solid network techniques need to be dropped in favor
of large but uncooperative browser vendors. Adding an interface for SRV
records would be really easy and helps to support flexible network
administration. Note that I don't wan't them to use SRV records for
generic http requests but extensions should be able to use it instead of
resorting to external DNS lookup providers. [Arggh, it is the whole
everything must be http thing - I bet we will sooner or later see a new
IP protocol number for HTTP-ng].


This is an open question but for a different reason: Current web
browsers have no way to lookup SRV records.


I'd support this.
I'd also support dropping the whole SRV records part to simplify the spec.


I recently looked into a protocol *forgot which one) which didn't used
SRV but a domain name prefix. So, do you think that a strategy of:


First try


https://openpgpkey.example.org/.well-known/openpgpkey/...


if that host can't be resolved (or accessed?), fallback to


https://example.org/.well-known/openpgpkey/...


be a practical replacement for SRV records here?


Shalom-Salam,


Werner






Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp