On Mon 21/Jul/2025 16:53:16 +0200 Hannah Stern wrote:
On 7/16/25 10:42, Alessandro Vesely wrote:
On Tue 15/Jul/2025 17:01:14 +0200 Hannah Stern wrote:
[...]
Or
bh1=hash1;bh2=hash2;b=1:signature1:selector1;b=1:signature2:selector2;b=2:signature3:selector3
There seems to be some confusion on field names. Isn't b= the actual
signature? And bh=? The body hash ought to be the same for all signatures.
And no, body hash isn't the same, as a algorithm specifies the hash function
used, as in "rsa-sha256". So you could as well have algorithms like "rsa-
sha3-512" besides that.
You're absolutely right. When we adopted Ed25519, we forced it to sign a
sha256 hash instead of the actual canonicalized text (likely limiting some of
the anti-collision properties intended by the algorithm design.)
In a PQ scenario, SHA itself may be cracked, so the ability to change bh is
essential.
However, the implementation considerations that guided the choices of RFC 8463
may still apply to a PQ algorithm. Therefore, we should devise a format in
which some tags have multiple values, dependent on the algorithm, while others
are valid for the whole signature. The selector may also require this flexibility.
How about using, besides normal tags, tags of the form
colon-separated-struct-def "=" colon-separated-values, like so:
DKIM2-Signature: s=default-selector; bh=common-bh; a:b=rsa-256:GBrish1...;
a:b=ed25519-sha256:GBrish2...; a:b:bh=pq1-sha512:GBrish3...:GBrish4...;
a:s:b=whatever-sha256:its-own-selector:GBrish5; ...
Elements not present in a structure are taken from simple tags, while any
signature can override any other element by specifying its values in the order
indicated by the structure definition.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
