Re: including the entire fingerprint of the issuer in an OpenPGP certification

Jon Callas <> Tue, 18 January 2011 02:14 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0I2EeQn009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:14:40 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0I2EejN009868; Mon, 17 Jan 2011 19:14:40 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( [] (may be forged)) by (8.14.4/8.14.3) with ESMTP id p0I2EdUQ009863 for <>; Mon, 17 Jan 2011 19:14:39 -0700 (MST) (envelope-from
Received: from localhost (localhost []) by (Postfix) with ESMTP id 081EF2E0B4 for <>; Mon, 17 Jan 2011 18:14:53 -0800 (PST)
Received: from ([]) by localhost (host.domain.tld []) (amavisd-maia, port 10024) with ESMTP id 12947-09 for <>; Mon, 17 Jan 2011 18:14:48 -0800 (PST)
Received: from ( []) (Authenticated sender: jon) by (Postfix) with ESMTPA id 30FA82E02C for <>; Mon, 17 Jan 2011 18:14:48 -0800 (PST)
Received: from [] ([]) by (PGP Universal service); Mon, 17 Jan 2011 18:14:34 -0800
X-PGP-Universal: processed; by on Mon, 17 Jan 2011 18:14:34 -0800
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jon Callas <>
In-Reply-To: <>
Date: Mon, 17 Jan 2011 18:14:31 -0800
Cc: notmuch <>
Message-Id: <>
References: <>
To: IETF OpenPGP Working Group <>
X-Mailer: Apple Mail (2.1082)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by id p0I2EdUQ009864
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

Hash: SHA1

On the one hand, my only disagreement with you is to suggest that your proposal be tied into using SHA256 for a fingerprint. If you're going to expand the keyid to a fingerprint, why not get a better fingerprint?

On the other hand, this has never been a problem. It's harder than you think, because you have to generate a new key each time, which takes a while on RSA. 

Nonetheless, I think it's a good idea. I'd just go all the way to a better fingerprint.


On Jan 17, 2011, at 5:47 PM, Daniel Kahn Gillmor wrote:

> * PGP Signed by an unknown key
> Hi OpenPGP folks (and Cc'ed notmuch developers/users)--
> Some recent discussion about verifying OpenPGP signatures for the
> notmuch mail user agent got me thinking about different ways one might
> interpret a negative result from a signature made over a message.
> Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket to
> refer to the low 64 bits of the fingerprint of the issuer's key (the
> issuer's "key ID"):
> Given that we can't assume that key IDs are unique with any high degree
> of confidence, this creates some ambiguity between these states:
> A) "you don't have the key that made this signature"
> B) "this signature is bad"
> a user-friendly MUA that thinks it is in state A might do something
> sensible like offer to do a keyserver lookup (if it is online), while
> simply reporting "signature error" if it thinks it is in state B.
> But a devious attacker could potentially create a colliding Key ID (i
> believe collisions of the low 64 bits of SHA1 are within reach today,
> i'd love to be corrected if this is not the case) and cause the
> user-friendly MUA to assume it is in state B when it is actually in
> state A.  The attacker doesn't even need access to the message or
> signature in question to do this.  They'd only need to have been able to
> supply a key to the user at some time in the past.  (e.g. push a new
> subkey to the keyservers which a user pulls during a keyring refresh)
> One way around this ambiguity would be to include the issuer's entire
> fingerprint instead of just the low 64 bits, which would make the
> certainty of state A vs. state B much clearer.
> Would there be any objection to a new subpacket type for OpenPGPv4 that
> would include the remaining 96 bits of the issuer's fingerprint?  (the
> "high 96" proposal)
> Alternately, what about a new subpacket type that simply includes the
> entire 160 bits of the issuer's fingerprint?   (the "full fingerprint"
> proposal)
> A third proposal would be a new subpacket type that simply includes the
> entire public key of the issuer (the "full pubkey" proposal).
> I lean toward "high 96", since using it in conjunction with the issuer
> subpacket retains backward compatibility with existing tools (which know
> how to interpret the issuer subpacket) while introducing the smallest
> amount of additional data per signature.
> Given that the size of a signature from a 2048-bit RSA key is 256 bytes
> already, adding an additional 12 bytes (plus a few bytes of subpacket
> overhead) per signature doesn't seem particularly excessive.
> I'm also assuming that the typical use of this subpacket would be in the
> unhashed section of a signature packet, since it is an advisory field
> and not intended to address attacks against an adversary capable of
> tampering directly with the data in the signature itself.
> I will write code to implement this using an experimental subpacket ID,
> but i'd like to know if anyone has any caveats, concerns, or preferences
> between the proposals i've outlined above (or entirely different
> proposals that would address the underlying concern).
> Any thoughts?
> Regards,
> 	--dkg
> * Unknown Key
> * 0xD21739E9

Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii