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

[Ryan Sleevi <[e-mail]>]

On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) <[e-mail]> wrote:

> Hi Ryan,
>
> This topic seems like a good one to just get on the phone and sort
> through, but I have one question:
>
> On 8 Jan 2020, at 09:11, Ryan Sleevi <[e-mail]> wrote:
>
> However, if using the same set or CAs that popular OSes use for TLS, it
> does mean that these CAs, and their customers, will still be subject to the
> same agility requirements, and limited to the same profile as TLS. Because
> of this, there’s ample reason to split further into the dedicated hierarchy
> and dedicated EKU.
>
>
> Is there an example of a non-EAP use where splitting into a new hierarchy
> has actually succeeded?
>

Document signing generally fits there, in that there are a number of CAs
that only offer document signing/identity proofing without overlapping. As
would, say, Cisco’s device/firmware signing model or the PKIs in use in the
financial services/ATM markets.

Relevant to EAP would be the aforementioned Passpoint model, which uses new
and distinct CAs for that. There are definitely flaws with that (e.g.
wanting said CAs to work with browsers), but there are parts of it that do
work.

There’s no technical reason to require the use of the same roots/same
hierarchy, and ample and adequate reason to distinguish: both from the
perspective of a root store maintainer (ensuring certificates comply with
policies) and as a certificate consumer (minimizing risk of misissuance,
ala Flame)

>