[openpgp] Intended Recipient observation

"Neal H. Walfield" <neal@walfield.org> Fri, 16 April 2021 14:24 UTC

Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 67C043A27D2 for <openpgp@ietfa.amsl.com>; Fri, 16 Apr 2021 07:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xTMgYmgm36zN for <openpgp@ietfa.amsl.com>; Fri, 16 Apr 2021 07:24:40 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FEA3A27D1 for <openpgp@ietf.org>; Fri, 16 Apr 2021 07:24:39 -0700 (PDT)
Received: from p5de92c26.dip0.t-ipconnect.de ([] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1lXPOd-0003yx-5k for openpgp@ietf.org; Fri, 16 Apr 2021 16:24:35 +0200
Received: from grit.huenfield.org ([] 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 1lXPOc-0007Bn-M7 for openpgp@ietf.org; Fri, 16 Apr 2021 16:24:34 +0200
Date: Fri, 16 Apr 2021 16:24:34 +0200
Message-ID: <87zgxynw7x.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: openpgp@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/27 (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-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/KJAKRNTI1V2nW6kFl1JCne6BXgQ>
Subject: [openpgp] Intended Recipient observation
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, 16 Apr 2021 14:24:44 -0000


I just encountered a complication when respecting the Intended
Recipient subpacket.  Others might find this useful.  Consider.

Alice has a certificate A with an encryption subkey S.  The encryption
key is stored externally on something like an HSM (in my case, gpg
agent).  The key is addressable by its grip (basically a hash of its
public MPI).


Mallory creates certificate M and adopts S.  This is possible, because
unlike signing subkeys, encryption subkeys do not need a backsig.

Alice imports the certificate M into her local keystore.  She now has
two certificates with the subkey S.

Alice receives a signed and encrypted message.  The message is
encrypted to S (the PKESK's recipient field has the keyid of S, S'),
and A is listed as an intended recipient in the signature.

Alice's OpenPGP implementation looks in her keystore for a certificate
with S' and finds M.  She sees that S is in her HSM, so she decrypts
the message using the HSM.  It works.  Alice's OpenPGP implementation
now checks whether M is in the set of intended recipients.  Since it
isn't, her OpenPGP implementation marks the signature as invalid.


Marking the key in a special way (e.g., A is a personal key, and only
personal keys should be used for decryption) is not sufficient.  I'm
aware of people who use the same key material on multiple

  $ gpg --with-keygrip -k XXX
  pub   dsa1024/0xE0BB1C42B6A8C559 2002-03-01 [SCA]
        Key fingerprint = 8C88 F05D EE7E 7A36 075F  609B E0BB 1C42 B6A8 C559
        Keygrip = 08E03C5C2B608ABBE643F4CCDC15AB1266E6F847
  sub   rsa2048/0x6374E7B91E8D8306 2016-01-27 [A]
        Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3
  sub   rsa2048/0xCB3A5ACDBA0C288F 2016-01-27 [E]
        Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE
  sub   rsa2048/0x44C4193E2D42869B 2016-01-27 [S]
        Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E

  pub   dsa3072/0xDCF666F298FA0DCF 2021-01-06 [SC]
        Key fingerprint = 3361 C438 401F C9C9 D52C  DDC7 DCF6 66F2 98FA 0DCF
        Keygrip = DA44D0AD8506E6CB0ECDE60DF9925D5A6AD05F3C
  sub   rsa2048/0x46E8EF0E42FE802B 2021-01-06 [A]
        Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3
  sub   rsa2048/0x940C2C3BDB9A2EF6 2021-01-06 [E]
        Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE
  sub   rsa2048/0xB86888BABA9CD070 2021-01-06 [S]
        Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E

(In this person's case, the subkeys happily have different
fingerprints, but this need not be the case.)

So it seems that when checking the intended recipients, it is
necessary to check whether any of the certificates with S is listed,
not just the first one that happens to have that subkey, which is my
case was sufficient to decrypt the message.

:) Neal