Need to be able to specify both RSA and Ed25519 keys/selectors in opendkim

[kitterma]

It looks like the libopendkim.c changes in Beta0 only use a single parameter for the key file/selector. In order to produce a double rsa-sha256/ed25519-sha256 signed message (which is operationally what we'll need for quite some time), I believe that would mean passing a message through the library twice for signing. This seems inefficient.

Regardless of the library implementation, opendkim will need to know both rsa and ed25519 keys for dual signing. This will require some additional paraters for ed25519. I'd suggest something like:

.TP .I KeyFileEd25519 (string) Gives the location of a Ed25519 private key to be used for Ed25519 signing all messages. File is the Base64 encoded output of RFC 8032 Ed25519 private Key generation (as used in dkimpy). Ignored if a .I KeyTableEd25519 is defined.

TP .I SelectorEd25519 (string) Defines the name of the selector to be used when signing messages using Ed25519. See the .B DKIM specification for details. Used only when signing with a single key; see the .I SigningTable parameter below for more information.

This parameter is ignored if a .I KeyTableEd25519 is defined.

[mskucherawy]

I think we need to extend the KeyTable to include a signing algorithm which, if present, overrides the one selected by the SignatureAlgorithm configuration parameter.

Once that's added, you don't need to add a new feature to do this (or shouldn't). If you set "MultipleSignatures", then all matches on the SigningTable will be applied, not just the closest match. Since the SigningTable keys may be unique (depending on the underlying data set), you may need to create a rule for ed25519 that's ".domain", and then for rsa-sha256 use "*".

Another option is to use one of the Lua hooks and invoke odkim.sign() more than once for a single message.

[imyxh]

Just hit this issue on my own setup. Apparently ed25519 is not validated by many large servers (e.g. gmail), and not being able to set two different SignatureAlgorithm makes it so that using both rsa+ed25519 with a KeyTable is useless.

[gene-git]

While this has worked surprisingly well for a moribund project its probably time for a active alternative ?

[thegushi]

I’ve been happy to try and add basic patches to fix problems (as you’ve seen me recently do with opendmarc) — but the openssl codebase is huge and complex, and adding support for a new keytype is more than I’m easily able to do. If you can get me a patch, I’m willing to put it in.

-Dan

On Apr 11, 2022, at 2:57 PM, Gene @.***> wrote:

While this has worked surprisingly well for a moribund project its probably time for a active alternative ?

— Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenDKIM/issues/6#issuecomment-1095608286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWKKEAW5TA7F5SEUT7SGTVESN4JANCNFSM4FAQLMZA. You are receiving this because you are subscribed to this thread.

[gene-git]

I believe the original poster here has since gone on to work on dkimpy tools. Dan I understand your openssl comment - though there is libsodium with good support of ed25519 if that helps? If folks could do something, what would be helpful to you, especially for those not familiar with the opendkim code? Like say a C function with args foo, foo, ... which does blabl and returns blabla or something.

[gene-git]

Now I am confused by above. After further inspection, opendkim already knows how to handle ed25519-sha256 from a crypto standpoint. opendkim-genkey will happily make keys as well. So it seems its more about the opendkim code organization itself and not the crypto side - unless I'm missing something.

[gene-git]

I created ed25519 keys using the opendkim tools - then added a second milter to use it - outgoing mail gets signed by both rsa and ed25519 but the latter is invalid - The opendkim server that received the mail marked the signature bad. To confirm saved the mail and confirmed signature invalid using dkimpy tools - which also says the sig is bad.

I also tried to create a sig using dkimpy's dknewkey - but the private key format is not one that is understood by opendkim. opendkim sandwiches the base64 key between a begin and end private key line - even adding those the dkimpy key was not usable by opendkim.

That's as far as I've got.

[gene-git]

Since this is basically impossible to debug I suppose the next step is to try dkimpy-milter and see how that goes. rspamd is an option too but seems too bloated to me.

[kitterma]

There's no standard format for the private keys (or there wasn't when I started working on dkimpy-milter).

[kitterma]

Relative to the original suggestion, it's my understanding that if you want to sign with both RSA and ed25119, you need to run it through opendkim twice. In dkimpy-milter, if you configure both signing methods, then it adds both signatures in one pass. I think this is a better approach because, as a practical matter, anyone doing ed25119 signing will also want to sign RSA.

[gene-git]

Definitely better. Okay will go pull your git master from your repo and work on setting up dkimpy-milter. Probably makes sense for any further discussion if I take it to your launchpad git area?

[ghen2]

I'm also running two milters, one to sign with RSA and verify (it verifies both algorithms) and a second one to sign with Ed25519 (and not verify). This is not ideal but it has been working well for 1,5 years now. However, DMARC reports are showing that almost no verifiers support Ed25519 DKIM signatures today.

I think the single biggest improvement for DKIM Ed25519 signature adoption would be simply to tag an OpenDKIM 2.11 release (not just beta) from the current code, then we'll soon see much wider support on the verifier side.

[gene-git]

interesting your opendkim set up works while mine does not verify. Scott do you know how to convert the opendkim keys (rsa and ed25519) to a format usable by dkimpy-milter? Or should I start from scratch and push dns?

tx

[kitterma]

Definitely better. Okay will go pull your git master from your repo and work on setting up dkimpy-milter. Probably makes sense for any further discussion if I take it to your launchpad git area?

Yes, although I would use the latest release. I think git master is ~fine, but I don't remember for sure. I've lacked time recently to work on it.

[kitterma]

interesting your opendkim set up works while mine does not verify. Scott do you know how to convert the opendkim keys (rsa and ed25519) to a format usable by dkimpy-milter? Or should I start from scratch and push dns?

I don't (since I don't know what opendkim does). For now, I'd just generate a new key and update DNS. Eventually I should probably add support for whatever it is opendkim does.

[gene-git]

yeh no prob on keys - dns propagates quickly these days. Will likely be a couple days but will report back. I do see at bottom of git area another repo where someone added a possible utf-8 (aug 2021) tweak. I see 3 commits in master since 1.2.2 tag. Thanks scott - wish me luck :)

[gene-git]

Closing comment - I have tested dkimpy-milter with ed25519 and it works correctly

[gene-git]

scott - i sent you email - found oddity you may be interested in