Alan – Adding yet another OID and/or EKU to a certificate does not change the fact that no authority can attest to that information. A public CA cannot validate a ownership of an NAIRealm. So while a supplicant could be configured to validate that the server’s NAIRealm matches the local configuration, that doesn’t change the requirement to manually configure the supplicant. So what are we actually trying to improve here?
From: Alan DeKok <al...@deployingradius.com> Date: Monday, November 18, 2019 at 10:43 AM To: Cappalli, Tim (Aruba) <t...@hpe.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] Best practices for supplicants and authenticators On Nov 18, 2019, at 10:37 AM, Cappalli, Tim (Aruba) <t...@hpe.com> wrote: > > If the goal is not to improve identity assurance of an EAP server then what > is this best practice change actually for? I have been *explicit* in my statements that my goal *is* to improve validation of the EAP server identity. I have no idea how anyone could interpret those statements as meaning the opposite of their clear intent. So I have no idea what you're getting at. Please explain yourself using something *other* than a leading question which gets everything wrong. i.e. state a position and defend it. Attacking a straw man version of someone else's position is unhelpful. Alan DeKok.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
