-----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]
