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

Werner Koch <> Fri, 11 December 2020 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99A363A0140 for <>; Fri, 11 Dec 2020 00:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XXN2SZsrCG8c for <>; Fri, 11 Dec 2020 00:30:13 -0800 (PST)
Received: from ( [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED8733A00F7 for <>; Fri, 11 Dec 2020 00:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pRDrNtabw2kK79ZALxyOfcNBlh3JBb1UFCe2ZojEQGQ=; b=b8HPd+hjBlIucfsA2znY68JlTM YKogSQtwhM7iLrRuCUBRreilLqJBWZUY7Ph/q3esbgrhXmbZT+30bSbkYWLihA2SR2Q6oqfyrKHHr PWAgX6rRL2YWYjk0WzmHdzFR/kd5QHSkC/gZX2vHaDjyaFPqw/ScZkLcK8PGWWcJp67o=;
Received: from uucp by with local-rmail (Exim 4.89 #1 (Debian)) id 1kndoW-0001zj-Lg for <>; Fri, 11 Dec 2020 09:30:08 +0100
Received: from wk by with local (Exim 4.92 #5 (Debian)) id 1kndoM-0001mp-Ir; Fri, 11 Dec 2020 09:29:58 +0100
From: Werner Koch <>
To: Wiktor Kwapisiewicz <>
Cc: Kai Engert <>,
References: <> <>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Wiktor Kwapisiewicz <>, Kai Engert <>,
Date: Fri, 11 Dec 2020 09:29:52 +0100
In-Reply-To: <> (Wiktor Kwapisiewicz's message of "Fri, 11 Dec 2020 08:21:26 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=gamma_2600_Magazine_industrial_intelligence_Bosnia_Tony_Blair_ICE=De"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] Combining signature with signer's public key
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: Fri, 11 Dec 2020 08:30:15 -0000

On Fri, 11 Dec 2020 08:21, Wiktor Kwapisiewicz said:

> You may be interested in the Key Block signature subpacket as detailed
> in here:

Right.  GnuPG introduced this for better user experience with mail
providers who won't deploy a Web Key Directory and, more important, to
ease handling of signed file conveyed using non-mail systems.

> Do note that as to my knowledge nothing supports it yet (happy to be
> corrected).

GnuPG supports this since 2.2.20 (released 2020-03-20)

  * gpg: New options --include-key-block and --auto-key-import to
    allow encrypted replies after an initial signed message.  [#4856]


    This option is used to embed the actual signing key into a data
    signature.  The embedded key is stripped down to a single user id
    and includes only the signing subkey used to create the signature
    as well as as valid encryption subkeys.  All other info is removed
    from the key to keep it and thus the signature small.  This option
    is the OpenPGP counterpart to the gpgsm option --include-certs and
    allows the recipient of a signed message to reply encrypted to the
    sender without using any online directories to lookup the key.  The
    default is --no-include-key-block.  See also the option


    This is an offline mechanism to get a missing key for signature
    verification and for later encryption to this key.  If this option
    is enabled and a signature includes an embedded key, that key is
    used to verify the signature and on verification success the key is
    imported. The default is --no-auto-key-import.

    On the sender (signing) site the option --include-key-block needs to
    be used to put the public part of the signing key as “Key Block
    subpacket” into the signature.

The include-key-block option should only be enabled if required.  MUAs
can decide whether this makes sense; GPGME supports this using
gpgme_set_ctx_flag (flags "include-key-block" and "auto-key-import").



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.