ietf-dkim
[Top] [All Lists]

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

2006-06-24 07:33:55
Barry,

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

Eliot

Barry Leiba wrote:
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: user(_at_)sub(_dot_)example(_dot_)com vs. user(_at_)example(_dot_)com
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  (leiba(_at_)watson(_dot_)ibm(_dot_)com)
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

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

<Prev in Thread] Current Thread [Next in Thread>