In the design of PKI, an intermediate CA is utilized, which was briefly introduced in the installation tutorial. I have a few questions I'd like to ask:
Thank you, looking forward to your reply.
Hi @KerwinKoo, welcome to the community and to OpenZiti (and zrok and browzer)!
The quick starts were always intended to be learning tools, not production style install scripts. As such, there are various commands and features on demonstration that may or may not be of value. One such feature of the ziti CLI is creating pki components. Specifically, creating root cas and intermediate cas. The complex pki on display in the quick starts simply illustrate that it's possible to structure a pki with whatever root/intermediate structures you might want to support. There's no more rationale than that.
If you look at the recently created deployment section of the docs instead and inspect the pki it creates, you'll see there's a single root ca, a single intermediate and that's it.
The related commands are ziti pki create. For example looking at the source of the quickest, you can find that command invoked a few times ziti/quickstart/docker/image/ziti-cli-functions.sh at main · openziti/ziti · GitHub
As for "How can these functions be reflected in product design?", I'm not really sure I'll have an answer for you. Everyone is different here and it's probably an exercise for you to determine what sort of setup you want to support.
I mentioned before the quickstarts weren't intended to be production deployments but the reality is there are many many networks that used the quickstarts to get going, and have been running great for people for a very long time. Many people are happy to just keep the complex pki because in the long run, it's generally only used by the overlay itself and it works, so I imagine the platitude why "fix"what isn't "broke"applies.
Hope that helps
Hi @TheLumberjack , Thank you for your response. I am learning about zero-trust network security and have come to understand the structured design and use of PKI, which plays a role in isolating risks after the leakage of certificate keys. I've also noticed that ZITI has such designs, so I would like to learn about ZITI's philosophy in PKI design, such as whether it utilizes the PKI structure of ROOT CA + intermediate CA + LEAF CA, and what kind of security enhancements this approach can bring to zero-trust.
It really doesn't have one. It expects you to understand any and all ramifications of the established PKI and to configure your overlay accordingly. There are good reasons for lots of different types of setups and it's up to the operator to decide what fits best for them.
Our sensible defaults for a deployment -- which you'll find when using the deployment-doc Controller Deployment | OpenZiti is to make a single root (which you could then choose to move the key for which somewhere safe) and one intermediate. But that is not our ethos, that's just "one great way to do it". 
@TheLumberjack Thank you for your response. I understand that ZITI makes good use of the security and advantages of PKI while also retaining enough flexibility for users to design their own PKI structures.