Subject: [ietf-dkim] Summary of jabber meeting of 22 June

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Jun 2006 15:03:56 -0400

The full jabber log can be found here:
http://www.ietf.org/meetings/ietf-logs/dkim/2006-06-22.html

The 22 June jabber meeting was called to order at 1500 UTC on, 
surprisingly, 22 June.  In attendance were, in jabber-roll-call order, 
Barry Leiba, Dennis Dayman, Doug Otis, Eric Allman, Jim Fenton, Peter 
Koch, Murray Kucherawy, and Mike Thomas.  The agenda was simply to go 
through the issues list and check status, to make sure we're on track 
for working-group last call of the -base-04 spec, which Eric intends to 
submit by the deadline of this Monday, 26 June, at 6 a.m. Pacific Time.

I will list the issues here, along with the conclusion and action 
item(s).  For details of the discussion, see the jabber log.

1286: draft-ietf-dkim-base-02 //a= algorithm ABNF
1286 will be CLOSED, change made for -base-04.

1287: base: signature removal
Discussion revealed that John Levine had volunteered to give Eric some 
proposed text to resolve this.
1287: REMAINS OPEN, John Levine to propose text to Eric.

1288: base: signing address
Jim Fenton had agreed to work with Eric on text for this.
1288: REMAINS OPEN, Jim to work with Eric on defining default in one 
place & referring to it later.

1289: Base-02 signature process clarification requested
Some did not understand this; Barry and Jim both do, and have 
volunteered to propose text.
1289: REMAINS OPEN, Barry to propose text.

1291: Use of "sender" in -base
Dave sent Eric text for this, but one other issue came up yesterday. 
Eric is OK to resolve that, so...
1291: CLOSE, fixed in -base-04

1292: draft-ietf-dkim-base-02 //g= template
Much discussion of this, with decision to define a flag instead of what 
the issue DB suggests now: Key record will have a new flag that says 
that i= must be the same as d= in order to use this key.
1292: CLOSE, fix will be made in -base-04 as per above.

1293: base-02 // worst-case scenario/duration of exploit/use of deprecated
Insufficient understanding of this item.  Doug has posted something he 
says is clearer, but people hadn't read it yet.  We'll all go back to 
the list with this one.
1293: REMAINS OPEN, study and discuss on mailing list.

1294: draft-ietf-dkim-base-02 //i= parameter conflict
Only Doug wants this, but no one else agrees.  Doug says that John 
Levine supports it, so we'll check that on the mailing list.  As it 
stands, NO CHANGE will be made for this unless there is other support.
1294: CLOSE with no change... pending confirmation on mailing list.

1295: issue with relaxed body canonicalization?
Brief discussion on whether to leave it in for now, consensus is to 
leave it and remove later (maybe at move to Draft Std) if it turns out 
to be unused.
1295: CLOSE, no change.

1296: [email-masked] vs. [email-masked]
This is John Levine's version of what basically is the same as 1292. 
Let's see if John likes the answer to 1292 for this too.
1296: CLOSE, see resolution for 1292 -- subject to confirmation with JohnL.

1297: Clarification on z=
Discussion about the QP thing and how to put leading blanks, already 
discussed on the mailing list.  Eric has posted text to mailing list, 
but not everyone has read it.  Go read.  Lacking objections, we'll use 
that text and close this.
1297: CLOSE, accept Eric's text for -base-04.

That's the end of the issues list.  Doug repeated a request that he's 
made before:  "There should be some consideration give the Security 
Consideration section regarding the affects of the _domainkey subdomain 
use."  Eliot, please open a new issue for this so we can track it.  So 
far, we've not seen support on the mailing list for putting this in, but 
we'll open a tracked issue for it and give it one more chance during WGLC.

DKIM meeting ended at 1558 UTC.  Thanks, all.....

--
Barry Leiba, DKIM Working Group Chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Jun 2006 14:06:13 -0700

Excellent, all... we're getting close :)

       Mike

Barry Leiba wrote:

> for working-group last call of the -base-04 spec, which Eric intends 
> to submit by the deadline of this Monday, 26 June, at 6 a.m. Pacific 
> Time.
>
> Much discussion of this, with decision to define a flag instead of 
> what the issue DB suggests now: Key record will have a new flag that 
> says that i= must be the same as d= in order to use this key.
> Consideration section regarding the affects of the _domainkey 
> subdomain use."  Eliot, please open a new issue for this so we can 
> track it.  So far, we've not seen support on the mailing list for 
> putting this in, but we'll open a tracked issue for it and give it one 
> more chance during WGLC.
>

---

From: John Levine <[email-masked]>
Date: 24 Jun 2006 11:01:58 -0000

Sorry I missed it, elementary school graduation took precedence.

>1294: CLOSE with no change... pending confirmation on mailing list.

No, that was 1292.

>1296: CLOSE, see resolution for 1292 -- subject to confirmation with JohnL.

I don't see the point of a flag that will always be set the same way,
but I can live with it.

R's from Marrakech,
John

---

From: Eliot Lear <[email-masked]>
Date: Sat, 24 Jun 2006 16:29:48 +0200

Barry,

All of these are done.  New issue for Security considerations is 1308.

Eliot

---

From: Eric Allman <[email-masked]>
Date: Sat, 24 Jun 2006 10:08:58 -0700

--On June 24, 2006 11:01:58 AM +0000 John Levine <[email-masked]> 
wrote:
>> This is John Levine's version of what basically is the same as
>> 1292.  Let's see if John likes the answer to 1292 for this too.
> I don't see the point of a flag that will always be set the same
> way, but I can live with it.

John, I think one of us must be missing something.  Why would the 
flag always be set the same?  The problem only occurs when you are 
using g= in the key, and there might be good reason why you would not 
want to limit the signature to the d= domain in this case, e.g., 
role-based names such as perhaps "postmaster".

eric

---

From: "John R Levine" <[email-masked]>
Date: 24 Jun 2006 19:22:27 -0400

> role-based names such as perhaps "postmaster".

I suppose tht [email-masked] might be the same as
[email-masked], but in my experience if [email-masked]
sends any mail, it's exactly because he's not the same person as
[email-masked].

But like I said, I can live with a flag.  If I'm right and it's always
set, we can deprecate it in 2009 or so.

R's,
John