I have a pki infrastructure for internal company use. In this pki there are multiple registration authorities whose responsibility is to.
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?
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
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 ?
The relying party keeps only the root ca in its trust store, and it trusts any end certificate that has a valid chain that
As an example the RP could verify that:
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.
...are there other alternatives?
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).
External links referenced by this document: