Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header

Daniel Kahn Gillmor <> Sun, 07 July 2019 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E2B61200B4 for <>; Sun, 7 Jul 2019 13:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=R3HEYamf; dkim=pass (2048-bit key) header.b=HxlFoqYQ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zOE_YKmWydZn for <>; Sun, 7 Jul 2019 13:28:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFDDD12008F for <>; Sun, 7 Jul 2019 13:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ApFxaoForyqPQCVivS4NF2o1mVYlTussv2Ui9q/O2I4=; b=R3HEYamf9ktrnyo1MWi/z1vWIePV3jGDhSULKiSz5XuK0aUe4Jm0dj1L iN95B/MxrFCLd7dADAdvCC0mDXiiDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ApFxaoForyqPQCVivS4NF2o1mVYlTussv2Ui9q/O2I4=; b=HxlFoqYQ2kIx0oPyCQOntTgszTowIjjIWeWZ5l0s4jfNLtOmauLXa29K MXgT+hxtSkiku3eJ7eqV0U9dchpEZSlfuzSRriJ7ESFReBPmR4fJSk4f9m ULW4K7F4UulPjH/THSaRD0iDdys/UYLABkYwGkIN1yCyjqFh6vCbGlL77M rfU37tN4qml1NJwPGJ3I5LAMXAykWIx7F4ezXFo3OX64ZLtxGAJlAGBWkf zfDNbtUROlQb/WfccOm2skmFje1eJgHZMVaXeOFas/ZwSzKVW7s8MtzHy0 IWAInIi9+CQ8nTigQtceN53sWNcQ8ki+kp3XP1sDqv683w1aKe/rgA==
Received: from (unknown [IPv6:2001:470:1f07:60d:5cf3:eff:fee2:4b88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FA69F9A2; Sun, 7 Jul 2019 16:28:55 -0400 (EDT)
Received: by (Postfix, from userid 1000) id CEFDE20A70; Sun, 7 Jul 2019 16:23:19 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Marcus Brinkmann <>,
In-Reply-To: <>
References: <> <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Sun, 07 Jul 2019 16:23:19 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Jul 2019 20:29:03 -0000

On Sun 2019-07-07 01:56:19 +0200, Marcus Brinkmann wrote:
> That seems almost like a bottomless pit.

Totally agreed, fingerprinting surfaces are a drag. Nonetheless, the
people best equipped to enumerate them are the folks with
domain-specific knowledge, like you've done here.

Thanks for starting up a list.  You're basically identifying places
where implementers have a non-obvious choice to make when generating
OpenPGP constructs.  Perhaps the right form for this guidance would be
text that says what reasonable implementations should do.  I'll propose
a few below:

> 1. The embedded timestamp and filename in a literal data packet.

I'm not sure how these would vary across implementations.  perhaps the
guidance should say "in the absence of a requirement to the contrary,
the timestamp should be set to zero and the filename should be zero
octets in length."

> 2. The block sizes for partial data packets, and when they are used.

Partial data packets SHOULD NOT be generated.  In the event that they
are generated, partial data packets SHOULD have a length represented by
the value 236 (meaning, the packet has a length of 1<<(236&0x1F) == 4096

> 3. The signature subpackets used and their order (hashed and
> unhashed).

Which hashed subpackets to use: i'm not sure about this.  suggestions?


Implementations SHOULD emit signature subpackets in subpacket type
order.  If multiple subpackets of a given type are present, they SHOULD
be ordered based on the binary representation of the
subpacket. (0x01ffff comes before 0x020000, etc).

Implementations SHOULD NOT emit unhashed subpackets without a concrete
reason to do so.

> 4. Possibly the details of the compression.

Implementations SHOULD NOT generate compressed packets.  If they do,
they should prefer Bzip2 over Zlib over ZIP.  (is this right?  what
about per-format compression details?

> 5. The length of the base64 encoding.

I think this means line length.

Implementations SHOULD generate Radix-64 data encoded such that all full
lines have 64 printable characters in them.

> 6. Potentially the order of signature packets.

I'm assuming this is about signature packets over a data, not user ID
certifications or subkey signatures.

If multiple signature packets are attached to a piece of data, they
SHOULD be ordered by their creation date (oldest signature first).  If
multiple signatures share the same creation date, they SHOULD be ordered
by their binary representation.

> 7. The value of any quick check bytes (some implementations set them to
> invalid values to discourage checking them).

That's news to me, thanks for raising it.  Can you point to
documentation about that?

> For keys:
> 1. Again the signature subpackets used and their order.

Same as above, i think.

> 2. Potentially the details of the user id.

as most of this is entirely user-visible (and user-selected), i'm not
sure how much implementations can do here.  Perhaps we should recommend
using Unicode canonicalization form C for the UTF-8 string though?

> 3. Algorithm and other preferences and flags.

These compatibility markers will invitably leak some information about
the local implementation, as they are needed for interoperability.  We
can provide guidance on the ordering of those preference though.

> 4. The cryptographic parameters of public keys (RSA exponent etc)

The chosen RSA exponent SHOULD be 0x10001.

(suggestions for other parameters for other pubkey algorithms welcome!)

> 5. S2K count.

Modern hardware is fast.  Implementations that emit an S2K packet SHOULD
use Iterated + Salted S2K, and the S2K count SHOULD be 65011712
(single-octet representation 255).

> 6. Possibly resolution of any timestamps.

Isn't the specification's 1-second resolution reasonable?  Do we want to
encourage something different?

One other item for OpenPGP certificates ("keys")"

7. order of certification packets, order of user ids, etc:

I proposed a canonicalized structure for OpenPGP certificates over here:

Perhaps this should be a supplementary implementator guidance draft,
distinct from the specifying RFC?  Then we could also update it as new
fingerprinting surface is discovered, without revising the RFC itself.
Anyone interested in starting a draft?