Stephen Farrell wrote:
Well, happy new year all.
Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the "MUST NOT"
on the "z=". Correct me if I'm wrong there.
Was there a suggestion for new text for the "z=" that we can
consider? (Sorry if I missed it.)
My input on this.
Based on the earlier discussions about this, I found it to be a wasted
tag with meaningless value because of the idea it was "acceptable" that
the contents of the tags could be different what the actual header
values are, including having other header values that were not
necessarily part of the hashing.
Under those considerations, it could be *only* be used for some
diagnostic reason only understood by the signer and if there is any good
reason, I would think it would be for analyzing changed header values.
So if there was an *official* way to determine if a header change did
take place, then maybe the Z= tag might be useful here for explaining a
possible signature failure. We already have the body hash, so if that
turns out to be ok, then "possibly" a signature failure was due to a
header change. But that only be done if a copy of the headers used for
signing are stored in the z= tag.
If this becomes acceptable, then its quite possible for a verifier to
short circuit the verification hashing overhead if the h= header values
do not match z= values. That would be a big plus in the verifier world.
It is quite possible to use this for checking DKIM signed mail that have
arrived from list servers. A specific verifier may wish to do a brute
force checking concept, 1) first check the h= headers, then if that
fails, 2) replace the header values with the z= copy and check again.
By far, the typical list server minimum mutations would be:
1) optionally adding a [listname] tag to the subject line
2) optionally adding a footer to the body.
Its quite possible for the verifier to resolve the body with the l=
length, and the subject change, if hashed, with the z= copy.
So if there any proposal for text change here, I would suggest that the
z= tag, if used, "SHOULD" include a copy of the hash header values or at
the very least, the copy of the header "most likely" to change for the
DOMAIN intentional chosen DKIM MAIL ROUTE of this mail that may suffer
mail integrity issues.
If anything, change this text:
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
to:
Verifiers MAY use the header field names or copied values
for checking the signature and comparing expected header
values.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html