Subject: [ietf-dkim] 4871bis/4871 interop

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Jun 2009 15:48:54 +0100

It'd be useful for us, as chairs, to know if we have consensus
around requirements for interop between implementations of 4871
and 4871bis.

Some of the discussions about things to deprecate may affect that,
so if we have a clear understanding in advance it might short-cut
some discussions of specific topics. (When developing 4871 from
DomainKeys we did have a pretty clear set of principles we followed
for this, so if we can get to a similar level of understanding it
may help. For example, we required that DomainKeys key records
should be usable by 4871 so as not to require folks to re-key
when they moved to support 4871.)

We see these as the various ways in which implementations
could interop. If we had consensus on whether each of these
was a MUST, SHOULD or MAY that'd be good IMO.

Key Records:

1) 4871bis-compliant code [MUST|SHOULD|MAY] be able to use
   4871-compliant key records
2) 4871-compliant code [MUST|SHOULD|MAY] be able to use
   4871bis-compliant key records

Signatures:

3) 4871-compliant code generated signatures [MUST|SHOULD|MAY] be
   verifiable by 4871bis-compliant code
4) 4871bis-compliant code generated signatures [MUST|SHOULD|MAY] be
   verifiable by 4871-compliant code

If you could indicate your preferences that'd be good. Just reply
to this with your MUST|SHOULD|MAY preferences for 1-4.

In case it helps with interpreting this saying e.g. MUST for (3)
would mean a 4871bis verifier would never reject a 4871 signer's
signature just because it included some deprecated field. Saying
MAY for (2) would mean that some "new" key records would not be
usable with some 4871-compliant implementations.

If you say SHOULD anywhere, please specify what you mean, e.g.
by saying "except in the case of <<foo>>"

Thanks,
Stephen & Barry.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 09:42:43 -0700

On Jun 2, 2009, at 7:48 AM, Stephen Farrell wrote:

> Key Records:
>
> 1) 4871bis-compliant code MUST be able to use 4871-compliant key  
> records
> 2) 4871-compliant code MUST be able to use 4871bis-compliant key  
> records
>
> Signatures:
>
> 3) 4871-compliant code generated signatures MUST be verifiable by  
> 4871bis-compliant code
> 4) 4871bis-compliant code generated signatures MUST be verifiable by  
> 4871-compliant code

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 12:14:01 -0700

>    4871-compliant key records

SHOULD, in the classic "you should have a good reason not to" sense.

>    4871bis-compliant key records

MAY

>    verifiable by 4871bis-compliant code

SHOULD, as above.

>    verifiable by 4871-compliant code

MAY

---

From: John Levine <[email-masked]>
Date: 2 Jun 2009 20:50:05 -0000

>Key Records:
>
>1) 4871bis-compliant code SHOULD be able to use
>2) 4871-compliant code SHOULD be able to use
>3) 4871-compliant code generated signatures SHOULD be
>4) 4871bis-compliant code generated signatures SHOULD be

By SHOULD, I'm assuming we will remove some of the cruft, so that
signatures that didn't depend on exotic use of the cruft will still
work, e.g., an l= value is the actual body length so the body hash
covers the whole body, or an x= value is in a reasonable range.

The practical effect as far as I can see is only that we have to
reserve the key letters of the stuff we take out so it's not reused
for something else in DKIM N+1.  It already says that unrecognized
tags are ignored.

R's,
John