What he said :-) Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED]
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Thursday, April 20, 2006 2:07 AM To: Stephen Farrell Cc: ietf-dkim Subject: Re: [ietf-dkim] Attempted text for x= ----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> >>> Verifiers SHOULD support checking of x= values. >> >> I think this must be a MUST. > > REQUIRING that the verifer honour the sender's wishes is > tricky in general and a MUST there is getting close to that, > as you say. Agreed. If we change it to relaxed wording like so: Verifiers MAY support checking of x= values. If verifiers supports checking the expiration x= tag, they SHOULD honor the signature expiration. Then basically, this effectively defines for implementations, the x= tag is worthless and that if the domains wants to truly expire a signature they need to either: a) revoke the public key by setting p=data to empty, or b) purge the publc key DNS record from DNS. In this case, x=tag becomes an *optional* optimization or non-DNS based fast rejection feature or concept. The wording might be: DKIM offers an key expiration optimization option using an x=expiration date tag in DKIM signatures. Verifiers MAY use this tag to accelerate the classification of a signature to an invalid state. Signers MAY set this x= value, however, signers MUST be aware that verifiers may not support this option and the only effective way to expire a signature or revoke a public key is to clear the public key or remove the selector DNS record. That is all that basically needs to be said from my point of view as an implementator. Signers now will basically view x as the day the key data is cleared or the DNS record is removed, and decide for themselves if they want to assist the verifier world with the x=tag optimizer. Lets keep in mind, tag or not tag, you still have step 2 in section 6.2 and the 451 recommendation is not something verifiers will just willing honor across the board. That is definitely a candidate for local policy setting to 551. In short, the coding for the verifier might be: NXDOMAIN, no tag, not expired ---> 451 NXDOMAIN, signature expired ---> 551 -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
