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