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 ([EMAIL PROTECTED]) 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
