I still don't see that the signature packets are a very natural or
comfortable place to put this data.
We would probably use one-pass signature packets for this so that the MDC
(MIC) can go at the end and the encryptor doesn't need to buffer up all
the data. The format of a one-pass signature is:
- version number
- signature type
- hash algorithm
- public key algorithm
- signing keyid (8 bytes)
- nesting flag
Most of these fields are not relevant for the MDC. We need to put
a magic value into one of them (Tom is looking for all-zero keyid,
others had suggested using a zero public key algorithm). The others are
really not meaningful. The signature type with all its variations is not
relevant; hash algorithm is unnecessary, a fixed hash algorithm is fine;
public key algorithm and signing keyid aren't meaningful; nesting flag
is not relevant either.
Likewise, the signature packet fields are equally meaningless:
- version number
- length of hashed portion (must be 5)
- signature type
- signature creation time
- key id of signer
- public key algorithm
- hash algorithm
- left 16 bits of hash
- Multi Precision Integer holding the signature
Again, we have signature type, key id, public key and hash algorithms,
all unnecessary or irrelevant. We have a timestamp, also inappropriate
for an MDC (which is inherently a transient concept). We have the left
16 bits of the hash! Will we keep that, when we're going to be storing
the hash itself in the MPI signature field? It's just going to be a copy
of two bytes of the hash. Utterly pointless.
And last we have the signature itself, which is the only meaningful piece
of data in this entire packet, since that is where we will put the hash.
We have to agree on how to encode the hash, presumably as an MPI, which
implies special treatment of leading zeros. Or maybe we'll just shove
the 20 bytes in there and have done with it since we're misusing the
rest of the packet so badly anyway.
Looking over these comments, it's clear that these packets are completely
inappropriate for the use to which we are proposing to put them.
This solution is a real kludge.
If we absolutely, positively had to put this data into signature packets,
maybe we should create a new version of the packets and use that.
Or better still, use new packet types. Make the prefix packet be just
a flag that the following data will be checked with a MIC. Then make
the trailer packet just have the MIC in it. Simple and clean, unlike
the above.
Or even better, use a special encryption packet to indicate that there
is a MIC (MDC) following, and a special MIC packet to hold it following
the encryption packet, as Werner proposed. It is not too different from
the original idea and if it would help with the implementation it seems
like a reasonable method.
Hal