Hi Mauro, This is not about performance or avoiding JSON; it is about strictly limiting object depth to prevent structural parsing differentials at trust boundaries.
I personally do not have a problem with JSON, but we strictly
have to limit object depth.
BTW: This concept completely contradicts the principles of
RFC 5322.
Standard JSON specifications lack strict object-key ordering and
duplicate key handling. Introducing nested object complexity into
the transport layer creates serialization risks that flat, native
tag-value structures inherently avoid—which is why DKIM1 worked
without JSON for 15 years.
Best,
Timo
It looks like Mauro De Gennaro aimed to say:
> Hi Timo,
>
> What format would you propose instead of JSON? If your concern is
> performance, modern JSON parsers using SIMD instructions can parse a complex
> DKIM2 recipe in nanoseconds, so I doubt the format itself would be a
> bottleneck. If your concern is security, wouldn't writing and maintaining a
> parser for a custom serialization format introduce more security risk than
> relying on a battle tested, widely audited JSON parsing library?
>
> Regarding the key validity field, you raised concerns about key rotation.
> Could you clarify why a rotated key no longer being present in the DNS
> records isn't sufficient on its own? If the field's purpose is logging, does
> that justify the added complexity of bloating the DKIM2 signature with an
> extra field?
>
>
> Best,
> Mauro
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]
