sudoyear123

This is a very good question. We actually did consider proxy certs and name constraints certs first and had a long discussion at the IETF about these different options. At the end the consensus was that it would be much better to have a very minimal structure which could only do 1 thing and nothing else. DCs also have the advantage that they are cryptographically bound to a particular End entity certificate vs a particular public key only, and hence can only be used with their properties, so it really is the minimal possible thing you need and nothing more.

As a CA you can issue certificates for other domains as well which might be undesirable. There are existing mechanisms such as Name constrained CAs and proxy certificates to reduce this scope. While they were originally considered there are issues with them. There is no widespread support for either and there is no way to know whether both sides support them. DCs allow for a extremely minimal subset of what you might need to issue credentials with your own lifetime and it only affects you. DCs are cryptographically bound to the leaf certificate as well. A bunch of this is documented in the draft.

This would make a great comparison. I'm not certain whether or not K8's mutual auth supports session ticket resumptions and distribution of short lived ticket keys. The ticket rotation design would probably make a great addition to K8. There are a lot of intricate details in design which can make a major difference in not only performance but also whether or not the system wakes you up at night.

Ya they're similar in that they are all signed blobs of data, but different in the sense that they are specifically designed to send authentication information via several layers of proxies