Douglas Otis wrote:
Rather than waging a battle over how robust a signature should be, by
allowing a message-state header that describes the message content to
detect what has been damaged could easily serve two very legitimate
purposes. One being the detection as to what is being damaged within
the message, the other would be to allow a more discerning means for
rejecting a message on the basis of a signature failure. Let the market
decide how this gets used.
Something like- (see: rfc2822 & rfc2045/6/7)
H0 := "RECEIVED"
H1 := "MESSAGE-ID"
[etc.]
As compared with copying the headers, the only advantage I see here is
that this trace header is shorter. Is that advantage worth the effort
and complexity of defining a new language (that would need to be
extended as new headers get invented, I suppose)?
Also, if a message signature fails and it turns out that one of the
headers has changed, that's still not enough information to know that
there hasn't also been a cut & paste attack on the body. In fact, it
seems like one could substitute anything, and then provide a MSTATE
header that makes everything but one of the header fields look good, and
the recipient is likely to think that just that one header has changed.
In other words, this has diagnostic value but does not provide a more
discerning means for rejecting a message. Or am I missing something?
-Jim