At 5:27 PM -0700 4/6/06, Michael Thomas wrote:
DKIM is intended to have a transport duration lifetime, eg about
2 weeks.
Yep.
It is not intended to be used for archival purposes or
anything else like that.
Yep.
So what is the value to giving the signer a tool that can change
either of those statements? We should, instead say those two things
in the definition of DKIM, if the WG agrees that these two statements.
Like it or not, rolling keys is hard for
a significant set of people who might benefit from DKIM. Saying
that the only way that they can limit their exposure from otherwise
immortal signatures is by revisiting their DNS every few weeks is
unnecesarily burdensome on those operators.
Fully agree.
x= is a cheap way to
achieve that goal.
Simply specifying the length of a signature's life in the document
that defines the signature is much cheaper, and less prone to
misinterpretation.
Note that the informative note only says what x= is not. Leaving x=
in can also lead to silly states.
What states might those be?
For example:
The signer has measured the transit time to location A, and it is
always less than ten seconds. The signing system sets x= to a day to
be safe. Location A's SMTP server, becomes unavailable due to a
backhoe incident. The outgoing mail sits on the signer's system for a
day and a half before connectivity to A is restored. The message
arrives with an non-verifiable signature, even though the signer made
a reasonable assumption when signing.
If what the WG wants is signatures whose life is the time of transit,
we should say that in the protocol definition, not optionally in each
message.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html