WKD spec, draft 05

[Bernhard Reiter]

Am Freitag 05 Januar 2018 13:13:37 schrieb Werner Koch:
> >  that the draft should state that the server MUST prevent walking
> >  the list of available pubkeys for privacy reasons, for instance by
> > disabling the directory display function of a web server.
>
> These are public keys and testing for their existence is trivial as it
> it with all mail addresses.  

The problem ist not the pubkeys, but it can be used to detect all existing
email addresses of an email domain (that have pubkeys). An advantage 
of WKD is that you do not need to publish your email address to everyone
and it would get lost if people publish all the email addresses' pubkeys at 
once.

> If someone wants to add an index file for this it is at their discretion
> and we should not impose a restriction on this.

I agree that it could be used in a good way, if done deliberately. So I was 
undecided over "MUST" or "SHOULD NOT" at first. Overal I like to design for 
the simple case and prevent unthoughtful default configuration and later in 
the wild use. I guess a number of sites will have a directory listing enabled 
by default, so I'd rather give them a clear hint to disable it. And sites you 
actually want to publish a list of the email addresses they serve should be 
required to do extra efforts. In addition I do not want WELLKNOWN/hu/ to 
become an interface to find all pubkeys for an email domain.
So I'm favouring the "MUST" now.

> A SHOULD NOT would be okay, though. 

Adding a "SHOULD NOT" and a mention in the security considerations is an 
improvement, thanks for adding it!

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180108/f24eea47/attachment.sig>