[openpgp] Re: text vs. binary in an OpenPGP "Signed Message"

Andrew Gallagher <andrewg@andrewg.com> Mon, 03 March 2025 10:44 UTC

Return-Path: <andrewg@andrewg.com>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 958FD586DB3 for <openpgp@mail2.ietf.org>; Mon, 3 Mar 2025 02:44:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7fZ9XabQlDS for <openpgp@mail2.ietf.org>; Mon, 3 Mar 2025 02:44:11 -0800 (PST)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 204D0586D92 for <openpgp@ietf.org>; Mon, 3 Mar 2025 02:44:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1740998650; bh=dOwsxBW47xQnNvcyLYs8nQ5LdnRNFObzvuaFJeXcGho=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MwGbHDOupRomJYGNnCRlgcOQ7thGrBROR3EKc0TjU3sFLB06O17IOBZN/hT9sW+hL gVpE5d10O92/ouXobYSU0qfbjmoZWCfvt96GUgV6NchPo+Jza7MYwzKG14LyQTNW2A UbJOVmkxO0bbnCGARvoYiLtTJZScp4mJcJW0zBvhXAUbQtmevUhxchu9hkTwEfj2CD KT+3FttH3UEFB1OFF6RVS8P1dxYj+qHzqOwRxVdrxSNUunC+U/SiY9v64/FJqHu+x/ SBDG7h28b+eIj/lD6Hf1Oa+nv5q11HpZp2zM6KjvXtgQr71EPvCOEAKbF7fxZNKlgz AXarbxvZCPTUw==
Received: from smtpclient.apple (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id CB3C95DFC2; Mon, 3 Mar 2025 10:44:09 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_C574B330-BC05-4B01-AC43-1B3ACF441FEC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\))
From: Andrew Gallagher <andrewg@andrewg.com>
In-Reply-To: <87o6yiigut.fsf@europ.lan>
Date: Mon, 03 Mar 2025 10:43:51 +0000
Message-Id: <AC534DE2-3B46-4684-AD0A-C80897D1B607@andrewg.com>
References: <871pvq4yhe.fsf@fifthhorseman.net> <87o6yiigut.fsf@europ.lan>
To: Justus Winter <justus@sequoia-pgp.org>
X-Mailer: Apple Mail (2.3731.700.6.1.9)
Message-ID-Hash: SSEX7EWXFSL24HD2L5L22XX5SU4WDV3Q
X-Message-ID-Hash: SSEX7EWXFSL24HD2L5L22XX5SU4WDV3Q
X-MailFrom: andrewg@andrewg.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, IETF OpenPGP <openpgp@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Re: text vs. binary in an OpenPGP "Signed Message"
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/bLYvWLPKHWDsQukBGaHCGcR0Nwk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

On 3 Mar 2025, at 09:49, Justus Winter <justus@sequoia-pgp.org> wrote:
> 
> - If we compute/verify a text signature, we transform the data stream on
>  the fly for hashing purposes, but the downstream consumer gets the
>  data as is.
> 
> In short, if you use Sequoia, what bytes go in come out again,
> unvalidated and unchanged.
> 
>> - If not, should a verifier that encounters (d) attempt to apply CRLF
>>  line endings to the LITb?
> 
> No.

We need to be careful to distinguish between canonicalisation of the signature subject (i.e. the data on the wire that a receiver can read directly) and of the “type-specific data” that is passed into the signature hash function. The point of type 1 signatures is that the type-specific data is independent of which newline convention (if any) has been applied to the subject. So for the above question, perhaps we should clarify that the wire format of the subject SHOULD NOT be altered by the receiving implementation, but the type-specific data passed to the signature verification MUST still be normalised.

A