HI Jim, Thanks for bringing this up. I think it might be better to address this in a separate document since I think it can have more general applicability than TEAP. I'll add this to the TEAP discussion in Orlando. Comments inline below: On Mar 4, 2013, at 6:13 PM, Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote:
I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 – Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? [Joe] Both cases exist in deployments today, there are cases where server and client certificates are used for both HTTPS and EAP. It is more common on the client side. I believe EAP-TLS specifies the same EKUs as TLS for HTTP. I've always found it a bit strange, but I don't think ti has presented a serious deployment issue. I think it would be reasonable to define a new EKU, but I'd like to understand how it would or wouldn't work with what is out there. Question #2 – Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form “@realm” to be placed in a server certificate to define that it is the EAP server for the realm. This does assume that there will not be two different servers which are disjoint servicing the same realm but that would be a very unusual case. [Joe] Being able to identify the realm and NAI would be good. For the realm does this need to be distinct from DNS name? Jim _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu