On Jan 20, 2020, at 9:29 AM, Ryan Sleevi <[email protected]> wrote: > As I hoped my previous message conveyed, but it looks like it may not have > been clear for you, I'm not dismissive that for supplicants distributed by > the OS vendor, you (eventually) need to convince that OS vendor to distribute > roots with their supplicants, and from the end-user perspective, a default > install of that OS "just works". However, it's a very meaningful distinction > in the context of root stores, even if it may not be for supplicant authors, > to highlight the need to distribute roots _with the supplicant_, not the OS. > This is not a corporate distinction, but it is meaningful to how solutions > are engineered and the problem space, and that's why it does a great > disservice to dismiss that distinction.
We'll have to disagree here. That distinction is entirely a technical detail which is irrelevant to the end user. It doesn't matter to the standards bodies, either. The distinction doesn't even matter in the content of root stores. The vendor downloads N root CAs, and places them into files / DBs in the product. Whether those files from from A and go to B, or come from C and go to D is *entirely* irrelevant to the end product. Whether it's Department A that downloads the roots CAs or Department B is also irrelevant. Whether we have to convince "the OS vendor", or just "the supplicant division in the OS vendor" is largely the same thing. > The same goes for root CAs. While it's superficially true that someone can > start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* that CA. > Saying "you can start a CA" and by implication have people *use* it, is no > more realistic than me saying "you write software, Bill Gates wrote software, > there's nothing preventing you from being as rich as he is." > > This is again shifting the discussion. If you don't believe it is, then > certainly, how you're communicating is not coming across clearly. It's not shifting the discussion. It's directly addressing your point, as clearly as I can make it. > As I've mentioned several times, anyone can issue certificates, which is all > that matters for manual configuration. There's no need for anyone special or > blessed - it's just manual configuration. The issue, as I've mentioned several times, is that's where we are today. There's no need to bring up current behaviour as an option - we know it's an option. We're trying to fix it. > If you'd like to go to automatic configuration, then you need to define > policies and practices for issuance and verification. Anyone who can comply > with those can become a CA. The usefulness of "Billy Bob's Tackle Shop & CA" > is dictated by those who need a CA - the supplicants - and how well Billy Bob > complies with the policies and practices. You're absolutely correct that if > you don't define those, then _no one_ can become a CA. There's no reason to > believe that Billy Bob is more or less qualified than an extant CA unless and > until you define those. And, of course, once you define those, the usefuless > of Billy Bob - how likely his CA-slash-tackle-shop is to be included - is > dictated by those defining the root store. That's where the SDOs come in to > place. Which is largely what I was saying. So I think we're in agreement here. But again, this doesn't *help*. I can't get my CA shipped with vendor products, and nothing you've said convinces me that it's possible. > Then why are we wasting electrons discussing how to do it? If you believe > it's a doomed effort from the start, why bother replying? I never said it was "doomed". I was trying to suggest that there we need to have clear benefits, and a clear path to implementing the benefits. > The nice thing about the transition plan I've outlined several times is you > don't need the OS vendors to all adopt apriori for it to be useful. Other > supplicant vendors can go ahead, define their policies and practices, select > their CAs, and build their root store. And not a single person will download and use the new supplicant software. Making it 100% useless. Any "supplicant division" of an OS vendor will require high-level signify before massively changing user workflow. So in the end, it *is* the "OS vendor" who has to be convinced. > I'm afraid you've considerably misunderstood the proposal then, as I've tried > to express several times. I'm well aware the end goal is that on a 'stock' > install of your OS of choice, everything just works. I've outlined several > times a plan to get to that - and which does not involve shipping roots in > the OS, but roots in the supplicant that comes with the OS. The distinction > is quite meaningful for the reasons outlined throughout this thread, even if > the end user experience is "it just works" When I do RADIUS stuff, I say "the vendor has to do X". It's never been useful to say "Bob in engineering department X has to do it". The distinction you're making is 100% irrelevant. If this distinction is necessary and important, why has every other WG avoided doing it? i think we're at an impass. We agree on the end goal, but disagree fundamentally on some major points. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
