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