I mean ok, non-issue. Scott Kitterman wrote in <717c7103-311a-4c60-a3bf-72ea41cbc...@kitterman.com>: |On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso <stef...@sdaoden.eu> \ |wrote: |>Scott Kitterman wrote in |> <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>: |>|On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso <stef...@sdaoden.eu> \ |>|wrote: |>|>Scott Kitterman wrote in |>|> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>: |>|>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso <stef...@sdaoden.eu\ |>|>|> \ |>|>|>Thanks to Hanno Böck (known from ossec and more) i was pointed to |>|>|>my falsely published ED25519 DKIM key. ... |>|>|>I realize that RFC 8463 says repeatedly that the base64-encoded |>|>|>representation of an ED25519 key is 44 bytes, and that the |>|>|>examples go for this. Still there is no wording that the entire |>|>|>ASN.1 structure shall be thrown away. |>|>| |>|>|At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \ |>|>|specified yet. Openssl didn't support ED25119 either. I'm not sure \ |>|>|what you think we should have put in that we didn't. |>|>| |>|>|It seems to me that you are saying that the RFC is correct and clear, \ |>|>|but that you were certain you knew better than the RFC. That's not \ |>|>|a thing an RFC can fix. |>|> |>|>There *is* RFC 8410 to which 8463 refers, around the same time. ... |>|I don't see it? Where is the reference to 8410? |> |>Yes you are right. 8463 only refers to 8032, and does not mention |>8410 at all. This is a complete misunderstanding. I have 8410 .. |>I think now that i understand that 8463 just "invents its own |>protocol" instead of embedding itself into the CMS / X509 / PKI |>infrastructure i no longer like it at all. What a mess. It is |>Wireguard VPN / SSH etc raw algorithm logic! | |Since nothing else existed at the time we did the work, I'm not sure \ |what else we could have done instead. B64 of the public key isn't \ |that hard to do. Honestly, it was much easier to deal with implementing \ |it than RSA shoved into ASN.1.
But please allow me some doubts as there are widely available and audited cryptographic libraries around that offer interfaces to deal with these issues. |Ultimately, DKIM stuff is for DKIM and I don't think it's a huge problem \ |if it's slightly different than other things. In dkimpy I included \ |tools to generate keys correctly. I think that as long as library \ |providers do that, this is a non-issue. It is an intransparent binary blob of random data. And it remains so when decoded. Who wants that in the DNS. To trumple upon you all and this non-issue even further as it is Monday, these are my DKIM records v=DKIM1; k=ed25519; p=NhvcV4tLaGvK4sSxWEWzjfpntCeyj7s4smQ+JM1LE0Y= v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAniKuBSPAv5QtXEv08pP5uKWMIP3QvmSq3P2Ick/wMTnRv3xqCQPtXu7ick/qt05df/RNLlSIUVL0szhAq8Ua2QporQ53xs8llprY7y0ZpZpUrhUsvwa1GCF2o2DFnD9mWDq5wepxvDRLKpfJu6faz0eFNRL8fyR3ER7EqegrA6+dl6vX+eZLCp/qlhnMhlh/zio8irdCap9W28g+m5Wpqn2p3qhXjqdWKpQUwSu194O+lF19cdLLXpx2L+pW4r8TM/xi2dzNC0/3KEm+zWqhWZZV2T8oRk3mjoMfpMr1v2Yo2RIk7Q6akFna/Bqkt+zJvbu/Yso15x+JTQw6MPvSCwIDAQAB Everyone who knows can apply openssl base64 -d | openssl asn1parse -inform DER and will get somehow "useful" results for that latter, but nothing but an error for the former. The same person who wrote 8032 wrote 8410 and that in turn was IETF-published earlier than 8463. There is also RFC 7250 "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" from 2014, and many more ASN.1 / X509 / CMS etc infrastructural emissions from the IETF for which i am not an expert, but anyhow in all this context a binary blob of intransparent data is an "illegal alien". How about a RFC for asn1ed25519-sha256 DKIM keys which simply includes the 16 base64-encoded ASN.1 structure bytes? Or asn1ed25519-blake2 (RFC 7693), which is now also widely available (and if only for that RFC 9106 Argon2 monster)? Maybe this will help the switch away from RSA? It is otherwise not understandable in this world of hysteric encryption-scheme reduction (ie in TLS land just two or three years ago i was shouted at on nmh-workers at nongnu dot org by a well known US army (navy i think) security guy well-known for his Kerberos/GSSAPI prospect once i said something about TLSv1.1, and as of today in practice i only see TLSv1.3, and the developer of the HTTP server software i use reduced to forward-secrecy-plus ("CipherString" => "EECDH+AESGCM:CHACHA20:!PSK:!DHE") # default which is not much but at least has some TLSv1.2 left: # openssl ciphers -v EECDH+AESGCM:CHACHA20:!PSK:!DHE). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim