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