Re: [openpgp] Signing of literal data packet [was: Re: Disadvantages of Salted Signatures]

Andrew Gallagher <> Thu, 04 January 2024 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B4B1C14F6A6 for <>; Wed, 3 Jan 2024 16:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kV5y4-v95KoY for <>; Wed, 3 Jan 2024 16:17:30 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7C585C151985 for <>; Wed, 3 Jan 2024 16:17:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=andrewg-com; t=1704327447; bh=ygy07o7JGnJIJtQnhp/drQjzvZV6hts9xzfzj6C0i3Y=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=O0Uwmk8eeT+k7R+brjZsk8aYCABEFDLWKvKcgpKDVFp6BOxFflU2st0prQ68DsLej qnmhNl5lPvhU4XaP4TJdfgmnBfRjNi5+xdg05znm4YIC4B3G1ndgvmOyWZKXLWHNPv e80yC9HSg5MyxOzHcZgc2sdkWSfQavGhEax0X0QLPGPvZDUiQiASTi9KQXFKEy//Ly 7XFbTEeKWC/RpLQ6pJ5ja35xamgZaVujX+lp0FiZL1GFAu7QZ2cTJiA37YgYc8bZlg U9HF0DGr66azC4Uxup0iFWglv+gEvZHMRCPsMaYUaYnsYcb1Ltnf+QDqbg3XygUMOB eoj3ljWYRjtng==
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPSA id 4D2835DC2A; Thu, 4 Jan 2024 00:17:27 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <>
Mime-Version: 1.0 (1.0)
Date: Thu, 04 Jan 2024 00:17:15 +0000
Message-Id: <>
References: <>
Cc:, Werner Koch <>, Heiko Schäfer <>, Kai Engert <>
In-Reply-To: <>
To: Daniel Kahn Gillmor <>
X-Mailer: iPhone Mail (21C66)
Archived-At: <>
Subject: Re: [openpgp] Signing of literal data packet [was: Re: Disadvantages of Salted Signatures]
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jan 2024 00:17:35 -0000

On 3 Jan 2024, at 20:44, Daniel Kahn Gillmor <> wrote:
> With no hats on, as a document signer, i might want to include arbitrary
> metadata on a signature: For example, in 2024, why should my timestamp
> be limited to a 32-bit unsigned field of seconds since the unix epoch?
> Maybe i want higher-precision (or wider range) timestamps.  What if i
> want to record both a creation time and a modification time for the
> signed file?  What if i want to indicate a MIME type?  Why should my
> ability to record a filename be limited to 255 octets?  What if i wanted
> to record file ownership, permissions, or extended attributes?

All good suggestions. And I agree we could define better ways to handle arbitrary metadata using e.g. notations, or direct them to other layers of the stack. At this point however, I’m limiting myself to considering data that is already routinely included in OpenPGP messages, to minimise changes at the application layer.

> RFC 1991 clearly states the reason that these fields were not originally
> signed in the first place:
>>>  Note that only field (e) of a literal data packet is fed to a
>>>  message-digest function for the formation of a signature. The
>>>  exclusion of the other fields ensures that detached signatures are
>>>  exactly the same as attached signatures prefixed to the message.
>>>  Detached signatures are calculated on a separate file that has none
>>>  of the literal data packet header fields.

Good spot! I was unaware that this was explicitly documented. It does appear to demonstrate that this was a conscious design decision and not an implementation error. I will amend the preamble to the draftt accordingly.

> Arguably, the mistake was not that these fields were unsigned, it was
> that they were included in the literal metadata packet in the first
> place.  

I think we’re in agreement there! However, removing them entirely might be too much of a breaking change at this point, unless we are sure that no application relies upon them. 

>  (b) no one raised this issue when we did the multi-week call for
>      potential OpenPGP topics for the rechartered working group.

I can’t speak for why others didn’t bring the issue up at that time, however it has become clear since that this is the only technical issue remaining that prevents all implementations from supporting v6 signatures. I feel therefore that it is worth trying again to get agreement on this feature.

> To make it concrete, how would you propose extending the API surface of
> "sop" to account for the potential presence of this information under a
> cryptographic signature?  (or, if "sop" is not the right interface given
> its simplicity, apply the same question to any other OpenPGP interface
> for application developers)

I haven’t looked into it closely, but if the API surface already supports reading and writing the metadata fields of the literal data packet then no changes should be necessary at that layer. All that changes is where on the wire they get recorded.

> Even if this literal metadata issue is resolved and it becomes possible
> to say that a v6 signature can cover these legacy metadata fields the
> way that some v5 signatures aim to, a significant difference between v5
> and v6 signatures remains:

To be clear, this proposal is not intended to encourage the use of v5 sigs, but rather to make implementation of v5 sigs unnecessary.

>> It is open to further improvement: for example I would prefer not to
>> define both hashed and unhashed encodings of the same subpacket - if
>> we could agree to standardise on the unhashed encoding, we can leave
>> encoding/version 0 reserved. But that’s not a blocker.
> It took me a couple reads to understand that you're talking about the
> different proposed versions of the subpacket as "hashed" and "unhashed",
> given that subpackets themselves can be either in the "hashed" or
> "unhashed" areas of the signature packet.  I'm assuming that you do
> *not* mean that the packet would be structured differently depending on
> which area it sits in!

Sorry, yes the subpacket is only ever useful when located in the hashed area. The difference between the hashed and unhashed (the draft uses “verbatim”) encodings is that one involves an additional hashing stage when constructing the subpacket, before the signature hash is calculated.