Mailing List Archive

Only one pubkey to be delivered by WKD (Re: Update keys.gnupg.net?)
Am Mittwoch 28 Juli 2021 12:28:08 schrieb Simon Josefsson via Gnupg-devel:
> It seems like a
> neat thing to have all my keys in there, in case someone wants to verify
> old signatures.  Is this forbidden? As far as I can tell from wks draft
> -12 it is permitted: 'Note that the key may be revoked or expired - it
> is up to the client to handle such conditions.'.

Yes, in my reading it is "forbidden" to have more than one non-revoked pubkey
in a WKD reponse.

Citing from
https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/

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.

It is singular "the key" and "in addition to a new key".

Additionally ss Werner wrote: it would defy the purpose otherwise. :)

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
Re: Only one pubkey to be delivered by WKD (Re: Update keys.gnupg.net?) [ In reply to ]
Bernhard Reiter <bernhard@intevation.de> writes:

> Am Mittwoch 28 Juli 2021 12:28:08 schrieb Simon Josefsson via Gnupg-devel:
>> It seems like a
>> neat thing to have all my keys in there, in case someone wants to verify
>> old signatures. ?Is this forbidden? As far as I can tell from wks draft
>> -12 it is permitted: 'Note that the key may be revoked or expired - it
>> is up to the client to handle such conditions.'.
>
> Yes, in my reading it is "forbidden" to have more than one non-revoked pubkey
> in a WKD reponse.
>
> Citing from
> https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/
>
> 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.
>
> It is singular "the key" and "in addition to a new key".

The start of the paragraph talks about 'the key' but the end of the
paragraph talks about 'the keys', in plural. I don't think it is
terribly clear that it MUST NOT be more than one key. What is the
problem with serving more than one key? It seems like a useful thing to
do during key roll-over, or even during extended periods to make it
easier for people to verify older signatures.

/Simon
Re: Only one pubkey to be delivered by WKD (Re: Update keys.gnupg.net?) [ In reply to ]
Am Mittwoch 28 Juli 2021 17:36:54 schrieb Simon Josefsson via Gnupg-devel:
> he start of the paragraph talks about 'the key' but the end of the
> paragraph talks about 'the keys', in plural.

In context that makes sense, because the revoked keys are added to "the key".
(In my reading it is fine, that this is why you are given feedback. :) )

> I don't think it is terribly clear that it MUST NOT be more than one key.

Thanks for pointing this out, I think Werner will clarify this further
in the next draft revision.

> What is the problem with serving more than one key?

The idea is to find the one key that the owner of that email address
want to get emails (and potentially other communication) encrypted and send to
right now.

There is quite some discussion about the design rationale in the wiki, e.g.
https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept

> It seems like a useful thing to
> do during key roll-over, or even during extended periods to make it
> easier for people to verify older signatures.

Those problems are not fully addressed (yet) by WKD.
We wanted to start lean and solve the most important use case now:
Sending emails to new communication partners with good user experience.

It is thinkable to enchange WKD for more use-cases in the future.
To discuss the rollover situation a bit:
Of course you will sign the new pubkey with your old one
and then put it up on your WKD. Now a person that already
has your old pubkey can verify the new pubkey with the signature
and does not need the old one. On the other hand, if you do not have the old
pubkey, it does not help to get it for trusting the new one.

For signatures that does not work. One way could be to also sign
the old key with the new pubkey, so if you can discover the old key
via other methods, you can transfer a bit of trust.

Two more ideas:
1. You could use a second email address and a second pubkey for this,
if you need to have completely different pubkeys.
2. You could, in theory, deliver different pubkeys with each WKD request you
get, and if they are all cross-signed, others would discover them over time.
>;) (Okay, that is a bit too inventive I guess, you probably should'nt do
this, but just pointing it out)

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