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

[Paul Fawkesley <[e-mail]>]

On 08/11/2018 07:18, Werner Koch wrote:
> On Wed,  7 Nov 2018 20:49, [e-mail] said:
> 
>> 1. SHA-1 is obsolete.
> 
> |   The use of SHA-1 for the mapping of the local-part to a fixed string
> |   is not a security feature but merely used to map the local-part to a
> |   fixed-sized string made from a well defined set of characters.  It is
> |   not intended to conceal information about a mail address.
> 
>> 2. The use of a cryptographic hash here makes it harder for a server
>>    to conduct an appropriate lookup.  For example, if a server defines
>>    that all email addresses
>>        alice+<something>@example.com
>>    are owned by Alice, and Alice tells the server `please advertise
>>    my one OpenPGP key for all my email addresses', it is not clear how
>>    the server could implement that.
> 
> The problem here is that the client needs to know how the server handles
> this.  This is because the client should filter the returned key for a
> matching mail-addresses.

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

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

* [e-mail]
* [e-mail]

>  Actually we have had a discussion about this
> recently in Brussels with the outcome that for experiments we now
> appened "?l=joe.hacker" to the request.  Currently implemented servers
> will just ignore these parameters.

For experimenting, fine, but I'd prefer to get to a "production"
solution ASAP.

> 
>>
>> Suggested modification: Replace this part of the URL with the
>> URL-encoded email address.
> 
> Nope: That breaks existing implementations and would not allow to serve
> the data from static files.

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

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
   2.c in the client, don't filter on the user id for these

Ian, apart from z-base-32 not being exactly mainstream, does 2. work for
you?

>> II. URL domain name part
>>
>> The mail system for some domain, and its web server, are not
>> necessarily on the same host or under the same practical
>> administration.  Often webservers are outsourced.
> 
> That is rarely the case but given that I know a pretty large provider
> which has this problem, SRV records are used to overcome this problem.

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

I'm recalling a large organisation I worked in that were heavy users of
PGP. I can see two options for how I could have implemented WKD there:

1. request an HTTP redirect on the root domain (this one change would
take weeks of "change control" process, with lots of signing off by line
managers etc.) Then I can run a WKD service wherever I like.

  (the hosting for different subdomains and mail server were sprawling
across many different systems and providers)

2. use a subdomain e.g. wkd.example.com (also through a lengthy change
control process to get the subdomain)

Given that we can't rely on SRV records:

> 
>> Suggested modification: the domain name part should have a fixed
>> string prepended.
> 
> 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.

Paul