In re-reading this charter, I still don't think we're quite there: a. Why is there still a charter item for EAP-TLS? This work hasbeen completed, no? b. Attempting to extend EAP-TLS to support tunneling or channel bindings is not appropriate. EAP-TLS already widely deployed, with large investments in conformance tests. Given the number of existing TLS-based tunneling protocols, such a work item would serve no useful purpose. Let's focus on adding channel binding support to tunnel methods. c. To some extent, I agree with Dan and Yoav with respect to the need for password-based methods. Had such methods been availableearlier, it's questionable whether TLS tunneling would have takenoff to the extent that it has. Also, I think that such methods, if specified in the IETF, would be likely to be widely deployed. However, on the other hand I think that this is really an issue for the entire security area, not just for EMU. So I'd suggest that this issue be brought up in SAAG. =====================================================================Below is a revision to the EMU charter that is intended to reflect thediscussions in the Philadelphia meeting. Please respond to the list ifyou approve of the charter or if you have any comments on the charter.I would like to have responses by 4/24. Thanks, Joe
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu