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

Marcus Brinkmann <> Wed, 10 July 2019 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 614DA12017D for <>; Wed, 10 Jul 2019 00:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id giJmLfaNvbIF for <>; Wed, 10 Jul 2019 00:42:01 -0700 (PDT)
Received: from ( [IPv6:2a05:3e00:c:1001::8693:2ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4623120154 for <>; Wed, 10 Jul 2019 00:42:00 -0700 (PDT)
Received: from (localhost []) by (Postfix mo-ext) with ESMTP id 45kB392ZYXz4wJ4 for <>; Wed, 10 Jul 2019 09:41:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail-2017; t=1562744517; bh=su89ivCDUK45Sc4mk9b6YUUDTDaS/kS0dLf8I1/xkUk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q5nTia45G3ivEVXsrLqWJvYMCYYAAqjXn4UVnwp1UO2O6aO2jQIBUuTLpt/QJLgl+ oG1Gx8Y4UrrqQHHg4c7gDx8KcwQP3qQcWC4lUhrGcQJkCyS9E9GqfFmtcMYPhZQMpb mEIdBSWWxpV8dTzP8fNpzhpzYvSqEGyk1/9oMAS4=
Received: from (localhost []) by (Postfix idis) with ESMTP id 45kB391XJNz4w66 for <>; Wed, 10 Jul 2019 09:41:57 +0200 (CEST)
X-Envelope-Sender: <>
X-RUB-Notes: Internal origin=
Received: from ( []) by (Postfix mi-int) with ESMTP id 45kB3908ljz4wJ4 for <>; Wed, 10 Jul 2019 09:41:56 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 45kB386fmnzytt for <>; Wed, 10 Jul 2019 09:41:56 +0200 (CEST)
References: <> <> <> <> <>
From: Marcus Brinkmann <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Wed, 10 Jul 2019 09:41:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.4 at
X-Virus-Status: Clean
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: Wed, 10 Jul 2019 07:42:04 -0000


On 7/7/19 10:23 PM, Daniel Kahn Gillmor wrote:
>> 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."

Well, the encoding can be different, filenames can be typical for an
operating system, etc. I'd just zero it all out.

>> 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
> octets).

Actually, it would be more stable to always use partial data packets
with a fixed chunk size (plus rest).

>> 3. The signature subpackets used and their order (hashed and
>> unhashed).
> Which hashed subpackets to use: i'm not sure about this.  suggestions?

That's a large topic, unfortunately.  Probably requires some research, too.

> order:
> 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).

Subpacket length must be canonicalized, too, like packet lengths.  But
there is some trouble here: There are private or experimental subpacket
types, and a generic implementation won't know if the order matters.

> 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?

For example, block size. In general, I think there is a lot of
flexibility in choosing the huffman tree and such.  Dunno if that
actually happens in the real world.

>> 5. The length of the base64 encoding.
> I think this means line length.

Yes, sorry.

> 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?

Unfortunately, I can't find it. It might just have been an idea I read
about somewhere, without implementation, or an obscure niche
implementation. It was an interesting idea, though, so it stuck in my head.

>> 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?

I agree that user-visibility makes this different from the other items
on this list.

>> 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!)

Prime generation and random number generation:

The Million-Key Question—Investigating the Origins of RSA Public Keys
(Petr Švenda, Matúš Nemec, Peter Sekan, Rudolf Kvašňovský, David
Formánek, David Komárek, and Vashek Matyáš, Masaryk University),
25th USENIX Security Symposium

>> 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?

For example, when creating a new key with multiple subkeys, an
implementation could have the same or different timestamps for them.

> 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?


Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030