[openpgp] Issuer Fingerprint

Werner Koch <wk@gnupg.org> Mon, 13 June 2016 10:11 UTC

Return-Path: <wk@gnupg.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 7E8F612B01E for <openpgp@ietfa.amsl.com>; Mon, 13 Jun 2016 03:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 ZA4snnI3i_2C for <openpgp@ietfa.amsl.com>; Mon, 13 Jun 2016 03:11:36 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682B612B00F for <openpgp@ietf.org>; Mon, 13 Jun 2016 03:11:36 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bCOqE-0003OH-1e for <openpgp@ietf.org>; Mon, 13 Jun 2016 12:11:34 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bCOmL-0003KO-Ot for <openpgp@ietf.org>; Mon, 13 Jun 2016 12:07:33 +0200
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367
Mail-Followup-To: openpgp@ietf.org
Date: Mon, 13 Jun 2016 12:07:33 +0200
Message-ID: <87mvmp5rmi.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/LFtg4NzKEHIa8qTa4F0t7mr3JJQ>
Subject: [openpgp] Issuer Fingerprint
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Jun 2016 10:11:38 -0000

Hi!

It is a long time problem in OpenPGP that signatures have no way to
unambiguously specify the key used to create the signature.  The specs
suggest the use of the Issuer subpacket to convey the long keyid of the
issuing key.  However, it is possible to create colliding 64 bit keyids
and thus it is possible that a user downloads the wrong key for a
signature; this will yield a bad signature status and the user has no
easy means to decide whether this is is really a bad signature, or due
to the use of a colliding public key. 

This can easily be solved by including the full fingerprint of the key
in the signature.  Introducing such a feature can be made orthogonal to
a new fingerprint format.  I propose this change:

--8<---------------cut here---------------start------------->8---
@@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
           30   Features
           31   Signature Target
           32   Embedded Signature
+          33   Issuer Fingerprint
   100 to 110   Private or experimental

 An implementation SHOULD ignore any subpacket of a type that it does
@@ -1615,6 +1616,16 @@ #### {5.2.3.26} Embedded Signature
 in Section 5.2 above.  It is useful when one signature needs to refer
 to, or be incorporated in, another signature.

+#### Issuer Fingerprint
+
+(1 octet key version number, N octets of fingerprint)
+
+The OpenPGP Key fingerprint of the key issuing the signature.  The
+only possible key version number is 4 and thus N must be 20.  This
+subpacket is intended to eventually replace the issuer subpacket which
+does not not unambiguously specify the key.  It SHOULD be part of all
+signatures.
+
 ### {5.2.4} Computing Signatures

 All signatures are formed by producing a hash over the signature data,
--8<---------------cut here---------------end--------------->8---



Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
    /* EFH in Erkrath: https://alt-hochdahl.de/haus */