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

[Werner Koch <[e-mail]>]

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

> 2a. The cryptographic hash does not, however, provide any significant
>    degree of useful obfuscation since a search will usually be able to
>    reverse it.

See above

> 2b. The cryptographic hash is not needed for space reasons since URLs
>    can easily be as long as email addresses.

Right.  A constant length can make implementations easier. YMMV.
Further there is no limit on the length of the local part of the
addrspec.  It may well exceed the max. length of file names.


> 3. Supposing the hash were to be retained, choice of base-32 rather
>   than base-64 is unusual and needs to be justified.

Easy: The standard Base-64 includes a slash and thus the has can't be
used as a file name.

> 4. The lowercasing of the email address is contrary to the Internet
>    mail specifications, where case-sensitivity of the email address
>    is up to the mail domain in question.  If the email address were
>    not obfuscated by hashing it would be easy for the webserver to
>    handle case-sensitivity by URL remapping.

See my reply to Brian and above.

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

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

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

> III. Normative status of this document

|   Internet-Drafts are draft documents valid for a maximum of six months
|   and may be updated, replaced, or obsoleted by other documents at any
|   time.  It is inappropriate to use Internet-Drafts as reference
|   material or to cite them other than as "work in progress."

OTOH, it is a standard practise that RFCs are based on existing
implementations and we have that implemented in in GnUPG 2.1.12 (May
2016) and thus for example also in Debian Stretch


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.