Hi Pete, Hi all, have you never had typos in mails?
The core problem with JSON schemas is that they just can't limit tag usage by design, as Richard said. Writing "MUST use the first tag" into the spec does not stop dangerous Parsing Differentials). Standard JSON parsers handle duplicate keys in an undefined manner (RFC 8259). A flattened JSON array forces strict sequential determinism. It ensures that duplicate context tags cannot overwrite each other or create ambiguous parsing paths. Regarding predictable parsing time: Sterile lab setups do not simulate a CRITIS gateway under a DDoS attack. Deeply nested JSON opens the door to algorithmic complexity exploits. An array guarantees linear O(n) parsing time at wire speed. My idea of a flat array reduces the attack surface to the smallest possible level. It provides security by design, rather than security by policy. Regards, Timo It looks like Pete Resnick aimed to say: > On 14 Sep 2026, at 11:34, Timo Gerke wrote: > >> To me it seems that you lost the core of my idea. > Well, that may be true! > >> Richard was indeed talking about duplicate JSON tags (key-value >> pairs). The point is, that if we do not use key-value objects >> and instead transit to a flattened, sequential JSON array, >> there just can't exist any duplicate JSON tags in the data. > Well, that is a different point than you made earlier: You had said > "Since my idea does not save keys in the JSON data..." and "...we should > consider beleving keys in DNS." So it sounds like we are agreed that > crypto keys are not intended to be in JSON and are not part of the > concern. > > But on this new point: I think you have one too many "not" in that > sentence, but if I understand you correctly, you are concerned about > duplicate JSON key values. But as Richard said, the spec can properly > limit that, so I don't see the concern. > >> A flattened array is also able to be parsed in predicable time. > As Hannah and others have pointed out, CPU/time concerns do not seem to > be an issue to those who have already tried implementing some of this. > Unless you have a practical counter-example, I think I must conclude > that this has been reasonably considered by the group. > >> And mathematically it is nearly impossible to generate >> identical SHA-512 hashes from different data anyway. > I'm not sure what concern this is supposed to be about. > > 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]
