Question to WKD-Feature

Werner Koch wk at
Fri Nov 4 21:03:37 CET 2016

Hi Peter,

On Tue, 25 Oct 2016 18:47, p.fischer at said:

> "The HTTP GET method MUST return the binary representation of the
> OpenPGP key for the given mail address"
> Q1: Why is the output-key-format of the WKD-server binary and not
> "ASCII amored"? In difference the key-format of the submissions-mail
> is "ASCII armored".

It is binary because HTTP transports binary data just fine.

In contrast SMTP is not able to transport binary (hard line length
limitation) so that PGP/MIME (RFC-3156) demands armored messages.
Right, they could have also used binary so that MIME would be forces to
use Base64 encoding.  I guess Michael Elkins wrote the specs in that way
to make it easier for implementations (checkout how Mutt handles PGP).

A single fixed format makes it easier for implementations because the
test for binary or armored is not needed (cf. gpg's option --no-armor)
and a couple of problems with armor won't happen.  There has also been a
discussion in the OpenPGP WG on dropping the armor format from the
standard (unlikely to happen, though).

> Q2: Why do you build the URL for the public keys with SHA1-hash of the
> local-part?
>  * Are SHA1 hash-collisions theoretically possible (special on large
> userbases) ?

No.  But that is not the point; the hashing is only used to map all
possible local-parts to a character set which can easily be expressed in
an URL and be used in a file system (e.g. '/' is allowed in the
local-part but problematic in a file name).

>  * What about lower-casing all upper-case ASCII characters in
> local-part? Maybe encoding base64, for forward and backward lookup of
> the local-part?

The lower-casing has a pretty simple but common reason.  On business
cards the mail address is often written as John.Doe at  Most
users are not aware of the unspecified handling of case in local-parts
and some will type the name as is other will lower-case the name.
Regardless of that they want to send to the same address.  Fortunately
all mail providers I am aware of ignore the case in the local-part.

Now, if you really want to allow a lookup with a mixed case local-part
(say, due to software which does not do the lower-casing in the
request), it is easy to extract the mail address from the key and create
a symlink or a copy of the key under that hash.

> We believe that your reason for this is compatible and robustness on
> differed file systems. Please describe it, in an short comment in the
> DRAFT, to understand the motivation.

It is already there:

  OpenPGP defines its User IDs, and thus the mail address, as UTF-8
  strings.  To help with the common pattern of using capitalized names
  (e.g. "Joe.Doe at") for mail addresses, and under the premise
  that almost all MTAs treat the "local-part" case-insensitive and [...]


  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.

> Q3: Why is in the fixed string an subfolder "hu" (e.g.
> "<>")
> * We found the answer on the WKS-Site
> (<>), but it
> is needed (and when please  describe it in the Draft)?

It is just an identifier to put the keys into a separate directory than
the static information.  It also allows to switch to a newer version of
the protocol by replacing "hu" by another name.

RFCs give rationales only on important topics; most decisions are left
as an exercise for digital archaeologists ;-).



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161104/148abed9/attachment.sig>

More information about the Gnupg-devel mailing list