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

[Marcus Brinkmann <[e-mail]>]

Hi,

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

https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf

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

Thanks,
Marcus

-- 
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
http://www.nds.rub.de/chair/people/mbrinkmann