On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok <al...@deployingradius.com> wrote:
> I'm trying to solve the problem of bootstrapping. I agree that various > CAs have various rules. I agree that anyone can run their own private CA, > and do whatever they want. I've been doing that, and recommending it, for > ~20 years. Great. Let’s focus on one problem at a time to make sure it’s easier to follow along. Earlier in the thread you seemed fixated on the first problem, so it’s unclear when/where/how shifted to the second. When the CA *isn't* included with the OS distribution, it means that CA > *cannot* be used to bootstrap TLS-enabled applications. Each application > (not just EAP) MUST be manually configured with the CA. This isn’t true, if you mean that the end user needs to manually configure. Modern OSes allow the application vendor - such as the supplicant vendor - to explicitly configure. The alternative is to ask the application to naively trust a CA it > doesn't know, and a CA which isn't included with the OS distribution. I > don't think that will happen. The alternative is the application ships it’s own root store. Which applications have been doing for 20+ years and which modern OSes make even easier. It's easy for a browser vendor to tell a CA "issue certs our customers > can use". It's much, much, harder for anyone else to do the same thing. Not really? CAs are plenty happy to sell whatever folks want. Look at stuff like the drone PKI being developed. What other application developers can’t do - and this is intentional - is to get their certs and profiles for the same roots, even if they’re the same issuing organization. It's less of an objection than a statement that we're back to the initial > conclusion: use a private CA, manually configure, and ignore the root CAs > shipped with the OS distribution. > > How does that help with the bootstrapping problem? I already gave that answer several times. Define your profile and policies, pick (different) roots, and ship them in your software. It’s mistaken to suggest that you HAVE to use the same roots as the OS. I'm happy to use a new PKI. But we *cannot* and *must not* rely on every > application to "do it yourself". There must be a trust anchor shipped with > OS distributions, that applications can leverage. No, there doesn’t. That’s an unreasonable demand, because it’s insisting that advocates of the problem don’t want to actually do the work involved in developing a solution for the problem. There’s absolutely no reason to require that it be shipped as part of the OS. Plenty of PKIs exist without requiring that, and modern OSes make it easier. Now, it may be that OSes do this, in the future, but that only happens by first building the profile and policies. Because that’s all an OS root store is: a set of CAs known to meet particular profiles and policies. Anyone can define that. > It’s completely unreasonable to be complaining “CA X won’t let me use > certificates for this purpose” if you’re not addressing that with CA X. And > it’s completely unreasonable to complain that Root stores intended for use > case Y cannot be used with use case Z. Hammers make lousy screwdrivers, > even if they are both “tools one uses when building furniture” > > Sure. So how does *my* application get Microsoft, Apple, etc. to ship a > new PKI? Provide a problem statement and a solution that’s compelling enough for them to use? Fixating on the “new PKI” or “must be shipped in the OS” is completely unreasonable expectation, especially when even the _existing_ PKI doesn’t solve the bootstrap problem unless you convince the OS. There’s zero advantages to using extant PKI, and ample downside, and you can move quicker and ship things by just doing the work.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
