----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
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