Re: [openpgp] WKD for OpenPGP certificate "Intevation File Distribution Key <[e-mail]>"

[Daniel Kahn Gillmor <[e-mail]>]

[ Adding [e-mail] as i think this discussion is more
  standards-relevant, and is not just gpg4win-specific ]

On Mon 2019-08-05 13:32:33 +0200, Thomas Arendsen Hein wrote:
> The WKD RFC does not allow publishing multiple keys for the same
> email address, unless all but one of they keys has been revoked.
>
> But it makes sense to only publish the new key, so I just replaced
> it.

Thanks for updating the key!

I read
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-5
and i can see how to read it via your interpretation, but i confess i
read it with some ambiguity:

   The HTTP GET method MUST return the binary representation of the
   OpenPGP key for the given mail address.  The key needs to carry a
   User ID packet ([RFC4880]) with that mail address.  Note that the key
   may be revoked or expired - it is up to the client to handle such
   conditions.  To ease distribution of revoked keys, a server may
   return revoked keys in addition to a new key.  The keys are returned
   by a single request as concatenated key blocks.

So when i read this, i think the MUST applies to the fact that a binary
representation of the key needs to be present in the HTTPS response
body, but other material can also be included.

I don't see any constraint like "MUST NOT return multiple non-revoked
keyblocks", and i *do* see "it is up to the client to handle such
conditions…" which makes me think that clients will need to understand
what to do if multiple non-revoked OpenPGP certificates are returned
anyway.

What should a sensible OpenPGP client do if it encounters this case?

Even if there was a "MUST NOT" added, what should a sensible OpenPGP
client do if it encounters such a response?  reject all the
certificates?  take only the first non-revoked one?  take only the last
non-revoked one?  take the one with the most recent creation date that
has algorithms that the local implementation can handle?

What if two subsequent queries to the WKD endpoint (within an hour of
each other, let's say) return different certificates?  what should a
client do?

> Andre, do you think it would be helpful to keep old keys available
> via WKD? If yes, either the WKD RFC needs to be adjusted (which
> possibly can be helpful for people having multiple keys, too, e.g.
> ed25519 and a more compatible fallback rsa3072 key, or during key
> rollover when emails are still signed with the old key, but a new
> key already is available)

I think it would be concretely useful in cases of a planned key
transition to be able to return multiple still-valid certificates via
WKD.

> or we need to use different email addresses,
> e.g. distribution-key+2016@... for a key generated in 2016.

Please don't resort to this approach.  E-mail addresses should establish
a constant long-term identity.

  --dkg