WKD: returns only one pubkey (and why)

[Simon Josefsson]

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

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

I think we can separate the use-cases even further like this:

  1) Use WKD to map ONE email address to ONE public key to use for
  sending email to that address (i.e., encrypt).

  2) Use WKD to find ALL public keys for an email address for verifying
  emails from that address (i.e., verify).

These are distinct use-cases and for 1) it is harmful to have more than
one key per e-mail address (which one to use?) but for 2) it is
important to be able to store more than one key per e-mail address.

I don't think we should recommend against doing key rollovers -- forever
keys are bad.  I don't think changing e-mail address when you change key
is realistic either.  So we have to live with key rollovers for the same
e-mail address.

While we could recommend doing hard-stop key rollovers where you revoke
the earlier key at the same time you migrate to the new key, I don't
think that is a common habit nor am I sure this is even a good idea.
Does anyone think we should recommend that?  It does have some
advantages (clear one-to-one mapping between e-mail address and key),
but comes with a high price (flag day).  During a key rollover, I think
it makes sense to have both the old and new key be valid, for verifying
signatures, for some time.

Personally, the reason I still have one valid RSA key and one valid
Ed25519 key is that I haven't been able to get my Ed25519 into some
environments, with reasons ranging from use of really old GnuPG
(savannah, now fixed) to key signature requirements (debian), and simple
inertia and time to replace trust settings in various systems.

When I migrate to some post-quantum-safe algorithm, I expect to do a
multi-year key rollover where my current Ed25519 key is still valid as
well.  It would be good if the WKD supported both use-cases 1) and 2) or
that we come up with some other solution for use-case 2) if WKD is
intended purely for use-case 1).

In fact, I would be happy to migrate to a post-quantum-safe algorithm
early if I could keep having my Ed25519 fall-back available in case
there is a problem with the new post-quantum-safe algorithm.  If it
doesn't work well to have two parallel keys, I would delay switching to
the new algorithm until use of it has become stable.  I didn't switch to
Ed25519 until 2019 for this reason, but it would be nice to be able to
experiment with new algorithms more easily.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230126/6103a83b/attachment-0001.sig>