Dear Pete. Hi all. 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.
Regarding internal representation and y2k38: This is not about internal code; it is about strict constraints on the wire format. If a protocol aims to secure critical infrastructure running legacy 32-bit hardware, leaving timestamp boundaries "out of scope" is a known operational risk that flat, native types can easily avoid. Finally, defining Rough Consensus while bypassing the reality of broken Running Code at the edge nodes degrades a core IETF principle into theoretical debate. If the code breaks at the boundaries, there is no running protocol. Operators in the real world require deterministic security, not administrative consensus. You are confusing me. As editor of RFC 5322 you should be the last one who supports complex JSON objects in mail headers. BTW: Bron already confirmed that this design would possibly not work on Inbound Edge Gateways. Regards, Timo It looks like Pete Resnick aimed to say: > peaking as chair: > > On 10 Sep 2026, at 13:27, Timo Gerke wrote: > >> The core issue lies within the message transport layer (the email >> headers). Introducing nested JSON structures for recipes creates >> significant validation risks at the Milter level. >> >> Even with stable parsers, you cannot eliminate Parsing >> Differentials. If two compliant parsers (e.g., Milter vs. >> downstream MTA) interpret a nested JSON object differently - like >> key ordering or duplicate keys—the cryptographic canonization >> breaks completely. This is a classic Insecure Design vector. > As Hannah said in a later email, this does sound like a reason to make a > point in the Security Considerations section, but I'm not seeing a lot > of justification for your position to abandon JSON because of this. > >> Regarding y2k38 and expiration: Leaving representation "out of >> scope" is a risk for critical infrastructure running legacy >> 32-bit hardware. Relying on transient DNS deletion also ignores >> long-term immutable archiving, where historic signatures must >> remain deterministically verifiable independent of active DNS >> states. > Again, this seems like perhaps an issue for security considerations, but > specifying internal data representation is never part of protocol > specifications in my experience. > >> Since Bron already admitted the current "gummiband" design >> breaks at the edge nodes, there is no functional Running Code >> here. And without running code, there is no Rough Consensus for >> spec-06. > Running code is not a requirement for rough consensus. And determination > of rough consensus will be done by the chairs. > > pr Timo Gerke Hamburg, Germany "If you think technology can solve your security problems then you don't understand the problems and you don't understand the technology." -- Bruce Schneier
OpenPGP_0x9F03DF9F597BF31E.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
