Subject: [ietf-dkim] RFC 4871: Signature Expiration

From: Florian Sager <[email-masked]>
Date: Fri, 11 Jan 2008 20:55:48 +0100

I wonder why the signature expiration date (x-param) was included in the 
signature itself.
If there was an optional expiration date contained in the _domainkey DNS 
entry besides the public key instead, a mail admin could react in the 
short-term to e.g. abuse of the according private key without 
interfering the validation of signatures before this expiration date.

Florian

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 11 Jan 2008 20:08:02 -0000

>interfering the validation of signatures before this expiration date.

If I were a bad guy, why wouldn't I simply forge a date in my spam
before the expiration date?

R's,
John

---

From: Florian Sager <[email-masked]>
Date: Sat, 12 Jan 2008 10:20:06 +0100

> before the expiration date?
John, I would agree if the expiration date (x-param) was compared to the 
signature timestamp (t-param).
But the RFC says (see x-param):

      Signatures MAY be considered
      invalid if the verification time at the verifier is past the
      expiration date.  The verification time should be the time that
      the message was first received at the administrative domain of
      the verifier if that time is reliably available; otherwise the
      current time should be used.

Regards,
Flo

---

From: Florian Sager <[email-masked]>
Date: Mon, 14 Jan 2008 11:08:09 +0100

John L schrieb:
>>>> If there was an optional expiration date contained in the 
>>>> _domainkey DNS entry besides the public key instead, a mail admin 
>>>> could react in the short-term to e.g. abuse of the according 
>>>> private key without interfering the validation of signatures before 
>>>> this expiration date.
> As best I understand it, your suggestion above seems to be saying that 
> an admin expects his signature to be compromised at some future time, 
> so he tells people to stop believing the signature at that future 
> time. Certainly, if the key has already been compromised, he should 
> just cancel the key.

I was thinking about a key revokation in the retrospective: an admin 
recognizes misuse beginning at time t in the past, so he can set x=t. I 
am aware the recommendation to validate DKIM signatures shortly after 
mail reception. But I could imagine some extraordinary situations where 
the validation has to be suspended. Although this change (expiration 
date combined with public key in the DNS) would have little impact in 
practice, it seems to me it creates a more stable system.

FMI: is there somewhere a recommendation for the TTLs of 
<selector>._domainkey and _ssp._domainkey (what is considered as the 
optimum between signer friendly, short TTLs and verifier friendly, long 
TTLs) ?

Best regards,
Florian