On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso <[email protected]> wrote: >Scott Kitterman wrote in > <[email protected]>: > |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso <[email protected]> \ > |wrote: > |>Hello. > |> > |>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? Scott K _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
