Subject: [ietf-dkim] today's jabber agenda

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Jun 2006 15:43:36 +0100

1. agenda bashing
2. open issues (see attached)
3. AOB

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003648.html

talk to ya in about 15

Unresolved from last time, from Barry's notes:
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003720.html

Issue 1264: "(proposed fingerprint tag description)."
This was proposed by Murray, who wasn't on the jabber chat, and the 
participants didn't know enough about it to discuss it in Murray's 
absence.  Issue remains open; push it back to the mailing list.

Issue 1265: "(signing by parent domains)."
Some see potential issues with the ability to say something like 
"d=example.com" and "i=sub.example.com".  In particular, there's the 
danger of something like "d=com; i=example.com".  Some think there's 
little benefit to allowing it, and closing the hole would be better. 
Others see a great benefit, allowing example.com to have one place to go 
for keys, while signing for many subdomains.  Eric suggests this: 
"thought: a domain could use a CNAME for _domainkey.<dept>.example.com 
that would point up the tree." Jim Fenton will start a thread about this 
on the mailing list.  No resolution for now; leave open, discuss on 
mailing list.

Issue 1266: "(sec 5.2 move recommendations for key retention to a BCP)."
Lots of discussion about whether to specify a length of time or be vague 
about it, whether being vague is of any value to implementors, and 
whether it even makes sense to try to tell verifiers what they MAY or 
SHOULD do, since they can (and will) do whatever they want anyway.  In 
the end it seems that a modification of Doug's proposed rewording can be 
acceptable to all, so Eric is going to do another pass on the wording 
and post it to the mailing list.  Issue remains open until then.

Issue 1269: "(body length mechanism rejections)."
Looks like we're happy with what's in -02, but just as we start to move 
on there's more discussion along the "can't tell verifiers what to do" 
line.  The original issue was an objection to advising verifiers to 
"reject", and the consensus on that, as advice, stays.  In particular, 
we want to advise verifiers on determining whether a signature is 
*valid*, but leave the "what to do with it" part for another document 
(or local policy).  Tony doesn't like the advice to ignore the 
signature.  Others clarified that what we're really saying is to look at 
the other sigs in that case.  Most accept current wording, but there's 
some unhappiness all 'round, so it's not optimal.  Dave and Eric will 
collaborate on another iteration of this text, to try to resolve that 
and to make it clear what's normative and what's a recommendation. 
Issue remains open.

Issues raised in the last week on the list:

A. Fenton nits
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003757.html

B. Otis threats
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003756.html

C. Fenton, result codes
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003758.html

D. Fenton, normative order of steps
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003759.html

E. Otis, base-02 typos
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003760.html

F. Fenton, key lookup params
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003761.html

H. Otis, g=	template
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html

J. Otis, i= parameter
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html

K. Otis, signature removal
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003764.html

L. Otis, signature expiration
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003765.html

M. Otis, signing address
	http://mipassoc.org/pipermail/ietf-dkim/2006q2/003768.html

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