Web Key Directory
bernhard at intevation.de
Mon May 9 15:31:08 CEST 2016
Hi Werner, Dear GnuPG-Community,
some thoughts on
(I'll cite passages from there with the line number in front.)
Am Freitag, 6. Mai 2016 10:22:48 schrieb Werner Koch:
> For example the URI to lookup the key for Joe.Doe at Example.ORG is:
> (line has been wrapped for rendering purposes). The hash is a
> z-Base-32 encoded SHA-1 hash of the mail address' local-part. The
> address wk at gnupg.org can be used for testing.
59 Although URIs are able to encode all kind of characters,
60 straightforward implementations of a key directory may want to store
61 the "local-part" of a mail address directly in the file system. This
62 forbids the use of certain characters in the "local-part". To allow
63 for such an implementation method the URI uses an encoded form of the
64 "local-part" which can be directly mapped to a file name.
== why hashing the local user part?
Can you explain this implementation idea in more detail?
A lot of file systems allow saving of all characters in an email address,
mostly all bytes or unicode char except NUL.
This includes the standard default file system of major operating systems
like GNU/Linux, Mac OS X, Windows, see
So there may be no real need to cater to file systems, which is given
in the draft. This would still be possible. And some server implementers
will prefer a database approach anyway, so this is has the potential drawback
of adding an unnecessary implementation detail.
As potential drawbacks I additionally see that using the hash will add a tiny
chance of a collision and the mapping function may be a bit more complicated
as necessary provoking implementation errors as all clients have to implement
As advantage there is a limit on the length of the file name and that mapping
CPU resources will be done on the client which is good for high performing
webserver (if mapping is necessary after all).
What is special about the selected mapping function (Z-Base-32 method as
76 described in (#RFC6189), section 5.1.6.)?
== Where does the "/hu" come from?
78 concatenated with the mapped "domain-part", the fixed string
79 "./well-known/openpgpkey/hu/", the "domain-part" again, and the above
80 constructed 32 octet string.
== Update protocol, would TLS be better?
The biggest discussion point I have is that of the update protocol. The
alternative to an email update would be to use an HTTPS based update.
This possibly would be as secure, but the roundtrip would be faster
and no automatic email sending and processing would need to be implemented
on both server and client sides.
As drawback the HTTPS method technically depends on if the client
and server implementations have access to the email credentials of the user
== (General) Name
On the name:
I see "openpgp-webkey-service" and "Web Key Directory"
to me a better name would go without "web", "directory" or "key".
"directory" I don't like because there only one way to look up things
and I cannot discover new email addresses with it. "lookup" seems better to
me. "service" would address that we can also manage the public keys.
"web" seems to refer to "HTTPS", but this can bear a missunderstanding as
it shall be used for emails and files. "service" would be a better choice to
"key" I don't like because there is the missunderstanding of "privat keys"
to "public keys". However "public key" is too long for many contexts, so I am
trying to write "cert" and see how this fares. I know that "key" is the term
used in OpenPGP technical and normative circles, however we should go out of
our way to improve the experience and understanding of users. User have heard
about TLS certs, so I think it is worth a try to unify on "cert".
"OpenPGP" is technical as well, but may not be avoidable.
So how about
* Add an DANE rfc reference?
* Mention DNSSEC? It is not encrypted, so it leakes some information to
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel