On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso wrote:
>Scott Kitterman wrote in
> <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>:
> |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso \
> |wrote:
> |>Scott Kitterman wrote in
> |> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>:
> |>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso \
> |>|>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!
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.
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.
Scott K
Scott K
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
