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

[Alan DeKok <[e-mail]>]

On Jan 19, 2020, at 10:54 AM, Ryan Sleevi <[e-mail]> wrote:
> There’s zero need to use any existing CAs.

  I agree.

> Of course, the CAs are only going to do that if there are users: those who will buy or rely on those certificates. So you need to convince supplicants that a zero-touch world is worth it, AND that it can be as secure as manual configuration.

  First the solution needs to be defined.

> Supplicant vendors - whether they are open-source or operating system - are taking on the work to manage and police that root store.

  They "are" doing this?  I don't see that.

> They are not at all different. In both cases, the client has a principal it wants to validate: in RFC 6125, this is the reference name. This is the name in your credential in the case of EAP, the name of the host in the URL in WWW. The client wants to make sure it’s talking to the entity authorized for that name.
> 
> You can manually preconfigured exactly that entity. In EAP, this is incredibly easy to do when you’re provisioning the client credential to also provision the peer identity. This is the existing flow.

  I agree that they're similar, I'm not sure that they're identical.

> This may seem like splitting hairs, but it’s a _profound_ distinction if you’ve ever managed PKIs on operating systems, as this is not true. Shipping a CA list in the supplicant shipped in the OS != shipping a CA list in the OS. They are very different models of managing and configuring that should not be conflated. Android has plenty of OS components that ship their own root stores, separate from the root store it provides as part of its public API contract. We only need the former, not the latter.

  What matters is that the product the user ends up with has the CAs preconfigured for EAP.  The internal corporate structure is (to me) irrelevant.

> It sounds like this has circled back into “How do we get Apple/Microsoft/Google/whomever to have their supplicants trust a set of CAs by default”, and the steps outlined above continue to be it. For Google/Android/ChromeOS, I’m not going to want to conflate the TLS PKI and the EAP PKI if they have different operational considerations (e.g. the ease of replacement of certs and the ability to respond to CA incidents), different profile considerations (the information being attested), and different policy considerations (how that information is validated). The advocates of such a solution need to do the work in defining the profiles and policies and presenting that as the use case for why.

  Sure.

> To the OS vendor, managing these profiles and policies is a non-trivial undertaking involving a host of folks: Legal (for contracts and CP/CPS review), Engineering, Project/Program Management (it’s a lot of work to review several thousand CAs a year, let alone the 60-70 organizations in the root store), Release Management, etc. There has to be a value proposition here, because the convenient part of the much maligned manual configuration is that it outsourced all the risk the OS vendor might be taking on, and instead allows it to be the customer’s problem. That may seem unfair and non-ideal, but that’s where the risk/value calculus is right now, and to get vendors to change, you need to present a compelling value case that demonstrably minimizes risk. Trust is hard and expensive 🤷

  There have been attempts to simplify supplicant configuration with a standard XML format.  The vendors expressed zero interest.  And that's a *lot* easier to do than adding a new root store.

  Alan DeKok.