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. |>|>Until now that simply was the complete ED25519 public key, just |>|>like for RSA, instead of extracting the actual "bitstring data" |>|>from the standardized ASN.1 container, which starts at offset 16 |>|>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka |>|>the binary blob). |>|> |>|>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. |>It defines exactly this, no? It says there are no further |>parameters, but it does not say "hey so you can go and just leave |>that niche container off". |>Sure it is 44 bytes, but the entire thing is 64. |>It is de-facto only the single example in A.2 which reveals the |>total ignorance of ASN.1, and it is about brisbane and football, |>which i cannot glue together (letting aside it is written by an |>american, and who knows what kind of "football" that is?, as |>i seem to know they say "soccer" for what i would think, but it is |>4am so i do not truly think anyhow. Saturday night all right for |>fighting, ah.) (OpenSSL in mid 2017, at least a bit.) |>Thus: smart, very smart. Is always too smart for some. |>Just leave them behind. | |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 since February 2023, and 8032 since 31st of January this year, coming from a completely different background, having read 5480 (Elliptic Curve Cryptography Subject Public Key Information) and more in the past, and am a CMS and x.509 "fanatic". 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! --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
