I've posted a https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-dns/02/ to remove LWSP, and fix the digital signature algorithms to match spec -07. Language clarifies the key type names to digital signature algorithm names. -Wei
On Mon, Oct 19, 2026 at 8:52 AM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected]>, Mauro De > Gennaro <[email protected]> writes > > >Two editorial points on how the two drafts fit together, which I ran into > while > >updating mail-auth to draft-ietf-dkim-dkim2-spec-07: > > > >- -07 still cites draft-chuang-dkim2-dns-04 as [DKIMKEYS]. That draft has > been > >replaced by draft-ietf-dkim-dkim2-dns and does not define the new key > type, so > >the reference should point to draft-ietf-dkim-dkim2-dns. > > Yes it should, I'll fix that in -08 > > >- Section 3 of -07 says "Verifiers MUST implement all five algorithms", > while > >Section 3.3 of dns-01 says Signers and Verifiers "SHOULD implement > >ed25519-sha256 and mldsa44-ed25519-sha512". Whatever the final list of > >algorithms is, the two drafts should say the same thing. > > As I noted earlier there are numerous inconsistencies even just in the > spec-07 document alone. We have an interim meeting on Wednesday (and a > mailing list 24x7 !!) and I will issue an -08 to fix those > inconsistencies once I have some guidance which way the WG wishes to > move ... > > ... also, mldsa44 is one of those algorithms where you don't need to > hash (and it is kind of discouraged). That is if we don't use hybrids > then our list could be > > rsa-sha256 key name rsa > rsa-sha512 key name rsa > ed25519-sha256 key name ed25519 > ed25519-sha512 key name ed25519 > mdlsa44 key name mdlsa44 > > and we could drop the sha512 variants if no-one was interested. > > My preference remains to AND signature results and not use hybrids (and > to use mdlsa44 rather than hashmldsa44) [and to change PQ algorithm at > or before AUTH48 if we've gone down the wrong track] > > BTW, the section on MLDSA-44 in spec-07 almost certainly needs updating > to point at the LAMPS document -- which is with the RFC editor so it > will be an RFC RSN. They use the term "composite" rather than "hybrid". > > <https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/> > > Having read this rather more carefully than I did before I find that > they require a little bit more than just gluing keys and outputs > together, but it still does not look like "building your own crypto" to > me and a shim that packages the mechanisms here and then calls your > favourite crypto library looks pretty simple (Bron's Claude will > probably have finished doing that by the time I finish this sentence...) > > - -- > 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/AwUBatY32mHfC/FfW545EQK1PgCeJP41jPI5pl1hVZv6jbK+liXsH4gAnReF > IfsxrM7Me7uARQFTcfmil7Aa > =zlIM > -----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]
