What is the best practice for relying parties to selectively trust certificates in a corporate pki hierarchy?

Question

I have a pki infrastructure for internal company use. In this pki there are multiple registration authorities whose responsibility is to.

• receive certificate issuance requests
• verify the identity of the user/device/entity requesting the certificate
• forward the certificate signing request to the CA if the verification is successful.

The CA hierarchy is made of a RootCA, under which there are multiple intermediate CAs. Intermediate CAs are in a 1:1 mapping with Registration authorities. For each Registration Authority onboarded on the system there will be a corresponding Intermediate CA . The certificates requested through a given Registration Authority will be issued by the Intermediate CA that corresponds to it.

Each CA, will publish a CRL of the revoked certificates.

Under the model above a given entity can request and receive certificates through multiple RAs. Es. An entity X could “own” multiple certificates to attest its identity (es. CN: entity A Issuer: Intermediate CA RA 1, CN: entity A Issuer: Intermediate CA RA 2).

Since Registration authorities can apply distinct criteria, procedures and security standards for the end entity verification, a service that wants to authenticate entities based on the certificates issued by this pki infrastructure might want to trust only the certificate issued through some specific Registration Authorities and not others.

What is the best approach (best= most common/most secure/most supported) to allow relying parties to selectively trust only the certificates issued by a given RA?

1. The relying party keeps in its trust store and treats as trust anchors only the intermediate CA certificates corresponding to the RAs that it trusts. the RP does not keep in its trust store the RootCA certificate. The RP trusts any end certificates that has a chain that connects the ceritificate to any of the trusted intermediate CAs

   Consequences:
   1. In this case the RP, not trusting the rootCA will not be able to validate if the given Intermediate CA certificate was revoked, assuming the CRL is signed by the root CA.
   2. this implies that a mechanism exists for the CA infrastructure to communicate to relying parties the Intermediate CAs certificate that are “valid” and can be trusted for a given use cases
   3. what is the purpose of having a root CA at all if the trust anchors are always the intermediate CAs ?

2. The relying party keeps only the root ca in its trust store, and it trusts any end certificate that has a valid chain that

   • connects the certificate to that root ca and
   • whose content satisfies a set of additional constraints.

   As an example the RP could verify that:

   • the Issuer of the end certificate is the intended Intermediate CA (based on a convention on the name of the CA)
   • the end certificate subject fields contain specific information, such as the Organisational Unit subfield matches a pattern or has a specific value. In this case there would need to be a 1:1 mapping between the RA/CA and the OUs in the certificates. So that given the OU of the certificate the RP can know which RA/CA issued it. (https://docs.oracle.com/cd/E24191_01/common/tutorials/authz_cert_attributes.html)
   • the end certificate contains a specific Certificate Policy Extension (https://www.ietf.org/rfc/rfc5280.txt 4.2.1.4. Certificate Policies) In this case there would need to be a 1:1 mapping between RA/CAs and Certificate policies. We would need to reserve one new Certificate policy OID per each CA/RA. This seems to be what Windows/AD does with their own pki solution, calling these “application policies” (https://www.pkisolutions.com/object-identifiers-oid-in-pki/)

   Consequences:
   1. this implies there is a governance model for the pki infrastructure that guarantees that the certificates produced by each RA/CA pair can be distinguished based on some "intrinsic" properties from the certificates produced by any other RA/CA pair.

3. ...are there other alternatives?

Answer 1

Your option 2 is correct.

You need to use the Certificate Policies extension as you suggested.

X509 defines a Certificate Policy as:

A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

These rules are for the registration process and permitted use case as much as for the certificate issuance. In each case, you would need a policy OID for each CA/RA pair. Your Root CA has no Certificate Policy extension while each CA certificate has the OID in the Certificate Policy extension and also adds the extension to every certificate it issues.

Your relying parties will need to decide which policy they trust and provide its OID (or OIDs if it trusts more than one) for the certificate path validation process - this is called the user initial policy set. Only certificate chains which contain at least one of these OIDs will be trusted. The actual details are slightly more complex and are described in RFC 5280 Section 6.1.

That's the theory. In practice, it may not be so simple:

It may well work if your developing your own software; but it's not guaranteed to be available with software developed by others, as they may not give you the option to set the user initial policy set. In other scenarios it may not make sense for you to be expected to set the initial policy set before use - a web browser is a good example of this.

In the absence of a method to set the initial policy set, some applications use pattern matching on attributes such as the Subject Name, or Extended Key Usage as a method to restrict the applicability of a certificate (as you also mentioned in option 2).