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

[Bart Butler <[e-mail]>]

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=[e-mail]

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=[e-mail]

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 <[e-mail]> wrote:

> On Thu, 8 Nov 2018 12:08, [e-mail] 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 [e-mail] is now
> 

> https://example.org/.well-known/openpgpkey/
> hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=[e-mail]
> 

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