On Jan 11, 2021, at 7:08 PM, Martin Thomson <m...@lowentropy.net> wrote: > I was not exactly. I was thinking that EAP-TLS uses the unadorned string and > other usages (that need a different MSK) define their own string as needed.
Which is largely what was done for <= TLS 1.2. That choice made implementations more difficult. Not impossible, but annoying. The other TLS-based EAP types are generally implemented as variants of EAP-TLS. They re-use much of the EAP-TLS code. So every difference is more code, and more things to test. > Though what you describe would scale more, if the ordinality of that scale > is bounded by RFC numbers, defining the extra strings would not be that hard. > You could provide some sort of infrastructure in the form of a recommended > label prefix if you are concerned about misuse. I'm not sure EAP-TLS is the place to make recommendations for other EAP types. There is a draft to deal with other EAP types: https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 It's pretty trivial. Adding more complexity is annoying, but not much worse than that. My preference is to remain with the EAP type as the context. The code is simple, and it's easy to understand. But if it causes issues with TLS review, we can change it. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
