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