> > |Because that's not actually accurate, due to the inclusion of the digest > |OID in the signature payload in the "single" primitive. > > ...but the above says "two hashes". But despite that. > An Ed25519 sign operation alone creates three SHA-512 digests > which are incorporated into several further calculations. Whereas > for RSA it is, to the best of my knowledge, crucial to let it pass > over as few bytes as possible (for encryption as such i think > OpenSSL will refuse to do so after a certain limit), for EC with > its embedded digests it may be more expensive but even beneficial > to push more data rounds onto the embedded digests. > So maybe, and in hindsight to the RFC that i would try to publish > in fall if i am allowed to and if the email giants still have not > moved towards this RFC 8463, it might make sense to adjust the > data-hash in that it may come from hash-alg or be included via > sig-alg. > > --steffen
I don’t wish to oversimplify here, but I wonder if the confusion is with the idea that in order to support RFC8463, a complaint implementation would have to sign two DKIM signatures for backward compatibility. One DKIM signature using SHA256 and a second signature using Ed25519. No one will support exclusively Ed25519 unless dealing with highly direct 1 to 1 comm I/O with a permission-based system. In other words, supporting this crypto enhancement requires a high overhead of two signatures, The ignorant RFC8463 system (the majority) is not ready for this. One SHA256 signature is sufficient, I would not Ed25519 provides smaller keys that are more supportive by DNS Zone Managers. All the best, Hector Santos _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
