Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

[Steffen Nurpmeso <[e-mail]>]

Scott Kitterman wrote in
 <[e-mail]>:
 |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso <[e-mail]> \
 |wrote:
 |>Scott Kitterman wrote in
 |> <[e-mail]>:
 |>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso <[e-mail]> \
 |>|>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)