Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

["David B. Nelson" <[e-mail]>]

On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <[e-mail]> wrote:
> 
>   Whether we have to convince "the OS vendor", or just "the supplicant division in the OS vendor" is largely the same thing.
> 
> It isn’t, and there’s been zero evidence to support that conclusion, but I can tell reality isn’t that convincing :)

I have to disagree with that.  There are exceptions to very rule, of course, but I have never downloaded, installed and configured a supplicant on any of my computing devices.  I’m a highly technical end-user (long time IETF and IEEE contributor).

> This is not about which department is involved. The distinction is about the scope of trust. Saying shipped in the OS, both in the context of this thread and more generally, is presuming a broad scope and maintained interfaces for third-parties, neither of which you need. Not recognizing that a “root store” on a modern OS is merely an abstraction over disparate trust bits is meaningful, particularly when not addressing what the “trust bits” should be or how they’re maintained.

And *that* is an artifact of the way vendors have chosen to ship their OS products.  I think what you’re saying is that large industry software providers aren’t going to change their behavior just because it inconveniences users (customers).  Maybe that’s true.  However, it’s an organizational and implementation argument, not a technical one.

> The IETF primarily targets those developers, not the end-user, and it’s essential to understand why and how it works to understand what work is needed to make something similar for EAP. Dismissing that as organizational structure just means dismissing the requirements and means to success, in which case, you’re going to be as unsatisfied as my appetite for a fresh unicorn burger.

Sure.  Standards are voluntary.  All *good* standards start with clear and accurate Use Cases and User Stories.  The ”users” have to include end-users, not just developers. Technical standards are successful when they solve end-user, market driven problems.  Standards that seek (primarily or secondarily) to preserve “the way we’ve always done it” among the vendor base, are not very useful, IMHO.

We all seem to agree that change is required.  Where we disagree is how change is implemented and who has to make it.  I’m not a unicorn-seeking idealist, but if the rationale behind a particular path to change is suboptimal because of vendor intransigence, then that needs to be very clearly documented for all stakeholders to see.

Regards,

Dave Nelson