Allow Intermediate CAs as Trust Anchors #5033
Description
We have a use case, where we need to permit intermediate CAs as trust anchors (ICA trust anchors). We are not concerned with who has signed the intermediate CA, as long as it is present in the relevant certificate store.
Example
The full chain of trust is as follows:
Root CA (self-signed)
|
+-- Intermediate CA (signed by Root CA)
|
+-- End Entity Certificate (signed by Intermediate CA)
We intend to keep only the intermediate CA in our trusted certificate store; we do not store the root CA, trusting the intermediate CA on its own. However, when attempting to validate the end entity certificate, it doesn't succeed with Botan unless the root CA is added to the trusted certificate store.
Current Behavior
At present, ICA trust anchors are not compatible with Botan. The x509_path_validate function in Botan demands root CAs to be self-signed; otherwise, it returns a CERT_ISSUER_NOT_FOUND status due to the need for an existing issuer, even if the intermediate CA is included in the trusted certificate store.
What are your thoughts on whether we should permit ICA trust anchors?
References
RFC 5280
I've gathered some sections of RFC 5280 to help determine whether ICA trust anchors might be suitable or not:
When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.
(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes:
(1) the trusted issuer name,
(2) the trusted public key algorithm,
(3) the trusted public key, and
(4) optionally, the trusted public key parameters associated with the public key.
The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. When the trust anchor information is provided in the form of a certificate, the name in the subject field is used as the trusted issuer name and the contents of the subjectPublicKeyInfo field is used as the source of the trusted public key algorithm and the trusted public key. The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure.
This could be understood as "the trust anchor can be any entity that includes information (1)…(4)." This interpretation would support our approach. However, the RFC frequently mentions "self-signed certificate," suggesting that if the trust anchor is presented as a certificate, it must be self-signed.
For our use case, we've determined that ICA trust anchors are acceptable.
Bouncy Castle
I also tested Bouncy Castle, which supports ICA trust anchors. Similar to the RFC, BC defines a trust anchor as a tuple comprising (name, public key (includes the algorithm), constraints). Using an intermediate CA as a trust anchor is also valid in BC (I've tested the scenario above).
StackExchange
Can an intermediate CA be trusted like a self-signed root CA?
Implementation Approach
If we choose to permit ICA trust anchors, there are two options to consider:
- We add another Path_Validation_Restrictions to toggle this behavior.
- We always allow it.
I plan to eliminate the requirement for trusted certificates to be self-signed. Additionally, I would remove the signature validation for trusted certificates—either for all certificate store certificates or specifically for those that are not self-signed.
What are your thoughts? Do you have any concerns?