Re: [openpgp] Intended Recipient observation

vedaal@nym.hush.com Fri, 16 April 2021 16:31 UTC

Return-Path: <vedaal@nym.hush.com>
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 669233A2BBE for <openpgp@ietfa.amsl.com>; Fri, 16 Apr 2021 09:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=hush.ai
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 AN1NnOlTM6FY for <openpgp@ietfa.amsl.com>; Fri, 16 Apr 2021 09:31:03 -0700 (PDT)
Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (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 812DC3A2BBC for <openpgp@ietf.org>; Fri, 16 Apr 2021 09:31:03 -0700 (PDT)
Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id AE9B820174 for <openpgp@ietf.org>; Fri, 16 Apr 2021 16:31:01 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=oDzIXC4xbY0TSqAnX6FiKP9Ei3MQpmq3KSf3wngvdqM=; b=f9wwEvXpTSNazJfRnNM53gMe+1QHAswf4E6PoxA9u1ifV6KnmMULTNJVZOL8nHxZDox1hic19nB9l+y5Ka8/tkEdYDm2VQeIcUY239pqwyvSjZGe3xAx0AhVvoH49GC6NrpuO0FHIFV6Q7J/JSxGivC78Ed6GDP1wbAHTrfs2+MixjE2Lzx8GY+/Vr7z9TokIYDG70r8+yst04kQKozilpITZGakw5Avs7yhem0tTdEnZUgjIwVQNcUHS0HacroEPDbc0cfzgKdyDO6PkQmFgf3vuWwRFUPVqhAk2oM7uX2fs9lWxuf4EUg/il52VROo8wHaqYcmvR2RNoB/77Dr4A==
Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Fri, 16 Apr 2021 16:31:01 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 48) id 3A49E80614A; Fri, 16 Apr 2021 16:31:01 +0000 (UTC)
MIME-Version: 1.0
Date: Fri, 16 Apr 2021 12:31:01 -0400
To: "Neal H. Walfield" <neal@walfield.org>, openpgp <openpgp@ietf.org>
From: vedaal@nym.hush.com
In-Reply-To: <87zgxynw7x.wl-neal@walfield.org>
X-hush-end-of-body-position: 70
Content-Type: multipart/alternative; boundary="=_3aef84a64d7902218c037f40e5e6f5d0"
Message-Id: <20210416163101.3A49E80614A@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rB0-YlMFE4zC8cX8jYACFneqApw>
Subject: Re: [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 16:31:08 -0000

On 4/16/2021 at 10:24 AM, "Neal H. Walfield"  wrote: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.  T
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. 

=====

Why would Alice want to import M's key?

Unless M was once a friend of Alice, and unsuspected by her, now bears
her ill will,
and is familiar with her encryption subkey S, and now created a new
certificate M'
with her encryption subkey S, and sends it to the server.

Still, in order for her to Import M' as a new key by M, she would
check first if M' was also signed by M.
If she then sees a decryption problem, she would (thanks to your
pointing this out), 
check for duplicate subkey S in her keyring, and then find out that M
does bear her ill will.

As most users are familiar with their encryption subkey's fingerprint,
it would be a good idea to check any prospective public key for an
encryption subkey fingerprint, before importing it.

Thanks for pointing this out.
(Doesn't affect me though, as am from old school that doesn't use
subkeys,
where the primary certificate signs, decrypts and authenticates).

vedaal