[ietf-dkim] Attempted text for x=

[Eliot Lear]

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