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

Kai Engert <kaie@kuix.de> Fri, 11 December 2020 09:02 UTC

Return-Path: <kaie@kuix.de>
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 A83D73A0045 for <openpgp@ietfa.amsl.com>; Fri, 11 Dec 2020 01:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, 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 (2048-bit key) header.d=kuix.de
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 PNzE29jrLVJr for <openpgp@ietfa.amsl.com>; Fri, 11 Dec 2020 01:02:58 -0800 (PST)
Received: from cloud.kuix.de (cloud.kuix.de [93.90.207.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9135C3A003E for <openpgp@ietf.org>; Fri, 11 Dec 2020 01:02:58 -0800 (PST)
Received: from [10.137.0.17] (ip-95-223-75-128.hsi16.unitymediagroup.de [95.223.75.128]) by cloud.kuix.de (Postfix) with ESMTPSA id E2C0018D049; Fri, 11 Dec 2020 09:02:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1607677374; bh=wZqIucdczclyH/KUxKkZbnrvS+frt9MO2cy+NVplOYk=; h=To:References:From:Subject:Date:In-Reply-To:From; b=OC/tlzND3wX4QF7DR3pajEJl0ApfQWVsrsqvtXr5jm4p9YLF2utQFL1XmtNoEyPIP /OClySE/CuU0piAppG+WwV1QCnmivMM9u7KKp/QL/NTCSpGQ2GzPdDqyV72gfpLai1 /+nPN4Kn3FpUmGQr6NbnSfgYRK3D/dZ+RrTH+YQbDy5/v7oNJoaigxYAg5hr8Kg4vv wNIeYUiQj10E4auwzCklP9jEpVP/t+Y8vAYYEzfZohppOJcqQLR//8x9GZ8qt8atkK fEs549/w6QxW0/mHNEZd7g/JYSVWdm5sIoyUjgLFCDR9S4A1cgPyb9kQ2tTxMfc5dj TQhQyBeI0NMaw==
To: vedaal@nym.hush.com, openpgp <openpgp@ietf.org>
References: <20201210215354.D75AF803B10@smtp.hushmail.com>
From: Kai Engert <kaie@kuix.de>
Message-ID: <3288b6ad-a31f-2c2a-b8c4-16449f04adf1@kuix.de>
Date: Fri, 11 Dec 2020 10:02:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201210215354.D75AF803B10@smtp.hushmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rfcduGg-BdClWj8FqS8ZGT0kRUo>
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 09:03:00 -0000

On 10.12.20 22:53, vedaal@nym.hush.com wrote:
> On 12/10/2020 at 4:38 PM, "Kai Engert" <kaie@kuix.de> wrote:
>     Possible, but slightly tedious:
> 
>     [1] Export the public key as an asc file
>     [2] Add a line after the last line, saying that the key as well as
>     whatever is to be signed in the message is now being signed by the
>     signer's key (list name and long fingerprint
>     [3] Armor sign the entire thing  (asc key file and extra line)
>     [4] Send the Armored signed message as the attachment instead of the
>     signature

Thanks for your suggestion.

This approach probably doesn't work for us. I should have clarified that 
it's about PGP/MIME. I guess receiving agents aren't prepared to receive 
a signed message in the place where they expect a signature. Also, IIUC, 
the signature calculation would have to be different, it would have to 
feed both the primary message and the secondary message (with the key) 
into the signature calculation. It seems this won't be comaptible with 
existing clients.

Thanks
Kai