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

["Eliot Lear (elear)" <[e-mail]>]

Thanks, Ryan.  After I sent the note I thought about document signing.  Our SUDI model at Cisco I view as somewhat different, but may be closer to apt to EAP anyway, so worth discussing.

Eliot

On 8 Jan 2020, at 12:26, Ryan Sleevi <[e-mail]<mailto:[e-mail]>> wrote:



On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) <[e-mail]<mailto:[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]<mailto:[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)