WKD: User ID filtering
wiktor at metacode.biz
Thu Jun 21 10:16:56 CEST 2018
Yes, it's obvious in retrospect, but when implementing it from the spec
it's far to easy to take the shortcut of "just fetch the binary key from
that URL and import it to local keyring".
I did it in my two implementations of WKD clients and as far as I've
read the source code of EnigMail it does that too (imports the entire
key without filtering).
Your addition to security considerations will be greatly appreciated.
I assume that if after filtering the key does not contain any UIDs the
import is rejected.
> That key is
> then stored in the local public keyring along with a flag that the
> user id has been retrieved via WKD.
Is that flag used for anything or just informational?
Because fetching via WKD at least "validates" the e-mail part and this
information is useful.
Thank you for your time!
W dniu 21.06.2018 o 09:39, Werner Koch pisze:
> On Wed, 20 Jun 2018 22:06, gnupg-devel at gnupg.org said:
>> Is this by design?
> Yes, this by design of the protocol. The protocol asserts via TLS that
> a user id is managed by a certain domain (i.e. mail provider). client
> connects to the domain of a user id and looks up the key. That key is
> then stored in the local public keyring along with a flag that the user
> id has been retrieved via WKD.
>> Should this behavior be documented/recommended in the I-D?
> I though this was obvious. I will add this to the security
> | The mail provider MUST make sure to filter a key in a way that only
> | the User ID belonging to that user is returned and that confirmation
> | requests are only send for such User IDs. It is further recommended
> | that a client filters the key for a publication requests so that only
> | a key with the specific User ID of the provider is send.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel