Question to WKD-Feature

[Bernhard Reiter]

Hi Peter,

Am Dienstag 25 Oktober 2016 18:47:13 schrieb Peter Fischer:
> we want to adapt the WKS-Request by an Proxy to our HKP-Interface.

it is very cool that you are considering WKD and WKS for mailbox.org!
The requesting part is one important step forward.
I hope the managing and email client parts will follow soon. :)

> e.g. form:
> https://pgp.mailbox.org/pks/lookup?op=get&search=pefi@mailbox.org
> (response the active pub-key of this mailalias)
> to:
> https://mailbox.org/.well-known/openpgpkey/32bitsofsha1hashofmailalias
>
> In this mind, we have some question to the WKD-standard:

According to what I know pgp.mailbox.org will only return one key.
It seems to be implemented with Bounce Castle, it should be easy to 
add an option for a binary output.

> According to:
> <https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-02#sectio
> n-3.1>
> "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".

Werner?

> Q2: Why do you build the URL for the public keys with SHA1-hash of the
> local-part?

This has been discussed a bit already, a short answer from
https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Ask_the_mail_service_provider_.28MSP.29

"The reason for using this encoding instead of a standard hex encoding is to 
visually distinguish such an item from a fingerprint. Furthermore, in 
contrast to Base-64 and other Base-32 encodings, z-Base-32 has been optimized 
for easier human use. "

In addition we are avoiding problems with transformations for all intermediate 
components (see disregarded alternative):
https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Using_URL_encoding_in_the_request

>  * Are SHA1 hash-collisions theoretically possible (special on large
> userbases) ?

Let's consider each person on earth had an email address with one provider, 
we would have little less than 2**33 addresses. Sha1 has 2**160 possibilities.
An approximation of the probability of an accidential clash if the 
distribution is even should be
def d(n, d):
  return 1 - math.exp(-n**2/(2*d))
d(2**54, 2**160) give me 1.11 e-16 probability. So it is very unlikely we run
into trouble this way. However researchers claim to be able to find collisions
much easier (2**63 computation says wikipedia). Frankly I don't know
what that does to the probability. However I doubt that an email provider
will allow anything near that number of tries for choosing an email 
addresse. ;)

>  * What about lower-casing all upper-case ASCII characters in
> local-part?

Thats already in the spec: draft-02, Section 3.1 "Key Discovery"
"all upper-case ASCII characters in a User ID are mapped to lowercase."

> Maybe encoding base64, for forward and backward lookup of 
> the local-part?

See reasons given above.

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

Personally I'm not sure if we should all design thoughts into the spec
itself. My aim is to record the most important ones on the wiki (linked 
above). I've not added the idea of file system robustness, because I don't 
believe this a major argument (most filesystems can deal with a lot of 
names). Fix length is another minor argument, I haven't recorded.

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

I guess someone could map an url part to a subdirectory and vice versa.
So the "hu" for "hashed-userid" is a separator against other functions of this 
interface. So why not?

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/20161026/7d0c4a17/attachment.sig>