Some people joined the jabber room early, but we then had problems --
people lost contact with the room, couldn't re-join, and so on.
Problems seemed resolved by 15:15 GMT, and we decided to start at
15:30, to give everyone time to get back on.
Meeting was called to order at 15:30 GMT. Agenda posted:
1. Agenda bashing
2. Finialise text for x=
3. AOB
Attendees:
Stephen Farrell
Jim Fenton
Olafur Gudumundsson
Phillip Hallam-Baker
Tony Hansen
Arvel Hathcock
Paul Hoffman
Peter Koch
Barry Leiba
Doug Otis
Bill Oxley
Shamim Pirzada
Hector Santos
Agenda Item 1, agenda bashing:
Doug requested time in AOB to discuss the "7 days" text in section 5.2.
No other agenda issues.
Agenda Item 2, text for "x=":
Issue 1: "SHOULD" in proposed text.
Paul questions how SHOULD fits here, considering RFC 2119. Several
comments that MAY is fine. Hector initially thinks verifier "MAY
support" expiration is OK, but if supports, "MUST" honour expiration.
Arvel wonders why bother supporting it if you don't honour it,
supporting Hector's version. Paul counters that x= is a REQUEST from
the signer, and the verifier can/should do what it wants with the
information. Others agree. Barry suggests that perhaps a supporting
verifier might want to honour it differently for different signers
(using reputation, perhaps), but that idea gets no interest. Hector
and Arvel agree with Paul in the end, and Jim likens "x=" to a "best
sold before" date, where the verifier may "drink the milk" anyway, but
"shouldn't be surprised if it's sour." General agreement (and
amusement) here, and there are no objections to using MAY throughout.
Resolution: Change to MAY; Stephen will propose new text to the mailing
list.
Issue 2: Treating expired sig as "broken sig" vs "absent sig".
Hector is concerned that verifiers WILL treat broken different from
absent, despite what the spec says, and wants to make sure that we put
expired sigs on the right side of that. Barry explains history: if we
recommend treating broken vs absent differently, they expose DKIM to
different attacks, and so we must advise treating them the same. Given
that, there's little to be gained by worrying about where expired sigs
fit, because a verifier will still choose its own preference, and we
can only give advice.
Resolution: Leave as is.
Issue 3: Barry checks something from mailing list discussion. On the
mailing list, some seemed to think that some were advocating making
previous verifications become invalid after expiration. WAS anyone
actually advocating that, or was it a misunderstanding. Conclusion was
that it was a misunderstanding, and once the sig is verified (prior to
expiration), the expiration time becomes irrelevant.
Issue 4: Which "time" at verifier is used to determine expiration?
"received" time, or "current" time? The distinction is important if
verification is done in MUA, and Doug and Hector both want "received"
time. Much discussion here, with lots of it centering on whether
received time can be determined reliably, people don't want to be
recommending parsing Received lines, and such.
Resolution: Suggest using received time "if reliably available", else
current time. Arvel and Jim aren't sure, but accept it if it's "MAY".
Stephen will propose text.
Issue 5: Hector wants to add "step 0" in section 6.2, allowing verifier
to check x= first, and shortcut key retrieval if sig has expired. Some
discussion there, consensus to add it, as "MAY".
Along with this there was discussion of returning SMTP 4xx errors vs
<whatever else the verifier does with the message>. Observation that
4xx is ONLY appropriate for true temporary key retrieval errors, and
should NOT be used for other verification problems. We chould check
text to be sure that's reflected.
Agenda Item 3, any other business.
Issue 6: Doug's item about "7 days" in 5.2.
If verification is done in MUA, 7 days is not enough time for a key to
remain available. General agreement that there's a significant issue
here, but no good ideas how to resolve it. Given that, and the fact
that we were out of time, we will take the general question of
"verification in MUA" issues to the mailing list, with the note that
DKIM is intended to be primarily used in the MTA/MDA, but that it
should allow for MUA use in its design. We especially need to look at
the timeout and routine key rollover issues with that in mind.
Meeting adjourned at 16:30 GMT.
--
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