The spec should say that implementations must be capable of recognizing the version field and respond appropriately: * An implementation can always infer that ability to verify the signature implies that the sender signed it. If there are cryptographic changes that are necessary for security reasons it is certain that they will fail to verify accidentally. * If the implementation fails to verify a signature that specifies an unsupported version it cannot make any conclusion about the signature other than it is unable to handle it. I think that what we need here is to get the policy paper written right. The policy has to be able to specify what the version(s) used to sign messages are. In other words what we want is a graceful failure mode for legacy systems that are not kept up to date. We don't want to be prevented from introducing v=2.0 by the legacy base. If the legacy base is able to verify the signature then it can accept the email as valid. If the legacy base fails to recognize the version and is unable to process the signatures then it should be treating the email as if it was unsigned. But it should possibly be also giving the sysop a report saying that it needs an upgrade if these are coming from a significant number of sources. It is not really necessary to have a method of signalling a completely incompatible change. Just used DKIM-II: as the header value. I have dug out my policy paper on the subject (attached).
-----Original Message----- From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of william(at)elan.net Sent: Monday, July 18, 2005 3:44 PM To: Jim Fenton Cc: ietf-mailsig(_at_)imc(_dot_)org Subject: Re: DKIM - Version (Note: part2 of the reply) On Wed, 13 Jul 2005, Jim Fenton wrote:4. Version tag From section 3.5 - "Tags on the DKIM-Signature header field along with their type and requirement status are shown below. Valid tags are: v= Version (MUST NOT be included). This tag is reservedfor future useto indicate a possible new, incompatible version of thespecification.It MUST NOT be included in the DKIM-Signature header field." I understand your intent but above is funny to say theleast, plusin light of the fact that in some other part of the spec it says that unknown tags are to be ignored, it would be wrong. What you should probably say is that "v" is reserved tag and if verifying agent confirming to this spec encounters "v" tag it should abort processing and consider it to be incompatible header and abort processing.I thought this was what it is saying, i.e., if the v= tagis presentit is incompatible with the current version of the spec.However personally I think you should specify 1.0 asdefault versionand say that it MAY be added but its not required and that if "v" tag is not present the header field should be processed asif it haddefault "1.0" version tagThe rationale here is to avoid defaults as much aspossible. I don'tsee any functional difference between "no version" and usingversion 1.0 as you havesuggested.I disagree with this system, I think "v=" should be at the very least optional and you should not abort processing if its present. There is also difference between minor and major changes (v=1.0 to v=1.1 as opposed to v=1.0 to v=2.0) and minor is considered valuable addition to any version string to indicate standard document compatibility. There have also been several others who have said that "v" tag should be present, so this issue should be revisited. -- William Leibzon Elan Networks william(_at_)elan(_dot_)net
|<Prev in Thread]||Current Thread||[Next in Thread>|