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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html