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

[Werner Koch <[e-mail]>]

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.