Re: [openpgp] Combining signature with signer's public key

"brian m. carlson" <sandals@crustytoothpaste.net> Fri, 11 December 2020 01:02 UTC

Return-Path: <sandals@crustytoothpaste.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E193A1382 for <openpgp@ietfa.amsl.com>; Thu, 10 Dec 2020 17:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vugLL3WWNgFd for <openpgp@ietfa.amsl.com>; Thu, 10 Dec 2020 17:01:59 -0800 (PST)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065103A1381 for <openpgp@ietf.org>; Thu, 10 Dec 2020 17:01:58 -0800 (PST)
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:b610:a2f0:36c1:12e3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 7B7D960769 for <openpgp@ietf.org>; Fri, 11 Dec 2020 01:01:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1607648484; bh=Kh3pgXTq9T5LfeiV3X6FqYd1GSy4YafdZmtppvnSwNg=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=e7MPZsbX3A7qAuhZzYmzQ1/pABwRt9YN+K0DA6EqvoHBVCWGBaMaYdlQEd404Zgap +N7E43WdU8S7k9fvr+Z07xEM2x9GKY3T/uPfnlh52ammHseh92NHqV0VqvxvDt3cCB O2T3Ut21PM01LVqN3bbzsi82NRXIEe0n4kpi3M3fb5CjlKULKi2uA/aBLMpyFZxwkS evWQm05gUX5ER/Nw5CpJvPlLrREhpkQ7DHk5cN1pc3t88kgAeMfBoJUK66D5yfk7+8 NG3NXlvgbpuQmATOOC4FytPcbA2MxyM2d3MFQexfaYni4SPIoKX4+YjnKWfWwK+GHY vhKeY0L1U6Jw4X7NfyyMmxhJYPtseutKhjYDQ/6tZgqquUyVk4IZWFNTRP4VKgAQUe ozk39qLBK23PWK9Fd0xySVShX7Vmt1IgXesATiW/Qgu/fZxZ4CJRv02jpxgissnfAS NYealZiI9tTfr7oXePA/Q4BypYtdL6QMQn89wmB2ibiDYOdzI2S
Date: Fri, 11 Dec 2020 01:01:18 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <X9LE3rn9t88OJRSv@camp.crustytoothpaste.net>
References: <48be3fcf-cdce-9ef4-655b-63b6dddf9310@kuix.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="RRGEQrFCe9EBMue1"
Content-Disposition: inline
In-Reply-To: <48be3fcf-cdce-9ef4-655b-63b6dddf9310@kuix.de>
User-Agent: Mutt/2.0.2 (2020-11-20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/PU2hDzwKDMAr1rLvXVsopowkf_I>
Subject: Re: [openpgp] Combining signature with signer's public key
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2020 01:02:01 -0000

On 2020-12-10 at 21:38:22, Kai Engert wrote:
> Is it possible to include the sender's own public key as part of a detached
> OpenPGP signature?
> 
> When Thunderbird sends a signed email, it wants to include the sender's
> public key by default, to ensure that the recipient has it available.
> 
> Thunderbird sends the key as an attachment.
> 
> We received a surprisingly high number of complaints from users. who are
> unhappy about having attached the key by default. Apparently having the
> extra public key attachment causes confusion on the recipient side, with
> users not understanding what the attachment is about.

Yes, adding an attachment that the sender did not explicitly request is
not a good idea.  I would find this undesirable, too.

> However, I haven't heard complaints about the signature attachment - which
> is shown by MUA that don't support OpenPGP. The signature attachment appears
> to be less of a problem or confusion.

That's because (a) it's been around a long time and (b) that this is a
multipart/signed message, not an attachment.  An MUA that handles S/MIME
already knows how to handle this type because the same MIME type is used
for both (although the MIME type of the signature is different).  And
generally the signature doesn't have an attachment Content-Disposition.

Some MUAs do show it as an attachment and that does cause confusion.
I've had people ask me about it.

> If it were possible to include the sender's public key inside the signature,
> Thunderbird could use a single attachment for both.

I don't think RFC 4880 specifically permits this as part of an OpenPGP
message, but then again they don't specifically permit a detached
signature as an OpenPGP message (although it is described elsewhere).  I
suspect many implementations would in fact understand and parse a key
that was included in the same OpenPGP message as the signature, but
might or might not permit it to be imported.  RFC 3156 states that the
second body "MUST contain the OpenPGP digital signature," but doesn't
restrict it to that or specify things that it should not contain.

You could prototype it and try to see how other implementations (e.g.,
mutt) handle it.  I don't know how you'd get GnuPG to emit a combined
block, though.

There is also a specification called Autocrypt[0] (which I have not
looked at more than cursorily), which may be useful for your needs.

Finally, you could just assume that the user has access to a suitable
keyserver, like many people do, and skip sending the key altogether.
This is what mutt does.

[0] https://autocrypt.org/level1.html
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US