Hi!
And another issue about header change recipes specifically:
If a signer knows that there has a change for a specific field keys
but doesn't know the previous state, it can generate r_field=z.
However, if it only knows that there has been _some_ change with
header fields, but doesn't know which keys are affected, it can't
generate a kind of global header "z" recipe.
Might we need that?
I'm asking because in our first iteration here we assume that we
generate no changes (i.e. don't need to either incrementally generate
Message-Instance fields or keep an old version to calculate change
recipes at the end during signing).
However to have robust code, I'd still want to check if the hashes
I calculate match those in the latest Message-Instance. For a body
mismatch I can fall back to generating a new Message-Instance with
"r=z". But for a header mismatch there's nothing I can generate
right now?
Another thing: If some code that is not the signer changes the mail,
it will need to transport the changes to the signer.
It has been suggested that we allow the option for each such
"changer" to add a Message-Instance header to record its changes
(hence there was the allowance for different "revision" numbers
separate from the DKIM2-Signature indexes). This would allow for
some kind of separation of concerns between the modification usecase
and signing.
However, the modifier, in this case, would need to anticipate which
hash algorithm(s) will be eventually needed for signing and perform
the hash. This seems to be not exactly "separation of concerns"
in fact.
Of course the other possibility would be to have some internal
interface between changer and signer which would either transport
only *incomplete* Message-Instance values (only the recipes) or
the previous version of the mail to the signer. (In which case
there'd be no need to allow for more than one Message-Instance
added between two DKIM2-Signature headers. If there is a sequence
of several recipe sets, they can be merged in a relatively easy way,
while if the previous version of the mail is passed, the signer
would perform some kind of diff once and add only one Message-Instance).
Kind regards,
Hannah.
On 1/19/26 18:43, Hannah Stern wrote:
Hi!
On 1/7/26 16:54, Hannah Stern wrote:
On 12/25/25 02:29, Richard Clayton wrote:
I have put in the changes and clarifications I emailed about earlier.
I'll go through the draft with a few remarks:
- 5 Message-Instance/change recipes
- "r="... "c:"
* This addresses the overlapping/non-monotonic issue well.
* How would a verifier handle invalid specifications
(line number 0 or > number of lines)? Same as z?
Or completely invalid signature (permfail)?
* Would we want a shortcut for single-line copies?
Currently they're like "c:42-42"
- "r_header="
* This addresses the inconsistency with the tag-name spec
in the previous version.
* How are header field names with "-" handled though?
An obvious solution would be substituting an underscore.
Another possibility would be allowing "-" in tag-name.
* "c:" addresses the overlapping/non-monotonic issue well.
Same question for invalid header field numbers though.
Would we want a short-cut for single-header-field copies?
- "mi-rh-tag-data = mi-rh-recipes / %07A"
* s/0/x/
* Perhaps lowercase the "a" for stylistic consistency
with "mi-r-tag-data"?
I only now noticed more inconsistencies in the change recipe specs:
For body changes, the textual description says:
c: startnumber-endnumber
Copy the lines numbered startnumber up to and including the line
numbered endnumber. The first line of the body (immediately after
the blank line that indicates that there are no more header fields)
is numbered 1. If the endnumber is omitted then all lines
(from the startnumber line onwards) are to be copied.
The startnumber of every "c" instruction MUST be in ascending order
and MUST be greater than
the endnumber of all preceding "c" instructions. There MUST NOT
be any further "c" instructions after a "c" instruction with
an omitted endnumber. In other words a recipe is not allowed to
use "c" instructions to duplicate or re-order lines.
and the ABNF says:
mi-r-recipe = %x63 ":" 1*DIGIT "-" [ 1*DIGIT ] /
%x62 ":" [ base64string ]
In my eyes, this fits together.
However, for header change recipes, the textual description says:
c: startnumber-endnumber
Keep the instances of the header fields (with the relevant header
field name) which are at position startnumber to endnumber.
The startnumber of every "c" instruction MUST be in ascending order
and MUST be greater than
the endnumber of all preceding "c" instructions.
Unlike for body change recipes, this doesn't allow omitting the
endnumber.
The ABNF says:
mi-rh-recipe = %x63 ":" 1*DIGIT /
%x62 ":" base64string
This seems to not allow ranges at all and thus contradicts the
textual description.
In addition, the specification is dissimilar between body and header
recipes, allowing less code refactoring.
I'd suggest having the ABNF to be the same for both:
mi-recipe = %x62 ":" base64string /
%x63 ":" (1*DIGIT / 1*DIGIT "-" [1*DIGIT])
This way, "c" recipes would allow addressing a single line,
if there's no "-" at all in the recipe. It would also allow
the shortcut for "up until the last line".
I'd keep the semantic differences for "b:": for header fields,
the "Field-Name:" prefix is implicit.
I'd keep the semantic rule that the ranges named in "c:" recipes
must be strictly monotonous: Only the last entry may have the
form 1*DIGIT "-" without endnumber, and the 1*DIGIT form is just
a shortcut for number-number (with same start/endnumber).
I'd probably keep the "bottom-up" numbering semantics for header "c:"
recipes. Theoretically "top-down" could allow for leaving off an
endnumber more often (e.g. an MTA has added a "Foo" line at the top,
being the 42th instance of "Foo" - it could generate "c:2-" instead
of "c:1-41"). But as apparently people are already working on
implementations, this would be a gratuituous breaking change.
I could alternatively work with a different outcome too, as long
as the inconsistency between textual description and ABNF for header
recipes is fixed in _some_ way.
Kind regards,
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig,
Dr. Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte
den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
