Question to WKD-Feature

[Werner Koch]

Hi Peter,

On Tue, 25 Oct 2016 18:47, p.fischer at heinlein-support.de 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 example.com.  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 example.org") for mail addresses, and under the premise
  that almost all MTAs treat the "local-part" case-insensitive and [...]

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.
> "<https://example.com/.well-known/openpgpkey/hu>")
> * We found the answer on the WKS-Site
> (<https://www.gnupg.org/blog/20160830-web-key-service.html>), 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 ;-).


Salam-Shalom,

   Werner

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