I was offline when I sent the charter update. I'm not sure there has to be only one mechanism, but I think it would be a desirable outcome. I like your text and will include it.
Thanks, Joe > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 30, 2008 4:54 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] EMU charter revision, > > [Joe] Jari had asked to keep this open to TLS. I think he > was suggesting it could be done as a TLS extension and would > not require tunneling. I agree that we do not want to extend > EAP-TLS to do tunneling. > > How about: > > "- Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on supporting EAP channel bindings within the tunnel > method. The possiblity of adding channel bindings to EAP-TLS > through a TLS extension or other standard TLS mechanism may > also be investigated. " > > [BA] I think we only want one mechanism for support of > channel bindings in TLS-based methods. So it's ok to > investigate a TLS extension vs. > other mechanisms for supporting channel bindings, but I'd > suggest we only want to choose one path. So my suggestion > would be to modify the text as follows: > > - Enable a TLS-based EAP method to support channel bindings. > This item will not generate a new method, rather it will > focus on adding support for EAP channel bindings. Potential > mechanisms for addition of support for channel bindings will > be investigated, including tunneling of channel > binding parameters, or a TLS extension or other standard TLS > mechanism." > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
