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

Daniel Kahn Gillmor <> Wed, 03 January 2024 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E130C31A623 for <>; Wed, 3 Jan 2024 12:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b="4pwEUoY9"; dkim=pass (2048-bit key) header.b="kIowGe/4"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wFnMKaRgo3Me for <>; Wed, 3 Jan 2024 12:43:41 -0800 (PST)
Received: from ( [IPv6:2001:470:1:116::7]) (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 E7778C151086 for <>; Wed, 3 Jan 2024 12:43:40 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1704314617; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MH/33LJwclbnRVYbQrCaFnIW8qHZ0ftviNOo+z0UVZs=; b=4pwEUoY9l2m5a3XfYksLcTUZ0eFPg38dZg+E7tR34bDwIueIjqP/WHqc5g6Ja3uCUODqE pAh3FDlqGksKsANBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1704314617; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MH/33LJwclbnRVYbQrCaFnIW8qHZ0ftviNOo+z0UVZs=; b=kIowGe/4pWOLoKLnuCEZrbsERORcVXIFR0GUeHQbEiGoLfKPKueSNbnjPvzw9W3SajytL FBQGHgwxxiiiYdgLl0fvMs4VugEqShz4dPV7XNm7DtkIrX/kraDiI3YkA/k/mutjkN7Bb9w FikjyjgdEJrFVjIG3JizjGZ0Y65dBqmjFVS8dLl8y0yqE65wBeN8fYL3bFm4J62L7zv8/dq aq6/NlLGIfHJ9RYhFYvuhsLZjbci1+3PgqoWShGQUXXerZYEvT9fgUkKQD3duJCwfGxwMuW CQKfzmv3nI56seR6nHwuczgK6Uujr1nvt2gZf2YAEtImTWi7/DsGQpnjRRsQ==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by (Postfix) with ESMTPSA id 28F5CF9D8; Wed, 3 Jan 2024 15:43:36 -0500 (EST)
Received: by (Postfix, from userid 1000) id 850A6205D1; Wed, 3 Jan 2024 15:43:33 -0500 (EST)
From: Daniel Kahn Gillmor <>
Cc: Andrew Gallagher <>, Werner Koch <>, Heiko Schäfer <>, Kai Engert <>
In-Reply-To: <>
References: <> <> <>
Autocrypt: addr=Daniel Kahn Gillmor; prefer-encrypt=mutual; keydata= xjMEZXEJyxYJKwYBBAHaRw8BAQdA5BpbW0bpl5qCng/RiqwhQINrplDMSS5JsO/YO+5Zi7HCw AsEHxYKAH0FgmVxCcsDCwkHCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZX F1b2lhLXBncC5vcmfUAgfN9tyTSxpxhmHA1r63GiI4v6NQmrrWVLOBRJYuhQMVCggCmwECHgE WIQTUdwQMcMIValwphUm7fpEBSV5r9wAAmaEA/3MvYJMxQdLhIG4UDNMVd2bsovwdcTrReJhL YyFulBrwAQD/j/RS+AXQIVtkcO9bl6zZTAO9x6yfkOZbv0g3eNyrAs0TRGFuaWVsIEthaG4gR 2lsbG1vcsLADgQTFgoAgAWCZXEJywMLCQcJELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YX Rpb25zLnNlcXVvaWEtcGdwLm9yZ3tfhOCIg3CfOHiNqvQ9/9vmGDEU+eAIXElKa2v9/RiJAxU KCAKZAQKbAQIeARYhBNR3BAxwwhVqXCmFSbt+kQFJXmv3AAAy7AEA+0yicpuEY6E7L7yaIBv+ ScnVwg8GMu6kluMz41QTVbIBAPWfIZb5fDAyumszBzfbSZ0kf0HSN2iQlkGI3v77Q2gEzjMEZ XEJyxYJKwYBBAHaRw8BAQdAjX25Fq2Q9IUFeHy6yByIQPBnFOedFliuEiCIUzJsENDCwL8EGB YKATEFgmVxCcsJELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGd wLm9yZ8KilrMOerqFlSyBXLO2XnCYMKbEjXr1gs274ikPMkS1ApsCvqAEGRYKAG8FgmVxCcsJ EHctFh41zUuBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9yZxCCUjsbs Nsv1CZoOTNwS6TdCWIzg2aV4hFRbtW8gEczFiEEdLwExD2GCEvoZywGdy0WHjXNS4EAALB/AQ CoNQuSyvw+6UpFwg/o300j/gqjOfIhy44eLyoaTirEyQEAh5XbRI8SdZLD0xYBvR4oRx+6nOv 8L7y8O+xEzKcJawMWIQTUdwQMcMIValwphUm7fpEBSV5r9wAAUPUA/RiwTcR6KDW2RZp7Ku+8 x/kqXW23Yt6RM1YOcH4VQb1KAP4pry989HzC5XwPfLlj1Cr3EY75CQQEJbRTWo3KmDrlAc44B GVxCcsSCisGAQQBl1UBBQEBB0BZMsRrRaaeFSYMF1ZdfRmVgBriDUIr99eDQ085BK14DgMBCA fCwAAEGBYKAHIFgmVxCcsJELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXV vaWEtcGdwLm9yZ7GswFl7RB1D5kk5nEWQCLALDYjvJNIXY7H0ZUVYqYCYApsMFiEE1HcEDHDC FWpcKYVJu36RAUlea/cAAFwlAP9/iW2lK8sE4ESH8LZ0hhp2BK6qQKqrQHhY6EVGRYlmVwD8D GotYbijxSuubCuYzjYWGDEq0RfAJIcTTS7zBHhSnwY=
Date: Wed, 03 Jan 2024 15:43:32 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
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: Wed, 03 Jan 2024 20:43:45 -0000

Hi Andrew--

Thanks for taking the time to think through one of the specific issues
raised in the present discussion, and to try to offer a concretely
useful step towards a resolution.  In some sense, this discussion is
re-hashing what came up in the working group over a year ago, in the
thread starting at,
and by the design team over in and related
issues and MRs.

On Tue 2024-01-02 00:54:40 +0000, Andrew Gallagher wrote:

> (@chairs: can you please add this to the list of WG documents?)

<chair hat on>

This is automatically done -- the datatracker does regex matching
against the I-D title slug to figure out what is intended for the group.

<chair hat off>

> This subpacket could then be used in both v4 and v6 sigs to add the
> missing functionality defined in librepgp v5 sigs. With no
> functionality differences remaining between v5 and v6 sigs, there is
> no justification to have them both, and with no difference in sig
> formats there is no reason to have two key versions either. This will
> allow us to reunify the public key and signature formats between
> crypto-refresh and librepgp.

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?

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.

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.  There are better ways to communicate this sort of information
without it being part of the OpenPGP specification.  For example, it has
always been possible to sign a tarball or a MIME tree; then the tar
format or MIME structure itself will be able to contain whatever
arbitrary metadata the signer wants to ensure is cryptographically

If we want to define some sort of "signed document structured metadata"
field to be contained in a signature, we can consider doing that, but:

  (a) other groups with more expertise in file management than this one
      have already done that work, and it is not part of the OpenPGP
      specification (they are, for example, part of MIME, or tar, or
      PAX, or whatever), and

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

Finally, it's not clear to me how an implementation should actually use
these fields even if they are (sometimes) cryptographically signed.  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)

Still more differences with v5

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: a v5 signature can be mechanically
transformed into a v3 signature over subtly different data, whereas a v6
signature cannot be aliased in this way.

Thanks to Demi Marie Obenour, who was the first person to notice this
particular risk that i'm aware of:

To my mind this makes it reckless for a single implementation to try to
support both v3 signatures and v5 signatures, particularly if the same
key material can be used in both v3 and v5 keys or if key versions are
not tightly bound to signature versions.  The easy answer today in 2024
is "don't accept v3 signatures", but even as recently about a year ago,
refusing v3 signatures wasn't acceptable on some significant pieces of

> 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!  It also seems possible to just define a new
subpacket type, or notation range to record specific file metadata

> The differing AEAD packets are outside the scope of this proposal, but
> we can come back to them later.

Thanks for focusing on one thing at a time :)