Re: [openpgp] Embedded TPK subpacket

[Justus Winter <[e-mail]>]

Hi Marcus :)

thanks for the prompt answer!

Marcus Brinkmann <marcus.brinkmann=[e-mail]>
writes:

> This is a bit awkward if you only want to do encryption (there is no
> subpacket then).  Some think one should always encrypt and sign, but the
> issue at least needs to be raised and considered.

That is true.  For me, not-sign-then-encrypt is not such a prominent
use case.

Note that this only concerns the key-gossiping use case.  Distributing
the revoker's TPK with revocations is always possible.

> Can you clarify what keys are allowed as embedded TPKs?  Just the
> signing key for that signature, or arbitrary keys?

Arbitrary keys.

> If the latter (for example to allow more use cases such as key
> rollover), then the new subpacket would be the first subpacket not to
> have any relationship to the signature it is contained in, which would
> be awkward.

Really?  Plenty of signature subpackets deal with keys, user
preferences, or can simply contain arbitrary data (notations).

> It would also potentially allow interesting attack vectors (injecting
> arbitrary keyring data).

GnuPG's keyring is uncurated, and it uses trust models to compute the
validity of userid,key-bindings.  Similar, Sequoia's keystore can
contain keys that have no bindings.

> Also, as you said, there are already some ways to transfer public keys
> in email as attachment or header.  Some email readers already look in
> these places and have a GUI to import these keys.  You say your proposal
> requires no cooperation by the MUAs, but this seems to rely on very
> narrow trust models not requiring any user interaction.  Maybe you can
> expand on that topic a bit?  Are the existing mechanisms obsoleted by
> it, or is it an alternative?  If the latter, can your proposal be
> extended to cover existing use cases?

My proposal is ment to obsolete the existing mechanisms.  The fact that
we now have multiple incompatible mechanisms is a bit sad, and I'm
trying to extend OpenPGP so that we can have interoperable
implementations again.

By requiring no MUA cooperation I ment to say "no MUA modifications
other than the usual PGP integration".  For example, if you look at
Autocrypt, implementing it means that the MUA needs to do a lot of
low-level key manipulations.  As I see it, this is much more work than
what is already done for many MUAs.  My proposal aims at bringing the
key gossiping to MUAs without requiring further modifications.

> The embedded key can contain signatures, and these signatures can again
> have embedded keys.  This would allow for arbitrary recursion, which
> from experience makes for interesting bugs.  Maybe you can add some
> considerations for that to your proposal?

I don't see that as too problematic.  We already have embedded
signatures, which can contain embedded signatures, and it doesn't seem
to be a problem there.


Cheers,
Justus