Hi!
On 7/16/25 19:27, Bron Gondwana wrote:
On Tue, Jul 15, 2025, at 11:01, Hannah Stern wrote:
How about multiple b=, like this:
DKIM2-Signature: i=1; d=example.com; b=hash1:signature1:selector1;
b=hash2:signature2:selector2; ...
I.e. allow multiple b= and combine bh and selector into the signature
(bh too as to allow for different hash algorithms as determined per
selector)? The format itself could be without hard format-defined limit,
but the standard should probably set technical limits (signers MAY NOT
add more than 10 signatures, verifiers SHOULD accept up to 10
signatures, or something)?
There's an issue with multiple same-name keys. Actually there are two
issues:
1) the algorithm right now in DKIM for calculating 'b' is defined here:
RFC 6376, Section 3.5 <https://datatracker.ietf.org/doc/html/
rfc6376#section-3.5> The DKIM-Signature Header Field
The DKIM-Signature header field being created or verified is always
included in the signature calculation, after the rest of the header
fields being signed; however, when calculating or verifying the
signature, the value of the "b=" tag (signature value) of that DKIM-
Signature header field MUST be treated as though it were an empty
string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored
by Verifiers.
So I presume we'd have to create the header with all the b= values,
otherwise with multiple signatures they'd all try to sign each other and
that would be an ordering impossibility.
Or we omit the dummy b= values before signing. I.e. we sign the
currently-being-generated/verified header as if the b= tags were
completely absent. We're not bound do how DKIM1 does that, are we?
2) the format of these headers is defined in:
RFC 6376, Section 3.2 <https://datatracker.ietf.org/doc/html/
rfc6376#section-3.2> Tag=Value Lists
Which says this:
Tags with duplicate names MUST NOT occur within a single tag-list; if
a tag name does occur more than once, the entire tag-list is invalid.
So if we want to allow multiple b= keys, we would have to change this
definition, which might cause issues with existing libraries that were
built on this invariant.
We could lift that restriction. I think a) we're probably needing new
libraries anyway, b) changing code to allow for multiple same-name tags
should be feasible.
Hannah.
--
Hannah Stern Mail System Development
www.mail-and-media.com 1&1 Mail & Media Development & Technology GmbH
[email protected] Brauerstraße 48 76135 Karlsruhe Germany
+49 721 91374-4519
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Dana Kraft,
Thomas Ludwig
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]
