The current draft states the following on the generation
of Message-IDs:
- "MessageID", a 32-character string of printable
characters. The string must be the same for all parts of
a multi-part message that uses the "PART X" Armor Header.
MessageID strings should be unique enough that the
recipient of the mail can associate all the parts of a
message with each other. A good checksum or cryptographic
hash function is sufficent.
The MessageID should not appear unless it is in a
multi-part message. If it appears at all, it MUST be
computed from the message in a deterministic fashion,
rather than contain a purely random value. This is to
allow anyone to determine that the MessageID cannot serve
as a covert means of leaking cryptographic key
information.
I consider this to be a dangerous approach, since it may
let _plaintext_ information leak to the public: Consider
some (broken) implementation using an SHA1 hash of the
message - to "prove" that some suspected plaintext is
actually the one you have, you only need to have a look at
the Message ID.
Even worse, an implementation which uses some part of the
plain text, encrypted with a symmetric algorithm, could
use this stuff to leak known plaintext while still being
compliant to the standard, while an implementation using
random values would _not_ comply.
As a solution, I'd suggest to mandate the use of a certain
hash (sha1?) of the armored text, i.e., the _encrypted_
message. (Most probably it's meant that way, but let's
make the text unambiguous.)
tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1