Stephen Farrell wrote:
Folks,
We've decided to stick with the status quo and keep
x= but we do seem to need some different text.
Barry and I would like finalising that text to be the
topic for tomorrow's jabber session. Maybe a bit
ambitious but we do need to kill the topic.
So to make that a bit easier, here's my suggestion
based on what I've seen on the list. Feel free to
beat it up, but we (as chairs) are going to have to
declare for some text after tomorrow. So beating
this up by proposing a better alternative is really
much more likely to be effective.
And during the jabber session, please try to
remind yourself that perfection is in this case
almost certainly the enemy of the good.
Stephen.
------------------------------------------------------------------------
Current:
x= Signature Expiration (plain-text; RECOMMENDED, default is no
expiration). The format is the same as in the "t=" tag,
represented as an absolute date, not as a time delta from the
signing timestamp. Signatures MUST NOT be considered valid if
the current time at the verifier is past the expiration date.
The value is expressed as an unsigned integer in decimal ASCII,
with the same constraints on the value in the "t=" tag. The value
of the "x=" tag MUST be greater than the value of the "t=" tag if
both are present.
INFORMATIVE NOTE: The x= tag is not intended as an anti-
replay defense.
Proposed:
x= Signature Expiration/Best-Before (plain-text, OPTIONAL, default is
no expiration/best-before). The format is the same as the "t=" tag,
represented as an absolute date, not as a time delta from the
signing timestamp. Verifiers who support x= MUST conside a
signatuure invalid if the current time at the verifier is past
the expiration date. If a signature is invalid for this reason,
then the normal rules apply, so the signature SHOULD be treated
the same as if cryptographic checking had failed or as if the
public key could not be retrieved. Verifiers MUST NOT asssume
that there is any particular relationship between the x= value
and the life cycle of a public key.
Signers MAY include an x= value at their discretion.
Verifiers SHOULD support checking of x= values.
The value is expressed as an unsigned integer in decimal ASCII,
with the same constraints on the value in the "t=" tag. The value
of the "x=" tag MUST be greater than the value of the "t=" tag if
both are present.
Hi Stephen,
Thanks for the text. Modulo MUST/SHOULD/MAY concerns I would be okay
with your strawman. I think MUST MUST be reserved for substantial
security problems or interoperability problems, and here I see neither.
And so where you list MUST I would label them SHOULD. Because we really
don't have a firm grasp on the usefulness of this function, I believe
verifiers MAY support checking of x= values. Indeed my own perspective
is that support of x= is counter-productive because the information
contained therein should be in the DNS and not in the message. After
all, if someone cracks the key, then x= won't really help, so the only
thing we *may* be doing is reducing the number of queries, and as DNS is
read optomized, I don't really care about that a whole lot.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html