----- Original Message ----- From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> From an administrative point of view it is useful to be able to > tell the signer 'hey dude' (that's technical speak) 'hey dude if you > want to verify this signature better get the signature key before > this date.' > > > Signature expiration in seconds-since-1970 format > as an absolute date, not as a time delta from the signing > timestamp. The signature expiration date allows the signer > to notify verifiers that distribution of the signing key > MAY cease once the expiration date has passed. Ok. In short, you are saying don't bother trying to do a Verification because the odds are good it is will fail, and it does fail, this would be one reason. Question: Why limit the signer ability to have DKIM system that keeps the same selector, creates different x= values depending on message type or value? I see that is a pretty powerful option. If we remove x=, we are left with removing selector. The result is a guarantee that it will fail based on a NXDOMAIN error. So it is correct to say: Signatures with selectors resulting in NXDOMAIN DNS querys SHOULD NOT be considered valid? I prefer to see a more direct "signal" from the signer that says this signature is no longer valid. Are we willing to say NXDOMAIN is sufficient for this? How about this in section 5.2: | 5.2 Select a private-key and corresponding selector information | | .. | A signer SHOULD NOT sign with a key that is expected to expire within | seven days; that is, when rotating to a new key, signing should | immediately commence with the new key and the old key SHOULD be | retained for at least seven days before being removed from the key | server. That basically means that x= must be used if there is planned event for selector removal within 7 days. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
