I suggested something similar recently, whereby a sender can explicitly
declare the next host can sign on their behalf as a means to ease
transition from RSA to Ed25519. A user signing their own e-mail would be
able to make this declaration while those using an ESP that currently
signs on their behalf, would have the ESP sign twice, once with the
authorising key (the current DKIM key) and again with their own key.
That said, I don't think pp= is the way to do it as the argument against
adding Ed25519 as a requirement is that it's too hard to get ESP
customers to add a second set of CNAMEs to DNS. While I don't consider
that to be an unreasonable requirement, adding a _pp is no less onerous.
I have requested time in the agenda to discuss an alternate approach to
rt, dd/nd which can eliminate additional DNS queries or record creation
and which could easily be extended with an additional flag granting
upstream editing permission (a feature I would really like to see).
Regards,
R. Latimer
On 4/11/2025 4:28 am, Wei Chuang wrote:
While I understand the desire to keep DKIM2 simpler, pp= permits
delegation to an email hosting provider as already pointed out above.
One consideration I didn't think of till now is this pp= delegation
can help with the DKIM2 adoption especially when we consider the
algorithmic agility requirement. DKIM2 at some near point wants to
mandate publishing and signing both with RSA and ED25519. My guess is
that many senders and forwarders will have trouble deploying ED25519,
and one avenue to smooth adoption is allowing them to delegate
publishing and signing to their platform. That said, I noticed that
pp= has been removed in draft-clayton-dkim2-spec-03, so perhaps this
discussion is perhaps moot.
Regarding the mv= tag, can more clarity be provided how that is
different from the i= instance number? Is the idea that a more recent
(higher i= number) DKIM2 signature can reference an older (low mv=)
MailVersion header?
thanks,
-Wei
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
