Web Key Directory

[Bernhard Reiter]

Hi Werner, Dear GnuPG-Community,

some thoughts on
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=blob;f=misc/id/openpgp-webkey-service/middle.mkd
(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:
>
>         https://example.org/.well-known/openpgpkey/
>         hu/example.org/iy9q119eutrkn8s1mk4r39qejnbu3n5q
>
>     (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
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
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 
the same.

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

== (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 
me.

"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
  'crypto-cert-lookup'
  'OpenPGP-cert-lookup'
  'email-crypto-cert-service'

== Misc
* Add an DANE rfc reference?
e.g. https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-11
* Mention DNSSEC? It is not encrypted, so it leakes some information to 
eavesdroppers
https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Deployment

Best Regards,
Bernhard
-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160509/6d24aac4/attachment-0001.sig>