Rely on name constraints or intermediate CA pinning?

Question

Two different services are exposed, call them 'cat service' and 'dog service'. "Cats" and "dogs" authenticate to the services via client certificates. The client certificates have cat and dog identities in the Subject (or SAN) field.

The PKI hierarchy is as follows:

           root CA
        /           \
   cat CA            dog CA
     /                 \
cat client certs     dog client certs

I want to prevent cat service CA operator issuing dog client certificates (and the other way around).

It appears there are two options for this:

1. use the name constraint certificate extension on the intermediate CAs. In this case, the server is configured to trust the root CA. Now, if a client sends a dog certificate signed by the cat CA (+cat CA as a part of the cert. chain), the server sees a contradiction and rejects even before validating against the root CA.

2. Have the 'cat service' listener pin the intermediate 'cat CA' and dog service pin the 'dog CA'. In this case, the server doesn't trust the root CA.

3. As pointed out in the comments by garethTheRed, there's also the third option: >> Use Certificate Policies to constrain each CA path to an OID. Have the Root CA issue each Sub CA cert with it's own OID and have the server check this during path verification of the client certificate.

What are the upsides/downside/comparison of the three approaches?

Note: this is question different than Will two intermediate CAs signed by the same root CA trust each other's signed client certs? as it asks if there's any particular down/upsides for any of two listed approaches.

Answer 1

I prefer option #2, as it's simple to understand, simple to implement across different stacks.

Option #1, you need to define mutually exclusive Name Constraints for the two services, possibly makes certificate issuance more difficult (additional checks need to be done before issuing cat/dog client certs), ensure the certificate chain validation library you are using properly respects Name Constraints extensions, etc.

I know you mentioned that the validation will be done on the service, which you have more control over, but if the validation has to be done by browsers, Safari/IE and possibly other browsers don't implement it properly.