> On 16 May 2024, at 10:02 AM, Hector Santos
> <hsantos=40isdg....@dmarc.ietf.org> wrote:
>
> 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, you're conflating completely different constructs, because SHA256 is NOT a
signature, it is a message digest.
All actual signatures schemes ultimately operate on short-enough octet strings,
with the key consideration being
whether those "short-enough" strings are generated via an internal digest
operation, or prepared by the caller.
> No one will support exclusively Ed25519 unless dealing with highly direct 1
> to 1 comm I/O with a permission-based system.
A verifier will support at least RSA with SHA2-256, and perhaps also Pure EdDSA
(Ed25519) also with SHA2-256, in the latter
case, the digest is computed by the caller, in the former, it will an internal
step in the RSA signature.
> 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.
Nothing of the sort, the computational costs are trivial, there is some
additional code required for Ed25519 support, because
instead of using a single Digest+Sign primitive in, e.g., OpenSSL, the caller
needs to first compute a message digest, and
then pass it to Ed25519 for signing. This is OK. One might argue that this
should have been either pure Ed25519 over the raw
data (contrary to the text of the base DKIM RFC, but aligned with how it
ultimately handles RSA), or, else Ed25519ph which is
explicitly design for hashed input (but APIs for which are not yet mature in
OpenSSL).
Nevertheless, the specification is clear enough, and a slightly different code
path for the new signature scheme is fine.
--
Viktor.
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
