Somebody, possibly Jim Fenton wrote on Saturday, September 18, 2004 9:15 AM
(I'm unsure) this text:
Both DomainKeys and the next revision of IIM have provision for
specifying a canonicalization (see the b: tag on the IIM-Sig
header on this message for a sample). Should we have a
signature for the strict (non-canonicalized) form of the
message as well, to give that option to the recipient as well?
I may propose other scheme for signatures. Instead of always doing canonization
create a two-step signing process.
1. Compute hash code for message in canonicated form.
2. Put this information about this hash and current timestamp in email header.
3. Apply a digital signature on information from this header and To: Cc: (or
Bcc: ) header.
4. Put a signature in email header.
Thus people can verify if signature match hash, timestamp and their address
first.
And paranoid one can verify content of message after this.
Thus we can solve problems with somebody can not perform canonicatation
requested or message was altered in transit.
People will still be able to check if this message looks like legit or clearly
a forgery.
If we will not store hash code for message - then nobody will be able to tell
if signature is incorrect or something really bad
happened with message.
Replay will be avoided using timestamp and hashcode collision checks.
Remailers can use additional Bcc: field data created by hashcode header.
Hash for message can be an optional header and will be possible (theoretically
only) to avoid in future.
--
Andriy G. Tereshchenko
Odessa, Ukraine