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:
- oldRoot uses a RSA key.
- newRoot uses an ECDSA key.
- To allow people to validate certificates issued by newRoot even if they do not know newRoot as a trusted root, a cross-certificate is issued, containing the name and public key of newRoot, but signed by oldRoot.
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.