Hector, Thanks for your note. Please see below.
> By the way, I am curious. I am wondering why is there is a resistance to a > expiration concept? Isn't expiration an inherent attribute in security and > in a crypto key concept? > Yes, it is. However, such expiration is usually associated with a key as part of a certificate for purposes of truncating revocation lists or otherwise limiting the damage that could be caused due to lost or stolen private keys. Under the cryptographic systems I understand a signature will verify as valid so long as the input was signed prior to a key's expiration. Put another way, you normally can validate a signature long after the key used to generate it has expired, so long as the key was valid when the signature was made. The problem here is that we are associating the expiration time with a message that is signed with such a key, and not the key itself. And so the semantics are different. x= says that the verifier should not try to retrieve a key from DNS past a certain date. If the purpose is to simply not have the message validate at all at some period of time, that is fine but that should be documented clearly (and further justified IMHO). Eliot ps: thanks to Landon Noll for providing me some guidance on the nature of cryptographic signatures. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
