Subject: [openpgp] Embedded TPK subpacket

From: Justus Winter <[email-masked]>
Date: Mon, 25 Mar 2019 10:20:45 +0100

Hello,

I'd like to propose a new signature subpacket that contains a TPK,
let's call it the Embedded TPK subpacket.

I see two immediate use cases:

  - If a designated revoker creates a revocation signature, she can
    embed her TPK in the signature, so that it is easy to verify the
    revocation without having to hunt for her TPK.

  - Some MUAs attach TPKs to emails, pEp does so too, and Autocrypt
    includes TPKs in mail headers.  Instead of doing that, one could
    then transmit ones TPK (and those of others in the conversation)
    in-band.  This has the advantage of requiring no cooperation of
    the MUAs, and the PGP implementations can gather the TPKs when
    parsing the signatures.

Thanks,
Justus

---

From: Marcus Brinkmann <[email-masked]>
Date: Mon, 25 Mar 2019 10:46:12 +0100

Note: I am assuming TPK means transferable public key.  Some issues that
spring to mind and that you may want to consider in your proposal:

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.

Can you clarify what keys are allowed as embedded TPKs?  Just the
signing key for that signature, or 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. It would also
potentially allow interesting attack vectors (injecting arbitrary
keyring data).  If only some keys are allowed, it needs to be specified
which and how they are verified.

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?

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?

Thanks,
Marcus

On 3/25/19 10:20 AM, Justus Winter wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
> 

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann

---

From: Justus Winter <[email-masked]>
Date: Mon, 25 Mar 2019 11:48:09 +0100

Hi Marcus :)

thanks for the prompt answer!

Marcus Brinkmann <marcus.brinkmann=[email-masked]>

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

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

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

> 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

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 25 Mar 2019 13:25:52 +0100

> trying to extend OpenPGP so that we can have interoperable

So what your proposal brings to the table is in-band key distribution without
MUA involvement, but hinges on the use of signed-only mails. Given the rather
terrible state of signed-only messages, which is likely what caused both
Autocrypt and PEP to omit support for them, I'm sceptical of this approach's
potential to do much for the unification of key distribution mechanisms.

Some more context: I chose to actively discourage signed-only mails in K-9 Mail,
due to 1) the friction they cause with recipients ("your mail contained a weird
attachment, is this a virus?"), and 2) limited usefulness in practice due to
brittle reliability and non-existent network effect.

That said, I can definitely see how self-contained signatures could be useful to
have for this and other purposes!

> For example, if you look at Autocrypt, implementing it means that the MUA
> needs to do a lot of low-level key manipulations.

Can you elaborate on this? We designed Autocrypt to be as agnostic of OpenPGP
implementation details as possible, especially for public key management it can
get away with treating keys as opaque bytes blobs. IINM the required API from an
OpenPGP implementation should be complete with just "get minimal own public
key", "check TPK integrity", and "encrypt to keys (given as blobs)". In practice
OpenPGP support in MUAs tends to be more involved than that, but I don't think
there is an actual "need" for that.

 - V

---

From: Marcus Brinkmann <[email-masked]>
Date: Mon, 25 Mar 2019 13:26:59 +0100

> preferences, or can simply contain arbitrary data (notations).

I haven't done an exhaustive analysis, but on a first glance those seem
to be related to the signature. For example, user preferences are part
of binding signatures.

> contain keys that have no bindings.

GnuPG's keyring was very helpful in my enigmail signature spoofing
attack [1]. Just saying :)

[1] https://neopg.io/blog/enigmail-signature-spoof

Thanks,
Marcus

---

From: "Neal H. Walfield" <[email-masked]>
Date: Mon, 25 Mar 2019 13:38:45 +0100

Hi Vincent,

On Mon, 25 Mar 2019 13:25:52 +0100,
> potential to do much for the unification of key distribution

This is *one* of the things that this proposal can help with.  Note:
in the context of Autocrypt, this could help with "autocrypt gossip";
I don't foresee it replacing autocrypt headers.

> 2) limited usefulness in practice due to

I agree that they *currently* have limited usefulness.  But, if
companies started to actually sign their outgoing mail, this could
help combat phishing.  I think we should consider both the future's
potential and today's limitations, and not be driven be either
exclusively.

---

From: Justus Winter <[email-masked]>
Date: Mon, 25 Mar 2019 13:51:35 +0100

Vincent Breitmoser <[email-masked]> writes:

> MUA involvement, but hinges on the use of signed-only mails.

Why would it be restricted to sign-only messages?  My proposal also
works with OpenPGP's usual sign-then-encrypt messages.  Marcus'es point
was about it not working with encrypt-only messages.

> there is an actual "need" for that.

"get minimal own public key" according to
https://autocrypt.org/level1.html#openpgp-based-key-data seems pretty
involved to me.  I'd be surprised if one can even implement that using
the various OpenPGP implementations out there.  Same for the filtering
of keys to be gossiped.

(I just noticed that I cannot do Autocrypt with my key because my
primary key is not signing-capable...)

Justus

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 25 Mar 2019 15:31:58 +0100

> was about it not working with encrypt-only messages.

I didn't think it would be restricted to that, but I assumed this would be
a common purpose for the mechanism given you were talking about obsoleting key
management/discovery schemes.

> the various OpenPGP implementations out there.  Same for the filtering

Well, "export minimal public key" functionality should probably be part of
a general purpose OpenPGP implementation. You're right that it might be tricky
to get this particular flavor right, but it's not super important to have the
exact structure in practice (however, see below).

> primary key is not signing-capable...)

Indeed, we should change that to a SHOULD. Looking at it now I'm surprised we're
so strict there, it's good to have a proper recommendation but any minimal key
format should be at least acceptable there. Thanks for the hint, I'll make
a PR :)

 - V

(I'll drop this line of questioning here since it's not really on topic)