-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <179237369481.304694.17403701817247439618@dt-datatracker-
7457c9c988-j45f7>, [email protected] writes
>Internet-Draft draft-ietf-dkim-dkim2-spec-07.txt is now available. It is a
>work item of the Domain Keys Identified Mail (DKIM) WG of the IETF.
>
> Title: DomainKeys Identified Mail Signatures v2 (DKIM2)
> Authors: Richard Clayton
> Wei Chuang
> Bron Gondwana
> Name: draft-ietf-dkim-dkim2-spec-07.txt
> Pages: 60
> Dates: 2026-10-18
There's heaps of tidying up here ... I have spent about 4 man-days (and
a whole heap of $DAYJOB$s tokens getting reviews from Claude) with a
view to making sure everything here is clearly specified and consistent.
I wrote the text BTW, Claude just told me (many times) what was still
wrong with it (until I explained that it was mistaken!)
If you are an implementer the main change is a new signing algorithm,
along with some carefully specified rules for checking the Chain of
Custody which covers a number of lacunae that clearly no-one had
encountered yet with null mail froms and nd=
A high level view of the changes is in the changelog section:
* Removed donotmodify and donotexplode.
there appeared to be WG rough consensus on this
* Added the composite PQ algorithm MLDSA44-Ed25519-SHA512.
as instructed by the interim (but I now think this is not the
right thing to do, see another message of mine)
* Required From header fields to be Authentic
from the interim
* Outlawed duplicate JSON keys.
long list discussion about JSON but the only spec change to come
out of that was this restriction (that cannot go in the Schema
so it is in the text)
* Added "u" steps in Recipes to handle non UTF-8 characters. Also
added patterns to the JSON schema to aid validity checking.
addresses the issue Hannah raised long long ago and we'd
overlooked. I didn't use "b" to avoid confusion
* Resurrected tag=value definition.
this seems the simplest way out of the mess
* Substantial rework of verification text to ensure it only states
how to check for a Validly Signed DKIM2 Message, moving
consideration of what that means into its own section.
this comes partly from the Authentic From discussion. People
seemed to want MUSTs etc for signers but Verifiers feed straight
into local policy, so you will now find that a Verifier just
tells you if a message is a "Validly Signed DKIM2 Message" or
not, there are no SHOULD reject statements or similar.
There are some retrictions on Signers as to what they can do
with something that is not a "Validly Signed DKIM2 Message" but
all the MUSTs and SHOULDs in the Verifier spec are solely about
consistency of reporting flaws in the message.
* Substantial rework of the description of DKIM Replay.
this is now separated from Verification
* An EAI section has been added.
* A security considerations section has been added.
please provide text if you want more here
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBatV4mGHfC/FfW545EQJTAQCfbuzJpDWvw5+z2A4hVEtlNH0gr8YAn07P
nraVtq7kcCveZAY2yiHOElkG
=M7xq
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
