Here is the promised summary of the issues presented at IETF65, and my
interpretation of the resolution. I've made a vague distinction here
between "Open", meaning that the issue still needs work, and
"Accepted", meaning that the issue's accepted and is being resolved,
and the resolution will be confirmed on the mailing list when the
related text (or the next iteration of the draft) is posted.
Items with a status of "Close" or "Reject" will be closed when the
minutes are accepted (I will merge this into the minutes). Items with
a status of "Accept" are essentially resolved, and will be closed after
review of the associated text. Items marked "Open" need further
discussion here.
-------------------------------------------------------
Threats issues:
1171: Clarification of the DKIM mechanism in introduction
Close, use current text
1172: Impact of signed message replay
Reject, consensus to leave as "Low"
1221: ABNF: Sender = Originator / Operator
Accept, Dave will give Jim a list of changes
Base issues:
1183: Should we have an r= tag in either the signature or key record
Open, take to mailing list
1184: Develop plan for transition of multiple crypto algs (a=)
Open, take to mailing list
1185: Transition sha-1 to sha-256
Accept, proposed wording
1193: instead of signing the message, sign the hash
Open, take to mailing list
1194: whitespace in signature?
Accept, check grammar for CFWS vs FWS
1195: 3.4.6 Example (Canonicalization)
Open, Hector must provide text, Paul will describe examples he'd like
to see
1196: Upgrade indication and protection against downgrade attacks
Open, some support for list of what I sign, some think it doesn't
matter; security area suggest that verifier decides what's OK
1200: MUST vs SHOULD in Verifier Actions section
Accept, Eric will propose text changes
1201: change the syntax from SPF compat to human compat
SSP issue, deferred until then
1203: extendable RR records
Accept, editorial issue for Eric
1204: issue with DKIM simple header algorithm and milter-based
implementations
Accept, Eric will add text warning about this issue with "simple"
1215: clarifications on use of l= tag
Close, Eric has edited text
1216: signature h= and z= tags
Open; clarify, h= required, z= optional and diagnostic, independent
(decoupled); take to mailing list
1222: ABNF: Sender = Originator / Operator
Accept, Dave will give Eric a list of changes
1224: DKIM and mailing lists
Open, continue on mailing list
1226: 512 too short?
Accept, use Russ's text
1227: bunch of nits for base
Accept, editorial issues for Eric
1228: Why is s= REQUIRED?
Reject, consensus NOT to have default selector
1229: z= field and EAI wg
Open, investigate EAI work
1230: selectors and key rollover
Close, leave as is, ASRG may discuss in BCP
1231: some process-problematic references in base
Open, must address as RR doc forms (Authentication-Results already
handled)
1235: Clarify delegation to 3rd parties
Accept, Eric will propose wording to clarify
1236: Analyzing Failures: List of Possible Reasons
Accept, Eric will edit
Extra: x= and clock skew
Resolution unclear; remove x=?; recommend (secure) NTP?
I think we need to open an issue on this one, Eliot.
-------------------------------------------------------
Corrections welcome....
For completeness, let me add two new issues that have been opened since
IETF65:
-------------------------------------------------------
1247: threats... (EKR) review of threats-01
Accept, Jim resolving, reviewing with EKR
1255: base... optional exponent needed or not?
Open, discuss on mailing list
-------------------------------------------------------
Barry Leiba, DKIM Working Group co-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