Mailing List Archive

On Sat, Jul 9, 2022 at 11:09 AM Simon Josefsson via Gnupg-devel <
gnupg-devel@lists.gnupg.org> wrote:

> Hi
>
> I'm reading
>
> https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-14
>
> with the background that the OpenPGP web of trust has a problem that
> many services now do not offer non-selfsig of the keys they return,
> making it difficult to get hold of them and then build a web of trust
> confidence in the key that was retrieved.
>

The question of publishing the signatures of a public key, along with the
public key itself, is interesting. I never thought about it.
Now that I think about it, it seems to me that it is completely up to the
user how to export the key and how to publish it.
For example, instead of using a command like:

gpg --no-armor --export \
user@example.org > nmxk159crbcuk3imqiw13gkjmfwd8mqj

You can use a command like this to avoid exporting any signatures:

gpg --no-armor --export \
--export-options export-minimal \
user@example.org > nmxk159crbcuk3imqiw13gkjmfwd8mqj

By default, the signatures are exported with the public key. Or you can use
the option "export-clean" instead, in order to avoid exporting the
signatures that are not usable.
For more details see:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

My hope was there would (or: could) be guidance on this matter in this
> document, but I don't see any -- am I missing it?
>
> I think it would be nice if this topic should be discussed in the
> document, possibly as a security considerations and with
> recommendations.
>
> How about the following strawman that illustrate what I'm after?
>
> OpenPGP keys can contain signatures from others, that may aid in
> determining the trustworthyness of a certain key (the web of trust).
> Including these signatures in the published file is therefor
> RECOMMENDED. The primary reason for not doing so may be due to size
> constraints or when permission to publish a third-party personal
> identifier has not been granted.
>
> What do you think?
>

I agree that these things should be discussed and explained somewhere, in
user guides, tutorials, etc. But maybe not in the spec. The spec does not
even mention the command `gpg --export`, how can it describe and detail
export options?

Regards,
Dashamir

Dashamir Hoxha via Gnupg-devel <gnupg-devel@lists.gnupg.org> writes:

> The question of publishing the signatures of a public key, along with the
> public key itself, is interesting. I never thought about it.
> Now that I think about it, it seems to me that it is completely up to the
> user how to export the key and how to publish it.

Yes, that's how it looks today, and we could leave it at that and let
users decide this themselves, probably guided by tutorials or
implementation defaults. I changed my own way of doing things from
publishing a minimal key to one with signatures in it yesterday, so that
clients are able to get my non-self sigs in a reliable way now that key
servers are unreliable.

This feels a bit sub-optimal though. I think if my suggested text was
in the specification, we would likely end up with a better world than
without the text: one where the OpenPGP web of trust is slightly more
likely to work. I may be missing something though, so more discussion
would be good.

> I agree that these things should be discussed and explained somewhere, in
> user guides, tutorials, etc. But maybe not in the spec. The spec does not
> even mention the command `gpg --export`, how can it describe and detail
> export options?

The spec can speak about what data should go into the file, that's the
point of a specification. It shouldn't speak about
implementation-specific commands of course. Right now it says any
OpenPGP public key for the particular user is valid, but I don't think
it says anything either way about which sub-packets of that public key
are permitted, encouraged or forbidden in the WKD published data.

/Simon

On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel wrote:
> Dashamir Hoxha via Gnupg-devel <gnupg-devel@lists.gnupg.org> writes:
> > I agree that these things should be discussed and explained somewhere, in
> > user guides, tutorials, etc. But maybe not in the spec. The spec does not
> > even mention the command `gpg --export`, how can it describe and detail
> > export options?
>
> The spec can speak about what data should go into the file, that's the
> point of a specification. It shouldn't speak about
> implementation-specific commands of course. Right now it says any
> OpenPGP public key for the particular user is valid, but I don't think
> it says anything either way about which sub-packets of that public key
> are permitted, encouraged or forbidden in the WKD published data.

The preferred way to "export" the key data to publish via WKD (not by the
spec, but by WKD's inventor) is to use gpg-wks-client.

The point of WKD is that your trust in the domain owner replaces the nerdy
web-of-trust. WKD is supposed to provide small keys, not gigantic keys with
1000s of third-party signatures. But in the end it's up to you what you
publish. But don't expect gpg to import via WKD anything and everything you
publish, e.g. it strips all user IDs not matching the looked up email address
and it imports at most 5 keys.

Regards,
Ingo

On Sun, Jul 10, 2022 at 10:27 AM Ingo Klöcker <kloecker@kde.org> wrote:.

>
> The preferred way to "export" the key data to publish via WKD (not by the
> spec, but by WKD's inventor) is to use gpg-wks-client.
>

WKD and WKS are different things (as far as I know), so "gpg-wks-client" is
probably not a suitable name for the tool. It may cause some confusion to
the users.

The point of WKD is that your trust in the domain owner replaces the nerdy
> web-of-trust. WKD is supposed to provide small keys, not gigantic keys with


My understanding is that the point of WKD is to make public keys
discoverable automatically, thus being an alternative (or replacement) for
the keyserver infrastructure.
I don't see why it should replace the web-of-trust, even if it is nerdy.
Also I don't see why the keys should be small, as long as their size is
under the user's control.

1000s of third-party signatures. But in the end it's up to you what you
> publish. But don't expect gpg to import via WKD anything and everything
> you
> publish, e.g. it strips all user IDs not matching the looked up email
> address
> and it imports at most 5 keys.
>

Maybe it makes sense, but I still don't understand why it should strip the
other user IDs, even if they are useless or redundant.
Also I don't understand the meaning of "it imports at most 5 keys", and why
such a limit is necessary (or why it is a good practice).

Regards,
Dashamir

On Sonntag, 10. Juli 2022 13:11:50 CEST Dashamir Hoxha wrote:
> On Sun, Jul 10, 2022 at 10:27 AM Ingo Kl?cker <kloecker@kde.org> wrote:.
>
> > The preferred way to "export" the key data to publish via WKD (not by the
> > spec, but by WKD's inventor) is to use gpg-wks-client.
>
> WKD and WKS are different things (as far as I know), so "gpg-wks-client" is
> probably not a suitable name for the tool. It may cause some confusion to
> the users.

Well, WKS is a service providing keys via the WKD protocol. gpg-wks-client is
meant to be used with a WKS. Hence its name. Incidentally, it provides a
command for exporting a key suitable for uploading to a WKS (or some other WKD
provider).

> > The point of WKD is that your trust in the domain owner replaces the nerdy
> > web-of-trust. WKD is supposed to provide small keys, not gigantic keys
> > with
>
> My understanding is that the point of WKD is to make public keys
> discoverable automatically, thus being an alternative (or replacement) for
> the keyserver infrastructure.
> I don't see why it should replace the web-of-trust, even if it is nerdy.

It doesn't replace it, but, depending on your trust model, i.e. if you trust
the domain owner that only people controlling a certain email address for that
domain can upload OpenPGP keys for this email address, it can make the web-of-
trust superfluous.

> Also I don't see why the keys should be small, as long as their size is
> under the user's control.

Because I don't want to download 1000s of certifications by third-parties I
don't even know. But do as you wish.

> > publish. But don't expect gpg to import via WKD anything and everything
> > you
> > publish, e.g. it strips all user IDs not matching the looked up email
> > address
> > and it imports at most 5 keys.
>
> Maybe it makes sense, but I still don't understand why it should strip the
> other user IDs, even if they are useless or redundant.

Because WKD is a proof-of-control over an email address (if the domain owner
does it right). gpg takes note from where it imported a key/user ID and in the
future it might add a trust model that gives user IDs retrieved via WKD more
than "unknown" validity. Moreover, it prevents users from being tricked into
using wrong keys for some email addresses.

> Also I don't understand the meaning of "it imports at most 5 keys",

The "meaning" can be found in the source code. The code doing the import
simply ignores the rest of the data after five keys have been imported.

> and why such a limit is necessary (or why it is a good practice).

Why would you want to provide more than five keys for the same email address?
gpg will only ever use one of those keys when encrypting a message to some
email address. By the way, WKD recommends to provide only a single key. The
exception is also providing some older key(s) to ease certificate rollover.

Regards,
Ingo

Ingo Kl?cker <kloecker@kde.org> writes:

> On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel wrote:
>> Dashamir Hoxha via Gnupg-devel <gnupg-devel@lists.gnupg.org> writes:
>> > I agree that these things should be discussed and explained somewhere, in
>> > user guides, tutorials, etc. But maybe not in the spec. The spec does not
>> > even mention the command `gpg --export`, how can it describe and detail
>> > export options?
>>
>> The spec can speak about what data should go into the file, that's the
>> point of a specification. It shouldn't speak about
>> implementation-specific commands of course. Right now it says any
>> OpenPGP public key for the particular user is valid, but I don't think
>> it says anything either way about which sub-packets of that public key
>> are permitted, encouraged or forbidden in the WKD published data.
>
> The preferred way to "export" the key data to publish via WKD (not by the
> spec, but by WKD's inventor) is to use gpg-wks-client.

Does it export signatures of the key?

> The point of WKD is that your trust in the domain owner replaces the nerdy
> web-of-trust. WKD is supposed to provide small keys, not gigantic keys with
> 1000s of third-party signatures. But in the end it's up to you what you
> publish. But don't expect gpg to import via WKD anything and everything you
> publish, e.g. it strips all user IDs not matching the looked up email address
> and it imports at most 5 keys.

Yes, stripping all user IDs not matching the looked up email is
important, but does it strip signatures from others for that user ID?
That doesn't make sense to me, and I'd be surprised if it did?

/Simon

On Montag, 11. Juli 2022 12:29:44 CEST Simon Josefsson wrote:
> Ingo Kl?cker <kloecker@kde.org> writes:
> > On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel
wrote:
> >> Dashamir Hoxha via Gnupg-devel <gnupg-devel@lists.gnupg.org> writes:
> >> > I agree that these things should be discussed and explained somewhere,
> >> > in
> >> > user guides, tutorials, etc. But maybe not in the spec. The spec does
> >> > not
> >> > even mention the command `gpg --export`, how can it describe and detail
> >> > export options?
> >>
> >> The spec can speak about what data should go into the file, that's the
> >> point of a specification. It shouldn't speak about
> >> implementation-specific commands of course. Right now it says any
> >> OpenPGP public key for the particular user is valid, but I don't think
> >> it says anything either way about which sub-packets of that public key
> >> are permitted, encouraged or forbidden in the WKD published data.
> >
> > The preferred way to "export" the key data to publish via WKD (not by the
> > spec, but by WKD's inventor) is to use gpg-wks-client.
>
> Does it export signatures of the key?

From a quick glance at the code third-party signatures seem to be included in
the export. And that makes sense because you probably want to publish your own
cross-certifications when you do a key rollover.

Regards,
Ingo

Ingo Kl?cker <kloecker@kde.org> writes:

> On Montag, 11. Juli 2022 12:29:44 CEST Simon Josefsson wrote:
>> Ingo Kl?cker <kloecker@kde.org> writes:
>> > On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel
> wrote:
>> >> Dashamir Hoxha via Gnupg-devel <gnupg-devel@lists.gnupg.org> writes:
>> >> > I agree that these things should be discussed and explained somewhere,
>> >> > in
>> >> > user guides, tutorials, etc. But maybe not in the spec. The spec does
>> >> > not
>> >> > even mention the command `gpg --export`, how can it describe and detail
>> >> > export options?
>> >>
>> >> The spec can speak about what data should go into the file, that's the
>> >> point of a specification. It shouldn't speak about
>> >> implementation-specific commands of course. Right now it says any
>> >> OpenPGP public key for the particular user is valid, but I don't think
>> >> it says anything either way about which sub-packets of that public key
>> >> are permitted, encouraged or forbidden in the WKD published data.
>> >
>> > The preferred way to "export" the key data to publish via WKD (not by the
>> > spec, but by WKD's inventor) is to use gpg-wks-client.
>>
>> Does it export signatures of the key?
>
> From a quick glance at the code third-party signatures seem to be included in
> the export.

Indeed, then this implementation is behaving like I would want it to,
and what is missing is guidance in the specification so that other
implementations will behave the same.

> And that makes sense because you probably want to publish your own
> cross-certifications when you do a key rollover.

It would be possible to separate third-party signatures from
cross-certifications, but I don't think that should be done.

/Simon

On Mon, 11 Jul 2022 13:24, Ingo Klöcker said:
> From a quick glance at the code third-party signatures seem to be included in
> the export. And that makes sense because you probably want to publish
> your own

No, they should not be included. gpg-wks-cleint uses

--export-options export-minimal which does

Export the smallest key possible. This removes all signatures except
the most recent self-signature on each user ID. This option is the
same as running the --edit-key command "minimize" before export
except that the local copy of the key is not modified. Defaults to
no.

I could imagine to add a feature to keep third-party signatures from
keys which are flagged with fully trust. However, this leaks the
owneertrust information which we try to keep local.

A reliable keyserver network with lookup only by fingerprint seems to be
a better solution to me.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On Mon, Jul 25, 2022 at 03:27:17PM +0200, Werner Koch via Gnupg-devel wrote:
> On Mon, 11 Jul 2022 13:24, Ingo Klöcker said:
> > From a quick glance at the code third-party signatures seem to be included in
> > the export. And that makes sense because you probably want to publish
> > your own
>
> No, they should not be included. gpg-wks-cleint uses
>
> --export-options export-minimal which does
>
> Export the smallest key possible. This removes all signatures except
> the most recent self-signature on each user ID. This option is the
> same as running the --edit-key command "minimize" before export
> except that the local copy of the key is not modified. Defaults to
> no.
>
> I could imagine to add a feature to keep third-party signatures from
> keys which are flagged with fully trust. However, this leaks the
> owneertrust information which we try to keep local.

What about using attestation signatures? Only signatures that have been
attested to would be published.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

On Mon, 25 Jul 2022 13:10, Demi Marie Obenour said:

> What about using attestation signatures? Only signatures that have been
> attested to would be published.

This is some proposed feature but not implemented. I Actually doubt
that it makes sense. The public web of trust is more or less dead and
it has inherent problems scalability. In well defined setting it still
makes sense but attestation signature are then not needed.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Am Montag 25 Juli 2022 15:27:17 schrieb Werner Koch via Gnupg-devel:
>  gpg-wks-client uses
>
>   --export-options export-minimal which does
>
>    Export the smallest key possible. This removes all signatures except
>    the most recent self-signature on each user ID.

> I could imagine to add a feature to keep third-party signatures from
> keys which are flagged with fully trust.  However, this leaks the
> owneertrust information which we try to keep local.

I can also see that adding third party signatures to a pubkey
delivered by WKD is good.

It needs a way for users to control which signatures,
which the simplest would be all in my keyring up to a limit in numbers.
(This has the drawback that I cannot just update my own pubkey from
keyservers without some attendance. But I guess I shouldn't do this blindly
anyway.)

> A reliable keyserver network with lookup only by fingerprint seems to be
> a better solution to me.

Both would profit from each other.
(I think the web of trust still has some merits, although in a new form.)

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