On Tue, Jul 15, 2025, at 11:01, Hannah Stern wrote:
> Hi!
> 
> 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.

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.

Regards,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [email protected]

_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to