Web Key Directory

[Werner Koch]

On Mon,  9 May 2016 15:31, bernhard at intevation.de said:

> == why hashing the local user part?
> Can you explain this implementation idea in more detail?

It is an obvious method to map one set of characters to another one.  It
has also the little advantage that we can work with fixed sized strings.

> A lot of file systems allow saving of all characters in an email address,
> mostly all bytes or unicode char except NUL.

Nope: You can't use a slash in a file name unless you want to handle
directory creation.  For Windows we have the colon and the backslash.
RFC-2822 has no strict requirements for the local-part and thus a slash
and colons are legal.   hashing is just easier.  DANE for OpenPGP works
the same way.

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

Then a fixed length string is even better for them.

> 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 

No, there is no real world chance for a collision.  Most of our crypto
world relies on hash functions.

> as necessary provoking implementation errors as all clients have to implement 
> the same.

Handling overlong strings is more prone to errors than a simple mapping.
Further only clients need to hash and clients need to hash anyway: For
example to compute the fingerprint.

> What is special about the selected mapping function (Z-Base-32 method as
>   76 described in [](#RFC6189), section 5.1.6.)?

z-base-32 is simply better than one of the other BASE-32 variants.  It
copes with human errors and (not relevant here) is able to encode the
length in bits.

> == Where does the "/hu" come from?

My guess is hashed user id.

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

You mean to use a HTTPS based protocol for the update?  This is not
sufficient because the system works by asserting mail addresses - which
can only be done by sending mails.  Mails are not commonly send via an
online protocol; but with the store-and-forward SMTP.

Even if parts of the protocol would use HTTPS, there will in any case be
a need to use SMTP/LMTP/IMAP/POP3 for the email confirmation.  Basing
the entire protocol on mail gives us queue management for free and
allows the use of air gaps.

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

The directroy and the update mechanism are independet of each other.
This is why the update mechanism could also be used for DANE for
OpenPGP.  I plan to add an "dane-only" policy flag to delcare that the
key won't be published in the 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.

Sorry, I do not understand this.  What we implement is indeed a
directory of all public keys availabale for a given domain.

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

Right, "web" refers to the web and its web servers which are currently
mostly accessed using the HTTPS protocol.  That may change though.

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

An OpenPGP key is a key (actually a collection of keys or a "keyblock")
and not a certificate.  In a standard key nothing is certified because
tehre are only self-signatures.

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

We are not doing X.509.  We are doing OpenPGP, which is almost always
used in a decentralized way.  Something which is not possible with
X.509.

Please do not try to push the term "certificate" again for PGP - it is
simply wrong and the experience has shown that the renaming, we did in
the Gpg4win manuals a logn time ago, was not helpful.  Thus it is time
to drop that term and use it only where it is technically correct
(e.g. recocation certificate)

> * Add an DANE rfc reference?

It is not referenced but only mentioned.  There are some strict rules
for writing RFCs (the current draft does not yet pass the nits check w/o
warnings).


Salam-Shalom,

   Werner


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