Hi Timo,
Please answer the below questions individually. Copy and paste them into
your answer if you need to.
On 10 Sep 2026, at 15:59, Timo Gerke wrote:
Shifting Parsing Differentials to the Security Considerations
section is the administrative equivalent of putting a warning
label on a structurally flawed bridge instead of fixing the
engineering. If a design inherently allows two compliant parsers
to interpret the same wire format differently, the cryptographic
canonization is broken by design. This cannot be patched in
prose.
Are you objecting to recipes in general, or are you only objecting to
JSON-encoded recipes?
If the latter, please describe the parsing differential that occurs from
JSON-encoded recipes that would not also occur in any other encoding of
recipes.
If the former, then I don't see enough support for your objection to
consider the rough consensus to be broken.
Regarding internal representation and y2k38: This is not about
internal code; it is about strict constraints on the wire format.
What text do you want to add to what section of what document?
If a protocol aims to secure critical infrastructure...
Do you see DKIM as securing critical infrastructure? Please explain.
...running
legacy 32-bit hardware, leaving timestamp boundaries "out of
scope" is a known operational risk that flat, native types can
easily avoid.
What text do you want to add to what section of what document?
Finally, defining Rough Consensus while bypassing the reality of
broken Running Code at the edge nodes degrades a core IETF
principle into theoretical debate.
This is not a discussion I'm willing to have on this list. I'll write to
you separately about this topic.
You are confusing me. As editor of RFC 5322 you should be the
last one who supports complex JSON objects in mail headers.
As the editor of RFC 5322, I can tell you that the parsing differentials
between 5322 parsers make parsing differentials between JSON parsers
look downright quaint, and let's not even start down the path of MIME
parsing. You're going to have to come up with specific issues that are
of concern, not generalities, if you want to convince others on this
list that there is a problem worth considering. (And my thoughts as
editor of RFC 5322 are independent of my role as chair, which is to
judge the rough consensus on the list.)
BTW: Bron already confirmed that this design would possibly not
work on Inbound Edge Gateways.
I'm not sure what you're referring to. Please cite a specific message. I
know Bron (among others) has said that some of the actions of inbound
edge gateways are not appropriate for recipes, but I have no idea how
that is relevant to the current discussion. Please provide context.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
