Re: [openpgp] Embedded TPK subpacket

Justus Winter <> Mon, 25 March 2019 12:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F9A51203E3 for <>; Mon, 25 Mar 2019 05:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qlX3DOJL6_Im for <>; Mon, 25 Mar 2019 05:51:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBD41120403 for <>; Mon, 25 Mar 2019 05:51:38 -0700 (PDT)
Received: by with SMTP id y7so5879362wrn.11 for <>; Mon, 25 Mar 2019 05:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=zuivPlRcbMxAnL0cq+37zQ0jABAu4l/wEyNB1TRE/fs=; b=m6cNHXlvn7hF6rlNumDm5KiCqHB0iUjBpSvGugbwWcwmzBgyTUou90bFVJoh/9z+yx vXBC2ClWCiAl7sh/qw5Z3+/5FzT4GvsTAqqfibFWflqbElr/AmaDkSfIJ7lQA/CsXPjv QbvvAuuHfWVLjmygxsyLofiNuSDKxjpN/yxTHUjmc6yaJWxpGwApe78b5McPF1tKw2to Qzv/j/54Ud87ZGG0BQD5AZmd9b43IQicy0uyNyfackmKXWCLBVTNnyKVD9USlB/CThc1 pGDcgHsatCZcUaWrKVjF9ITFyWNFMSpR4iDolyhvgxmdS84+KRqbhYklNOGb/lZ8bvKo aQ/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=zuivPlRcbMxAnL0cq+37zQ0jABAu4l/wEyNB1TRE/fs=; b=qZhg0mc7cfY4xz6VOK0y63Wj9N60TDtD1akCGCiABNMgaSzi/RdmzEZKavQkNbT5DK yDkfjZjxj2GCl9mBY5BM9TB1jVZy3FxdJNcMvDpMogbRUxUbgrxEE/OO5wX4URp7uptX rDRQ9Ir7mBMpIORtJTOYeOlIrHE2zUnpXMgv+WUjUAUsmMLv+Tw/575GyztfSOa0KYLu XEWO/GLS2yNlNroPPryPhkbx44oxKn0nAs+rCkP8/tNxB09lJ9iZDROUkvuo+cONQHtG yJdcjjHjmdVAXKdLYRnXoWPO6gImuzq9FfW1YESiZlhdf4WyvwKI+rOBXXpiQshSyhJ8 HCfA==
X-Gm-Message-State: APjAAAWvQ7s0ZBPvau+Z75021RCBeTKPuNm0L/GdMOyl40HcohAGVj5F UiUJNah4f4m27SZF8mTClRtIqvua
X-Google-Smtp-Source: APXvYqz8pxSpKqJ5q5SUFzN40hE5UJJq3jLJBBVjNmMUMof2iFH8MtMnh3LFV2k0bYrJISCcJA2/dA==
X-Received: by 2002:adf:f1c6:: with SMTP id z6mr15111866wro.232.1553518297367; Mon, 25 Mar 2019 05:51:37 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id z11sm5680446wmf.12.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 05:51:36 -0700 (PDT)
From: Justus Winter <>
To: Vincent Breitmoser <>
Cc: Marcus Brinkmann <>,
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 25 Mar 2019 13:51:35 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] Embedded TPK subpacket
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2019 12:51:41 -0000

Vincent Breitmoser <> writes:

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

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.

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

"get minimal own public key" according to 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...)