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
