>> I'd say that it would be better to just say that if you sign a >> non-compliant 5322 message that its verification is undefined, >> and move on. That at least matches reality, and hasn't hurt >> anything that I'm aware of.
Except that's not the situation we have here. a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone d) Receiver receives it and, uh, well, what? Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. As far as I can tell, this problem, detecting header changes, is a security problem that has never come up before. PGP, S/MIME, and PEM only protect the body, in some cases by wrapping the entire message as a message/rfc822 MIME body part and signing that. RFC 2822 and its predecessors tell you what is a valid message, but say approximately nothing about invalid messages other than a few historically motivated notes like bare linefeeds really are invalid. I think I can safely say that there is no chance at all that Pete Resnick et al. would agree to change 2822bis to fix holes in DKIM. I'm scratching my head to see if there is any advice we can offer to make signing and verification more robust while not changing the behavior of existing code for normal (for some definition of normal messages). A) You have to sign either all occurences of a header or none of them, and a message with some but not all occurences signed fails verification. This is probably too strong, although I doubt that there are many places in practice where it would matter. B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html