At 11:27 AM 3/26/98 -0800, Jon Callas wrote:
In this particular case, I think there's merit in *suggesting* but not
mandating that the message id be a function of the message.
There's nothing wrong in suggesting that a hash be used,
but there are plenty of other suitable ways to do it, including
just taking a slice of funtional slice cyphertext, which is mathematically
"random" and cannot leak any information. Cyphertext is always sent
in the clear, as it were.
I also think there's merit in not mandating how it's done, as long as it's
deterministic. However, I'm willing to listen to anyone who wants to argue
that that MUST on determinism be a SHOULD.
There are at least three problems with Message-ID
- Is the implementation secretly leaking data through it?
- Is the implementation leaking data due to bugs or bad design?
- Does the message-ID increase traceability of the message?
The latter's been argued enough times, and we'll assume for the
moment the non-existence of bugs :-)
The problem with making it only a SHOULD is that the recipient,
and possibly the sender, can't verify whether it's leaking data or not.
If you make documentation of the algorithm a MUST, and the algorithm is
deterministic, then the sender can verify it, but the recipient doesn't
have access to the sender's documentation anyway. If you make
one or one-of-small-n algorithms mandatory, both the sender and
recipient can check. I lean towards "SHA1 or MD5 of the cyphertext",
ignoring any armor that might be present or whitespace-munged.
I suppose the same problem exists with initialization vectors and
session keys, and you can argue that
- if you _are_ paranoid, you shouldn't be using software without
reading the source code yourself first
- the sender could also be sending copies of the message to kgbvax
without sneaking it out through the IV or Message-ID.
Thanks!
Bill
Bill Stewart, bill(_dot_)stewart(_at_)pobox(_dot_)com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639