WKD: returns only one pubkey (and why)

[Werner Koch]

Hi Simon,

>>>  1) Use WDK to map ONE email address to ONE public key to use for
>>>  email.
>>>
>>>  2) Use WDK to find ALL public keys for an email address.

> I'm not familiar with WKS so I don't have an opinion -- it looks like
> WKS was tailored towards the use-case 1) above, and I'm not sure a

Right.  I think that it is in general not a good idea to have several
keys for the same mail address.  How should a user know which key use
for a given mail address to use.  A use case would be to help migrating
to a new public key algorithm, like we did with ed25519 in the past.  In
that case having two entirely separate keys for the same mail address
makes sense.

> WKS-like protocol is useful for the use-case of 2) at all.  It is not
> important for me at least: I just want to self-publish all trusted keys
> for my email address and have a protocol to specify that people should

Actually you can do this, but we don't have the tooling to upload such a
ket without manual intervention.  Here is a test case:

I created an rsa1024 test key for dewey at test.gnupg.org, exported it in
binary format and then added it to the already existing key for
dewey at test.gnupg.org on the server:

  $ gpg-wks-client --print-wkd-hash dewey at test.gnupg.org
  1g8totoxbt4zf6na1sukczp5fiewr1oe dewey at test.gnupg.org

  $ cat newtestkey.gpg >> \
    /var/www/all/test.gnupg.org/htdocs/.well-known/openpgpkey/hu/1g8totoxbt4zf6na1sukczp5fiewr1oe

Then on the client you can test this:

  $ gpg --locate-external-key -v dewey at test.gnupg.org
  gpg: connection to the dirmngr established
  gpg: pub  ed25519/D19D22B06EE78668 2016-06-28  dewey at test.gnupg.org
  gpg: key D19D22B06EE78668: public key "dewey at test.gnupg.org" imported
  gpg: pub  rsa1024/5CEC38D7F995FB4E 2023-01-26  dewey at test.gnupg.org
  gpg: key 5CEC38D7F995FB4E: public key "dewey at test.gnupg.org" imported
  gpg: Total number processed: 2
  gpg:               imported: 2
  gpg: auto-key-locate found fingerprint 64944BC035493D929EF2A2B9D[..]
  gpg: automatically retrieved 'dewey at test.gnupg.org' via WKD
  pub   ed25519 2016-06-28 [SC] [expires: 2030-01-01]
        64944BC035493D929EF2A2B9D19D22B06EE78668
  uid           [ unknown] dewey at test.gnupg.org
  sub   cv25519 2016-06-28 [E] [expired: 2018-11-26]
  sub   cv25519 2018-08-28 [E] [expired: 2021-08-27]

  $ gpg -k dewey at test.gnupg.org
  pub   ed25519 2016-06-28 [SC] [expires: 2030-01-01]
        64944BC035493D929EF2A2B9D19D22B06EE78668
  uid           [ unknown] dewey at test.gnupg.org
  
  pub   rsa1024 2023-01-26 [SC] [expires: 2025-01-25]
        382C8F84FB9FE0F89E61B3045CEC38D7F995FB4E
  uid           [ unknown] dewey at test.gnupg.org
  sub   rsa1024 2023-01-26 [E]
  

Both keys have been retrieved (filtered to have only the requested user
id) and the best matching key has been listed.  With an implementation
w/o support for ed25519 the RSA key would have been listed.

So far with the theory and here comes the bug:  There is no valid encryption
subkey and thus --locate-external-key should indeed list the rsa key.
See https://dev.gnupg.org/T6358 .



Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230126/00a44d28/attachment.sig>