On Wed, 2004-09-01 at 05:32, Jose Marcio Martins da Cruz wrote:
> Jim Fenton wrote:
> >I suspect that the other cases can be solved by specifying that the To:
> >and Cc: lines are to be signed (using headerlist canonicalization or, in
> >0.2.0, the h= tag in the signature).
> No, I'm talking about verifying an already signed message. So, the
> filter shall check, when verifying, if there were any header of this
> kind inserted after the message was signed - so before the signature, in
> the linked list of headers.
> A particular case is when original message has no "Cc" header, and a
> "Cc" header is inserted after the message was signed. In this case, the
> verifyed message will have 1 To header and 1 Cc header. So, the message
> conforms to RFC 2822, but the message is replayed.
> /* either 0 or 1 To: or Cc: */
> if (dkf_findheader(dfc, "To", 1) != NULL)
> ok = FALSE;
> if (dkf_findheader(dfc, "Cc", 1) != NULL)
> ok = FALSE;
> As this is a linked list, the check should be done taking into account
> the position of the header relative to the signature header. And the
> result of the check shall be declared bad if one of these headers (Cc,
> From, To) is found before the signature header.
One of the goals of the h= tag in the signature is to define both which
headers are signed and the order in which they are presented to the
signing algorithm. This is because the order isn't always reliable. I
believe that (at least in the presence of the h= tag) the intent is to
collect all of the headers of the specified types, and put them in the
order shown. This includes the headers that come before
It seems like one should be able to list Cc in the h= list, even if it's
not present. That would catch any Cc that is added to the message.
You do point out a problem though: In such a case an attacker could
remove Cc from the h= list (and then add the Cc line) because the
DomainKey-Signature header itself isn't signed.