[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: WKD: returns only one pubkey (and why)
From:       Bernhard Reiter <bernhard () intevation ! de>
Date:       2023-01-26 10:04:32
Message-ID: 202301261104.39194.bernhard () intevation ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Werner,

Am Donnerstag 26 Januar 2023 09:42:24 schrieb Werner Koch via Gnupg-devel:
> > 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:

> Then on the client you can test this:

> Both keys have been retrieved 

for my understanding, this technical test case
tests something that is outside the specification of 
https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-15#name-key-discovery
?
(the current specification, as cited in the start of the discussion)

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

Looks like an example how distributing two active keys via WKD
make it more complicated to implement use case 1).
And a for a rollover, just the new public key could be distributed,
so I'd say multiple pubkeys are not necessary for the rollover.

Regards
Bernhard

-- 
https://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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel


[prev in list] [next in list] [prev in thread] [next in thread]