[Ietf-dkim] Re: I-D Action: draft-ietf-dkim-dkim2-spec-01.txt

[Steve Atkins <[e-mail]>]

> On 23 Apr 2026, at 17:42, Hannah Stern <hannah.stern=[e-mail]> wrote:
> 
> Hi!
> 
> On 4/23/26 15:08, Steve Atkins wrote:
> 
>>> On 20 Apr 2026, at 13:06, Richard Clayton <[e-mail]> wrote:
> 
>>> [...]
> 
>>> As presaged a while back -- and no-one objected, I have removed the
>>> definition of tag value list and incorporated the relevant text into the
>>> descriptions of Message-Instance and DKIM2-Signature. This is the only
>>> change that implementors MUST address -- the trailing ";" on these two
>>> header fields is now required.
> 
>> This is a change from previous usage of tag value lists, and might
>> reduce some code reuse for header generation as existing libraries don’t
>> necessarily add the trailing semicolon.
> 
>> But as someone who mostly writes code that validates these fields I do
>> find the mandatory trailing semicolon a useful check to protect against
>> truncation.
> 
> I'm not sure I agree with that consideration.
> 
> Truncation will be caught in verification because it invalidates
> signatures.
> 
> So for me the trailing semicolon change is mostly inconsequential
> and I'm mostly agnostic about it.
> 
> Might simplify one or two code paths in generation/parsing though.

I don’t think there’s a lot in it either way. I’d marginally prefer it
being either required or forbidden rather than optional, just to
reduce the test space a little.

> 
>> The other is that the narrative text describes the body recipes as
>> either null or an array of recipe steps (“c”, “d” or “z”) while the json
>> schema describes it as either null, or a {“z”: true} object or an array
>> of recipe steps (“c” or “d”).
> 
> I'd want to do away with "z".  There has been discussion in some other
> thread that that's actually not useful.
> 
> In a DSN the original message is included either as is or headers only.
> 
> The verifier inspecting a DSN can easily "know" if the body is left
> off without such a hint.  (Check original body empty and the hash
> in the original newest Message-Instance doesn't match - the latter
> only if you need a distinction between "original message actually
> had an empty body" and "original message had a non-empty body
> that's not included in the DSN".)

Yes, I’m not sure the use case is there.

> 
>> I think the json schema might be simpler to understand if we treated
>> header steps and body steps separately, rather than reusing recipe-steps
>> for both.
> 
> That argument goes in the opposite direction to the argument for
> tag-lists.
> 
> Once you omit "z", you have uniform types (only with null alternatives
> in 2 places, namely directly under "h", as alternative to the
> field-name -> recipe-steps object, or directly under "h" as
> alternative to recipe-steps (an array) directly).

Agree. If they’re actually identical, rather than mostly identical plus
“z”, then describing that array just once is better.

Cheers,
  Steve