----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
My fault handling process for 'key not found' is going to be
different if x= has expired.
Why isn't it possible for signers to use the same selector, but set
different expiration timestamps depending on the value of the message they
wish to sent?
It has the same effect. The different is the the key is still technical
valid because it hashes correctly with the message signature.
This is why we "might" want to consider two cases:
Expired Valid Signature
Expired Bad Signature
Is this not consistent with how Browsers work today with SSL certificates?
Both sets of information is convey here.
But if you security person are saying this expiration should mean the
signature should no loner be viewed as valid even it is technically valid,
then that fine by me too. We just need to make sure that it is consistent
for both dynamic transport level verifiers and post transpost delayed
verifiers. For the post/delayed verifier, I think it needs to emulated the
dynamic verifier as must as possible.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html