On Thu, Jul 10, 2025 at 1:42 PM Allen Robinson <arobins= [email protected]> wrote:
> Assuming there ends up being support for multiple signatures within a > single header field to support algorithm dexterity, a less DNS-impacting > option could be to have multiple selector+signature pairs within the field. > This would allow us to keep the single key per record structure of DKIM. > > Something like this: > > DKIM2-Signature: i=1; d=google.com; s=rsakeysel; bh=RSA_SIG; > s2=ed25519keysel; bh2=ED25519_SIG > With this approach, will there be a fixed number of alternative keys per signature? For example if there are only two allowed, could we then only have to specify statically "s" and "s2" and similarly "bh" and "bh2"? -Wei > On Thu, Jul 10, 2025 at 2:19 PM Wei Chuang <weihaw= > [email protected]> wrote: > >> >> >> On Thu, Jul 10, 2025 at 10:52 AM John Levine <[email protected]> wrote: >> >>> It appears that Wei Chuang <[email protected]> said: >>> >-=-=-=-=-=- >>> > >>> >Hi all, >>> >I'm announcing the Internet-Draft for the "Domain Name specification for >>> >DKIM2". >>> >https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/02/ >>> > >>> >DKIM2 intends to be compatible with the existing DKIM installed base of >>> >keys hence this part of the specification is essentially the same as >>> >RFC6376 with an update for more modern algorithms. ... >>> >>> It mostly looks fine but I have a few questions. >>> >>> It currently only lists k=rsa for RSA signatures. If we're only going to >>> have one signature scheme, it should be k=ed25519 since those signatures >>> are >>> smaller and faster to compute and verify. >>> >> >> That's an oversight on my part. I can add that in when the upload >> service is open again. >> >> >>> When we added a new crypto algorithm we realized that you can only have >>> one >>> key per selector.I gather the plan is to allow multiple signatures >>> in the same dkim2-signature header so the key records will need to allow >>> that. >>> >>> One possibility would be to relax the rule about one key TXT record per >>> selector >>> to allow multiple records but the k= values have to be different, e.g. >>> k=ed25519 >>> in one and k=postquantum in the other. Another possibility would be to >>> keep it >>> one record, but make the k= h= p= be comma separated lists rather than >>> single >>> values. >>> >> >> IMO either of these approaches could be sensible. Happy to document once >> a particular direction is settled upon especially wrt to how the signature >> will be specified. My guess is that the comma separated will be a little >> bit more straight forward to specify. >> -Wei >> >> >>> >>> R's, >>> John >>> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
