Re: [openpgp] Context Parameters for Signing and Encryption

Bruce Walzer <bwalzer@59.ca> Wed, 15 February 2023 21:43 UTC

Return-Path: <bwalzer@59.ca>
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 D4916C15EB2E for <openpgp@ietfa.amsl.com>; Wed, 15 Feb 2023 13:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl32iOKZ5TGK for <openpgp@ietfa.amsl.com>; Wed, 15 Feb 2023 13:43:08 -0800 (PST)
Received: from mail.59.ca (mail.59.ca [205.200.229.83]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C860C15E406 for <openpgp@ietf.org>; Wed, 15 Feb 2023 13:43:07 -0800 (PST)
Received: from [104.246.140.18] (helo=watt.59.ca) by mail.59.ca with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <bwalzer@59.ca>) id 1pSPYM-0003mX-Hn for openpgp@ietf.org; Wed, 15 Feb 2023 15:43:02 -0600
Date: Wed, 15 Feb 2023 15:42:56 -0600
From: Bruce Walzer <bwalzer@59.ca>
To: openpgp@ietf.org
Message-ID: <Y+1R4NSAW9asPWrE@watt.59.ca>
References: <87y1pcm3go.fsf@fifthhorseman.net> <87cz6ilr7w.fsf@fifthhorseman.net> <8B86FBCD-F723-4518-BE00-AE74FB2D47B2@andrewg.com> <k13jlbmfeU3h8dS-wAVK6aWpX_ZB2UW8AQDQpDU96H6_2zdtUNC9XXCrlq0oAL07Usueyn_TkPu_fA-V6V-UTtfFIVT43sDs7C-vh3aDDZ4=@protonmail.com> <467AF37A-34BE-4D10-99F5-E4421B7E6EF4@andrewg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <467AF37A-34BE-4D10-99F5-E4421B7E6EF4@andrewg.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/luBH6fTneI-7tNmjDhURU6KB7PA>
Subject: Re: [openpgp] Context Parameters for Signing and Encryption
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 15 Feb 2023 21:43:09 -0000

On Fri, Feb 10, 2023 at 02:49:32PM +0000, Andrew Gallagher wrote:
> On 10 Feb 2023, at 12:36, Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org> wrote:
> > 
> > I think another way to achieve something similar would be to define an
> > armor header (or an application-specific out-of-band mechanism, such as
> > an email header) to indicate the context used. That way, the sender can
> > also choose whether to include it or not, and it requires less fiddling
> > with the bits of the packet.
> > 
> > And then, even if the OpenPGP implementation doesn't do anything to
> > verify or expose the context (although imo it should), someone manually
> > decrypting the message could manually check the context as well.
> 
> This is how it should work at the application level, no matter what method is used lower down. The question for OpenPGP is a) to what extent should expert tools be able to decrypt under sub-optimal circumstances, e.g. if the email headers were mangled by an archival system, and b) to what extent should a cryptographic API protect the calling application from itself, e.g. sloppy programming practice. There is a trade-off here that does not have a universal answer, so leaving such decisions to application-level protocols seems appropriate to me.

Another interesting question here is: how should we explain things to
the user when this check fails? Delegating the response to the
application is fine only if the application is going to be able to
respond in a clear and understandable way. For example, encrypted
email borrows the idea of the envelope used in paper mail as the
concept for the encryption. How would this error condition be related
to that concept?

Bruce