My apologies for not jumping in here sooner.
The consensus that I've seen is against overloading message integrity on
signature packets. We also discussed it in Orlando, and there was great
consensus against it there. I confess that personally, I also question the
wisdom of separating them. Especially if it requires a shared key.
In Orlando, there was consensus that we wanted to add several things to
OpenPGP for our next RFC. They were:
(1) Message Integrity Codes (a.k.a. MDCs or whatever. I've been using the
term Message Integrity Code or MIC -- if people prefer the other
terminology, I can write it up that way.)
(2) Normalization of encryption modes. Among the solutions to this are (a)
using normal CFB mode or (b) using CBC mode. I've heard from people who
prefer each, and don't know if there's a consensus on which is better. I
don't care.
(3) Rich user IDs.
(4) A V5 signature packet that allows 4-byte lengths. There's a tangential
discussion to this that is to start deprecating some of the more bizarre
length types, but that's a can of worms I don't want to open today. Next
week.
(5) A signature sub-packet that allows a certificate to declare which of
the above advanced features it speaks. I've been calling this the
"features" subpacket.
Only (1) and (2) are germane to this present discussion.
A scheme that has been discussed, and I thought we had a lot of agreement
on even back in Orlando was to solve (1) and (2) with a new encrypted data
packet that used a standard encryption mode and appended a hash at the end.
I've been in discussion with several people who've offered several opinions
on what that hash can or should be, and I believe that the best thing to do
is just make it a SHA-1 hash, as a minimal OpenPGP implementation must
already have SHA-1 in it. No one who's done any work on it has come up with
a different solution that is better.
I really don't like overloading MICs on signature packets. That's a kluge,
and it offends my sensitive architect's aesthetics. OpenPGP already has
quite enough kluges in it. I'd prefer to stomp on a few rather than add
another. Adding in shared keys makes it a worse kluge. I can't see what
goodness comes from a null-signature packet.
I've been waiting for someone else to create this packet, and I'm tired of
waiting, so here's *my* definition of it. This new packet is like Packet 9
in semantics but consists of:
- Encrypted data, the output of the selected symmetric-key cipher
operating in (XXX) mode.
- A 20-octet SHA-1 of the plaintext contents of the packet. Note that if
the contents of the encrypted packet is another packet (or packets), the
hash runs over the whole of them.
I confess that I am concerned about the possible implementation
difficulties here, but I'm also confused, because I don't see the problem.
Unless the packet is encoded with indefinite length, you know how long the
thing is. So you just subtract 20 from the length, and you know how much to
hash. I am willing to write in there that if the packet is coded with
indefinite length, the last chunk MUST include at least one byte of data
and the 20-byte hash. Does this help any implementation problems? Tom? Hal?
Werner?
Jon