Sorry, I realised there were a few instances in my description that
incorrectly referred to the DKIM key and not the signature. Corrections
below to avoid any potential misunderstanding.
On 6/09/2025 6:10 pm, Inveigle.net wrote:
Deprecating RSA has non-technical barriers. For service providers
operating at scale, it is difficult (verging on impossible) to
convince every customer to publish new public keys. This is the
primary motivation for supporting RSA in DKIM2 at all.
This is actually one of the issues I am attempting to resolve through
the addition of the trusted signer concept. DKIM is limited by only
permitting a single record under each selector name, and altering that
would break existing verifiers that expect a single DNS answer record.
It's something that is easy to fix in code, but it would be a breaking
change, which I'm trying to avoid. A graceful switch to Ed25519 at
present would therefore require four CNAME records, allowing for
reliable rotation of two key types. A hard switch over to Ed25519
would be possible using two CNAME records, but it would be dependent
on verifiers supporting the new keys first.
Getting users to add records may be difficult, but if we introduce a
trusted signer concept, we can break the dependency on a single pair
of selectors and deploy DKIM2 sans RSA from the outset.
An ESP would do the following...
1. Sign the e-mail using DKIM v1 with one of the current domain keys.
2. Create a new authorisation header, authorising their own server to
sign on behalf of the domain, signed using the same key in step 1.
3. Sign the e-mail again using DKIM2 [*authorised domain*], ensuring
all DKIM2 mandated headers are used, with Ed25519 etc.
The authorisation header would look something like this...
DKIM-Authorized-Signer: d=provider.com; k=ed25519;
s=B9VoiuIq9M6WU6KrK72oBLGV9vkIXl30NwrCnswlpxI=; ...
Because this is a header and not constrained like RCPT TO, we can
easily use any existing RSA key *to sign* this authorisation header as
well.
A DKIM v1 verifier would be able to use the original DKIM-Signature to
check e-mail integrity. As the ESP controlled the process, this would
always pass if the message is not subsequently changed, preserving
DKIM v1 integrity. A DKIM2 verifier could also check the inserted
DKIM2 *signature* and signing authority, and I expect the spec would
contain a SHOULD or even MUST in that instance to ensure DKIM2
verification is promoted ahead of the earlier version, especially if a
more appropriate minimum set of headers is mandated.
Where the ESP doesn't have direct control over keys, the steps would
essentially be the same, with the exception that step 1 could also
include a DKIM2 *signature* from the outset, step 2 would be optional
if no changes were permitted (the use case not currently well catered
to), and step 3 would only be necessary if a DKIM2 *signature* was not
provided during step 1 or the e-mail was altered, but given it's
innocuous and keeps mail flow consistent, this step should probably
always be done and may ever be mandated for change tracking.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
