On Wed, 2006-06-07 at 09:01 -0400, Tony Hansen wrote:
You have to differentiate between a DKIM-Signature header that's being
created and/or verified, and a DKIM-Signature that was there previously
and has now been included in the list of headers that are part of the
message being signed and/or verified.
The b= nullification applies only to the DKIM-Signature being created
and/or verified. It does not apply to any other DKIM-Signature headers
that may be included as part of the message header.
When I read -base, this seemed clear enough to me.
It would seem this is also not very clear either:
,---
| 3.7 Computing the Message Hashes
|
| 2. The "DKIM-Signature" header field that exists (verifying) or will
| be inserted (signing) in the message, with the value of the "b="
| tag deleted (i.e., treated as the empty string), canonicalized
| using the header canonicalization algorithm specified in the "c="
| tag, and without a trailing CRLF.
|
| All tags and their values in the DKIM-Signature header field are
| included in the cryptographic hash with the sole exception of the
| value portion of the "b=" (signature) tag, which MUST be treated as
| the null string. All tags MUST be included even if they might not be
| understood by the verifier. The header field MUST be presented to
| the hash algorithm after the body of the message rather than with the
| rest of the header fields and MUST be canonicalized as specified in
| the "c=" (canonicalization) tag. The DKIM-Signature header field
| MUST NOT be included in its own h= tag.
'---
Where is the text that describes the different treatment of a previously
existing DKIM-Signature header?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html