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

"Neal H. Walfield" <neal@walfield.org> Fri, 11 December 2020 08:34 UTC

Return-Path: <neal@walfield.org>
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 1EA6F3A082F; Fri, 11 Dec 2020 00:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RTOfrTwLa3Z9; Fri, 11 Dec 2020 00:34:40 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4653F3A0913; Fri, 11 Dec 2020 00:34:39 -0800 (PST)
Received: from pd9e79cc0.dip0.t-ipconnect.de ([217.231.156.192] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1kndsr-0001oR-Ap; Fri, 11 Dec 2020 08:34:37 +0000
Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1kndsq-0005EM-Vw; Fri, 11 Dec 2020 09:34:37 +0100
Date: Fri, 11 Dec 2020 09:34:36 +0100
Message-ID: <87h7osyc4j.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Wiktor Kwapisiewicz <wiktor=40metacode.biz@dmarc.ietf.org>
Cc: Kai Engert <kaie@kuix.de>, openpgp@ietf.org
In-Reply-To: <5ecf5a5c-6eaa-7929-bb8e-c1bf776fb3d4@metacode.biz>
References: <48be3fcf-cdce-9ef4-655b-63b6dddf9310@kuix.de> <5ecf5a5c-6eaa-7929-bb8e-c1bf776fb3d4@metacode.biz>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-SA-Exim-Connect-IP: 192.168.20.9
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NVL1orm1eBR1xtu_lKMmqgRhXQE>
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 08:34:51 -0000

Hi Kai,

On Fri, 11 Dec 2020 08:21:26 +0100,
Wiktor Kwapisiewicz wrote:
> On 10.12.2020 22:38, Kai Engert wrote:
> > Is it possible to include the sender's own public key as part of a
> > detached OpenPGP signature?
> 
> You may be interested in the Key Block signature subpacket as detailed
> in here:
> 
> https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3.31

Storing the certificate in a subpacket area of the signature, as
Wiktor points out, is reasonable.

The subpacket that Wiktor references, however, was added to 4880bis
without any discussion on this mailing list, as far as I am aware
(please correct me if I am wrong).  As such, I would recommend that
you instead use a notation.  If, at a later point, this subpacket or a
similar one is indeed standardized, it is straightforward enough to
adapt your implementation.

You could actually store the subpacket or notation in the unhashed
subpacket area since the content is self authenticating (you can check
that the certificate is valid by checking the signature).

One thing to be aware of: the subpacket areas can only hold 64kb of
data.  So, you really should minimize the certificate.

:) Neal