Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Assume the following Public Key Infrastructure:
|Root CA (RSA)
|-Sub CA (RSA)
|-Sub CA (ECC)
Is there any rational that explains why this would not be an acceptable implementation?
Is the prefered implementation a PKI for RSA and a seperate PKI for ECC?
As per X.509, no problem. You can mix algorithms at will. Each signature is independent.
(X.509 includes a special provision for when a CA uses DSS and issues a certificate that also uses DSS with the same group parameters, in which case the issued certificate may omit the group parameters. This is called "parameter inheritance". This is never used in practice, and was not ported to ECDSA, even though it was a possibility and was apparently envisioned at some point. This is the only case, to my knowledge, where the signature algorithms at various levels in the chain have any relationship together.)
However, you must understand that by using several distinct algorithms, you force "relying parties" (systems that must validate these chains) to implement all of them. While this is normally not a problem for desktop systems and servers and smartphones, this could be an issue for small, embedded devices that want to save on code size, and would prefer not to include code for RSA and for ECDSA.
This kind of problematic is incarnated e.g. in SSL, where client and server tell each other what kind of algorithm they support for validating signatures on certificates (see for instance the Certificate Request message). This is meant to better support small devices with little code space. Making a mixture of RSA and ECDSA in your certificate chains puts you a bit at odds with that principle. Depending on your context, this may or may not matter (it will probably not matter).
In any case, that kind of mixed chain is expected for a transition. Suppose that you start with a full-RSA world; the root CA has been distributed to all client systems (possibly at a heavy cost). Now, you take the decision to switch to ECDSA, because client software is up to it (e.g. it came with normal OS / browser updates), but creating a new ECDSA root and pushing it onto all clients will take a lot of time. So, to begin using ECDSA without breaking things for the installed base, you make cross-certificates:
This cross-certificate allows systems that know newRoot as a trusted root to validate a certificate with a path "newRoot->cert", and systems that only know oldRoot will use "oldRoot->newRoot->cert" (in the latter case, going through the cross-certificate). In other words, newRoot has two certificates, one self-signed (with ECDSA), the other signed by oldRoot (making newRoot an intermediate CA).
This is a fairly standard method to handle renewals with key changes, but it necessarily implies, in the case of a RSA-to-ECDSA transition, mixed-algorithm chains. Thus, the situation that you describe is not only supported but expected.
To sum up: using completely separate PKI allows for single-algorithm PKI, which may help embedded devices (only one algorithm to implement). However, mixed-algorithm PKI are a normal thing, well supported, and expected in case of PKI-wide transitions to new algorithms.
To my knowledge, there is no requirements on the algorithm for the subordinate CA other than the one the root CA wants to enforce.
In fact, rather than looking for a rationale why it would be unacceptable, I would look into a rationale why it is acceptable. Any subordinate CA certificate must be signed by the root CA. And the root CA is representing the ultimate trust. If the root CA trusts the subordinate CA with a ECC/RSA/whatever algorithm certificate, then it's ok. The root CA signs the certificate and extends its trust.
However, you should probably provide a CA policy, where you state what you, as a CA, authorise, so that you clients can assess if they want to trust your root CA or not. Look at which algorithm are deprecated, or broken and never accept them in your certificates.
