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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp