Hi Tavi, Because a signature lifetime (x=) and a cryptographic key validity period serve two fundamentally different operational purposes:
- Signature Expiration (x=) is message-specific. It defines how long a specific signature on a specific message should be trusted after transmission (e.g., "this transit proof is valid for 7 days"). - Key Expiration (the proposed e=) is infrastructure-specific. It defines the absolute operational lifecycle of the public key itself (e.g., "this key belongs to a 90-day rotation cycle"). The operational risk: If we force operators to abuse x= to mimic key expiration, a single compromised or misconfigured long-lived public key allows attackers to forge valid historical messages indefinitely. Separating them allows high-security environments (CRITIS) to strictly enforce automated key rotation cycles at the DNS layer, without forcing them to artificially constrain individual signature lifetimes on long-running store-and-forward mail paths. If you don't believe me: Ask ekr or djb? 😉 Best regards, Timo Am 04.09.26 um 14:08 schrieb Taavi Eomäe: -------- Original Message -------- Subject: [Ietf-dkim] Re: Proposal key validity field vor DKIM2 Date: Friday, September 4, 2026 at 12:08 UTC From: Taavi Eomäe <[email protected]> To: [email protected] >> - We need a separate tag to signal when a key itself expires, >> independent of the signature's expiration (x=). Why? _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected] -- 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]
