While I like the utility of the JSON (RFC8259) + Base64 (RFC4648), I'm worried that it introduces an extra layer of opacity for the tag-value parameters of the DKIM2-Signature and will require special tooling to read DKIM2 signatures. In particular I would like to easily see the domain relationship between d=, mf= and rt= DKIM2-Signature. Body recipes and even header recipes are unlikely to make sense to people anyways, so encoding those in JSON+BASE64 in the Message-Instance is probably reasonable. Assuming a plaintext DKIM2-Signature tag-value, can we describe the mf= and rt= addresses using the RFC5322 address-list ABNF? If that's too complex, use the JSON idea: surround the address by a double quotes and then separate by commas? If that doesn't work, what about a new address header field based on RFC5322 Cc so it could use the same address-list ABNF but it would include a "i=" instance number .
My second concern is while the above JSON and BASE64 is normatively defined, the draft uses JSON Schema which as far as I can tell hasn't been IETF or W3C specified. Can that be found and normatively referenced in the draft? -Wei On Wed, Feb 18, 2026 at 12:39 PM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have submitted a revision to the DKIM2 specification document > > https://datatracker.ietf.org/doc/draft-clayton-dkim2-spec/ > > This new version places the recipes, the SMTP parameters and the crypto > into JSON objects which are then base64 encoded and put into the > Message-Instance and DKIM2-Signature fields. This was originally > Tobias's idea and it has worked out well (if a little slowly). > > Other values have been left as tag=value so that human readers of email > headers (who are not all that common of course) can get an idea of what > is going on. People who feed messages into tools that then present the > information in the header fields in a human-friendly way will not of > course care one way or the other! Anyway, it's obviously possible to > move more values in or out of the JSON. > > The recipes are complex and JSON is much more straightforward for > systems to parse. They are a separate object so that you can easily see > they are there (and get a feel for how complicated they might be). > > Putting the crypto (hashes and signatures) into the JSON means that the > bodge of a1= a2= etc disappears and I have removed the restriction on > just two hash/signature algorithms. We might want to set an upper bound > mind you. > > Putting the SMTP parameters into JSON does not help the human readers of > headers (albeit they are no worse off than with DKIM1 since this is a > new feature of DKIM2). However, if we don't do that then as Hannah so > helpfully pointed out you need a fully-fledged RFC5321 parser in order > not to misinterpret the superficially easy to parse tag=value format. > > I also removed the restriction on no recipes on the v=1 Message- > Instance. It is argued that being able to recreate the message as it was > before it entered the DKIM2 world would be useful ... one could see if > was an OK DKIM1 message for example, and this might make it easier for > people to handle messages from mailing lists which were DKIM2 enabled > but not all the messages submitted to them were DKIM2 messages. > > I have not yet had time to take up Dave Crocker's excellent suggestion > to have a section not just on Signers and Verifiers but also on what > Forwarders should be doing. I also aim to reorganise the sections a bit > (to put the algorithms for creating hashes alongside the description of > the JSON blobs to hold the results). This might reduce some of the > repetition that remains in the document. > > BTW: the four JSON schemas are valid JSON -- but that does not mean that > they are correct :-) ... and I will be sorting out the dangling URLs > very shortly. > > - -- > 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/AwUBaZYi8mHfC/FfW545EQIxngCdHhTqCtskg2PDzjlWb/YtGQOVwx8Ani4I > wfNzEt6bMxzj6xesnYDY4wqb > =0G+q > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
