You haven't said anything new here. The key point of disagreement is that you come down on the JSON is too complex side of a tradeoff:
A) encoding the entire allowable space of email addresses in a key-value format would require escapes in any key-value format. B) JSON is more complex, but already has clearly defined escapes, and base64+json allows us structure without having to invent a new format. The authors of the existing DKIM2 spec believe that the benefits of a pre-existing structure in JSON outweight the risks. You disagree. At some point we may need a consensus call from the chairs on this technical choice if we can't get an agreement. The hyperbole you've used below doesn't persuade me, I still favour JSON, I think it will create more consistent implementations than a custom escaping - and make no mistake, safely round tripping arbitrary email addresses will require a custom escaping, but it will be so rare that bugs will exist in the weird edge cases which JSON already deals with. Bron. On Sat, Sep 5, 2026, at 20:32, Timo Gerke wrote: > Hi John, hi all, > > And 15 years of experience also tells us that no JSON MIME > Headers are required to run global, highly resilient inbound mail > operations. > > We should consider following the extended KISS-principle here: > keep it simple, straightforward and short also in protocol > design, shouldn't we? > > You make an excellent point regarding operational pragmatism and > easing the transition. If our primary goal is indeed to keep > DKIM2 deployment safe and closely aligned with the proven, > installed base, then we should apply that exact same logic to the > serialization format on the wire. > > Leaving the JSON structure completely open and unguided directly > inside the RFC 5322 MIME headers seems to contradict that > transition safety. Without strict boundaries, it forces edge > infrastructure to run complex object parsers on untrusted > payloads before filtering, opening up unwanted vectors for parser > differentials and recursion. > > If we follow your pragmatic route - which I completely support > —we should ensure the draft remains structurally resilient before > WGLC. Enforcing a strictly flat tag-value representation or a > hard nesting limit (like d=1 or d=2) within the specification > would immediately solve the parsing risks while keeping the > transition as smooth as possible. > > Regards, > > Timo > > > -------- Original Message -------- > Subject: [Ietf-dkim] Re: Proposal key validity field vor DKIM2 > Date: Saturday, September 5, 2026 at 02:24 UTC > From: John Levine <[email protected]> > To: [email protected] > Cc: [email protected] > > It appears that Timo Gerke <[email protected]> said: > >> Because a signature lifetime (x=) and a cryptographic key > >> validity period serve two fundamentally different operational > >> purposes: > DKIM1 signatures have an expiration time, but DKIM keys do not. > We have over 15 > years of experience that tells us that this works fine. > > Keeping in mind that we are making DKIM2 keys the same as DKIM1 > keys to ease the > transition, you'll need considerably more than "something bad > might happen" to > make an incompatible change. > > R's, > John > > PS: > > >> Separating them allows high-security environments (CRITIS) to > >> strictly enforce automated key rotation cycles at the DNS layer, > I rotate my keys every month and have done so for years. Once again, > there is nothing to fix here. > > -- > 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 > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > *Attachments:* > • OpenPGP_0x9F03DF9F597BF31E.asc > • OpenPGP_signature.asc -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
