Hi all, Looking at the current direction of DKIM2 and JSON structures, I have to ask: Are we quietly trying to invent JNS (JSON Name Service) next?
Unless, of course, someone suggests using YAML instead... though given its parsing quirks, I think I would prefer suing YAML! Personally, I still prefer IMAP5. And let's be honest, nobody would ever dare to write an SMTP2 draft as long as JCK is active and we all know his motto is rather "less is less", and I follow the same strategy. Making a mistake in early drafts by introducing JSON might be human, but persisting with complex, structured formats in the message transport layer despite the clear performance costs is diabolical. A clean and lean API is worth so much more. To keep DKIM2 secure against parsing overhead and DNS-over-TCP fallbacks, we should strictly enforce flat, native tag-value representations instead of JSON/YAML structures. Specifically, we need a dedicated field for Key Validity: - We need a separate tag to signal when a key itself expires, independent of the signature's expiration (x=). - To avoid the Year-2038-problem on legacy 32-bit hardware, we also should think about setting the datatype of the signature expiration and the key expiration field to uint64_t. Best regards, Timo -- 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]
