Hi!
A few comments on the v4->v5 changes.
On 8/25/26 18:23, Richard Clayton wrote:
after some delay (I went to see the eclipse in Spain and drove back in a
leisurely manner) here is the latest version of the spec
It must have been great in Spain!
implementors should note:
there is a much extended list of header fields that should not be
signed --- this follows from the work that Bron did (with Claude's
help) to identify trace header fields from existing RFCs
sha512 is now required as a hash function alongside sha256. This is
mainly to allow implementors to test their code for multiple hash
functions; we might want to take it out before finalising the
document but for the moment it is a MUST for Verifiers
I observe that for the "top-level" hash/signature, we still only have
rsa-sha256 and ed25519-sha256. Cryptographically, I'm not sure how much
sense it makes to have sha512 in Message-Instance, but then hashing them
(textually via the Message-Instance fields) with sha256 at signing time.
there is now text to forbid repetition of algorithm or selectors
(there's no interop issues here, but it means you can reject
messages that are just trying to push up your electricity bill)
I read some inconsistency there:
- For M-I the language is clear, only at most one hash of a given type
- For D2-S, the language is less clear. I interpreted the previous draft
to forbid duplicate selectors already, but not duplicate algorithms. Now
the language says that duplicate algorithms are actually allowed, but at
most 2 signatures per algorithms. So I guess, it should be legal (with
different selectors), to have 2 RSA signatures (e.g. different key
size), 1 ED25519 (theoretically 2 would be allowed, but it would be more
pointless as you can't even vary key strength there), and 2 PQC (same
scheme, different strength), and perhaps another different PQC algorithm
or a custom extension algorithm.
- But later in the error messages, there's the error string
"DKIM2-Signature i=<x> has too many signatures" suggesting a limit (from
the standard, not operationally imposed) on _total_ number of signatures
per DKIM2-Signature field?
So what's the actual intention here?
however, the SHOULD NOT on specious Message-Instance fields is toned
down (they are now just discouraged)
I think that's okay. M-I fields with the same hashes (no recipes) are
pointless as you say (except they result from a change reversal, i.e.
there is an M-I with different hashes in-between; or if a later M-I has
no recipes but adds more hash algorithm(s)), but not too expensive.
Header field names in the JSON Recipes MUST be lower case; and
Verifiers should now report JSON issues specifically.
I'm glad about this change.
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]
