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

[Daniel Kahn Gillmor <[e-mail]>]

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

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

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

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

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:

  https://dev.gnupg.org/T3389

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?

         --dkg