Mailing List Archive

Third-Party Confirmation signature?
Howdy,

Is there a way to create a "Third-Party Confirmation signature"[1]
using the gnupg command line interface?

[1]: https://tools.ietf.org/html/rfc4880#section-5.2.1 (see "0x50:
Third-Party Confirmation signature.")

Thanks,
Daniel

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Third-Party Confirmation signature? [ In reply to ]
On Mon, 8 Jul 2019 18:45, gnupg-users@gnupg.org said:

> Is there a way to create a "Third-Party Confirmation signature"[1]
> using the gnupg command line interface?

No. You need to add code for this which also requires that you have a
way to specify another signature packet.

Are you considering to use 0x50 self-signatures to approve key
signatures?


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Third-Party Confirmation signature? [ In reply to ]
Hmmm, ok.

Yes, I am considering ways of letting a user "whitelist" signatures on
their public key, and using the Signature Target subpacket[1] seemed
like a way to do that.

However, if gpg doesn't support a way of adding that subpacket, then
creating easy-to-copy-and-paste commands for users to use to approve
signatures becomes difficult.

What about using the Notation Data subpacket[2] to provide a pointer
to a target signature that is "approved"? I noticed in the edit-key
interface there is an option for setting notations[3]. Could a user
use gpg's edit-key to create a signature on their key that has a
notation specifying the whitelist of approved third party signature
key-ids?

[1]: https://tools.ietf.org/html/rfc4880#section-5.2.3.25
[2]: https://tools.ietf.org/html/rfc4880#section-5.2.3.16
[3]: https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html#index-keyedit_003anotation

Thanks for the reply,
Daniel


On Tue, Jul 9, 2019 at 5:20 AM Werner Koch <wk@gnupg.org> wrote:
>
> On Mon, 8 Jul 2019 18:45, gnupg-users@gnupg.org said:
>
> > Is there a way to create a "Third-Party Confirmation signature"[1]
> > using the gnupg command line interface?
>
> No. You need to add code for this which also requires that you have a
> way to specify another signature packet.
>
> Are you considering to use 0x50 self-signatures to approve key
> signatures?
>
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Third-Party Confirmation signature? [ In reply to ]
On Tue, 9 Jul 2019 10:10, gnupg-users@gnupg.org said:

> However, if gpg doesn't support a way of adding that subpacket, then
> creating easy-to-copy-and-paste commands for users to use to approve
> signatures becomes difficult.

The problem I see is that the keyservers need to check the validity of
the 0x50 signature first. Only this will allow them to distribute only
key-signatures which have veen approved buy the key owner.

If that has been achieved we can quickly add the required feature to
gpg.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Third-Party Confirmation signature? [ In reply to ]
On Tue, Jul 9, 2019 at 2:10 PM Werner Koch <wk@gnupg.org> wrote:

> The problem I see is that the keyservers need to check the validity of
> the 0x50 signature first. Only this will allow them to distribute only
> key-signatures which have veen approved buy the key owner.

Correct, a keyserver would need to validate signatures before
including them in the public API. However, when gossiping with peers,
they could still included the hashes of non-verified signatures so
they stay in sync with each other.

> If that has been achieved we can quickly add the required feature to
> gpg.

While adding the ability for 0x50 signatures would be nice, I would
still like to explore ways of users self-limiting signatures within
the existing gpg command line, since most users will be just using
whatever version is in their operating system repo or whatever version
they downloaded at the time of installation.

So it seems like Notation Data subpackets may be the way to go instead
of 0x50 Third-Party Confirmation signatures, since notations can be
added in the existing gpg edit-key interface.

I'll begin playing around with this interface to see what kind of user
experience is possible.

Thanks for the prompt responses!
Daniel

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Third-Party Confirmation signature? [ In reply to ]
On 2019-07-09 at 15:55 -0500, Daniel Roesler via Gnupg-users wrote:
> While adding the ability for 0x50 signatures would be nice, I would
> still like to explore ways of users self-limiting signatures within
> the existing gpg command line, since most users will be just using
> whatever version is in their operating system repo or whatever version
> they downloaded at the time of installation.


We are currently in a catch-22 situation, where neither clients nor
keyservers support such confirmation signatures.

However, clients will eventually update, while we will be stuck forever
supporting whatever format is devised. I think it's more important to
define the right packets, based on packet semantics and also for
performing on-the-fly validation.

The users will need an updated software for making a confirmation
signature anyway (even if it's just an extra shell script over gpg1), I
see little hassle in requiring gpg >= 2.2.18 instead. Specially taking
into account that receiving new (legitimate) sigs is an uncommon event.
It wouldn't be that bad if someone had to use a LiveCD in order to
incorporate a new signature, just as you may need to use a certification
key which you usually keep offline.
(It would be good if this prompted them to update their day-to-day
client, though)

Please go for the best solution in the longterm, not just the one which
is easiest to support with ancient clients for the sake of it.


Kind regards


PS: This is not an endorsement of one type over the other, I haven't
evaluated the merits of either option (yet).


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users