RE: DKIM - Version

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 reserved 
> for future use
> > >   to indicate a possible new, incompatible version of the 
> specification.
> > >   It MUST NOT be included in the DKIM-Signature header field."
> > >
> > >  I understand your intent but above is funny to say the 
> least, plus 
> > > in  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= tag 
> is present 
> > it is
> > incompatible with the current version of the spec.
>
> > >  However personally I think you should specify 1.0 as 
> default version  
> > > and say that it MAY be added but its not required and that if "v"  
> > > tag is not present the header field should be processed as 
> if it  had 
> > > default "1.0" version tag
> >
> > The rationale here is to avoid defaults as much as 
> possible.  I don't 
> > see any
> > functional difference between "no version" and using 
> version 1.0 as you have 
> > suggested.
>
> 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

DKIIMTransitions.doc
Description: DKIIMTransitions.doc