Here's a proposed fix to the oops that Hal found:
-----
The plaintext of the data to be encrypted is passed through the SHA-1 hash
function, and the result of the hash is appended to the plaintext in a
Modification Detection Code packet. The input to the hash function includes
the prefix data described above which acts as a weakly keyed hash; it
includes all of the plaintext, and then also includes two octets of values
0xD0, 0x14. These represent the encoding of a Modification Detection Code
packet tag and length field of 20 octets.
The resulting hash value is stored in a Modification Detection Code packet
which MUST use the two octet encoding just given to represent its tag and
length field. The body of the MDC packet is the 20 octet output of the
SHA-1 hash.
The Modification Detection Code packet is appended to the plaintext and
encrypted along with the plaintext using the same CFB context.
During decryption, the plaintext data should be hashed with SHA-1, including
the prefix data as well as the packet tag and length field of the
Modification Detection Code packet. The body of the MDC packet, upon
decryption, is compared with the result of the SHA-1 hash. Any difference
in hash values is an indication that the message has been modified and
SHOULD be reported to the user. Likewise, the absence of an MDC packet, or
an MDC packet in any position other than the end of the plaintext, also
represent message modifications and SHOULD also be reported.
-----
I can quickly (like in 30 minutes) pop off another draft if this is
acceptable. Comments ASAP.
Jon