[ietf-dkim] RFC 4871: Signature Expiration

Florian Sager sager at agitos.de
Mon Jan 14 02:08:09 PST 2008


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




More information about the ietf-dkim mailing list