How to approach 2 tier PKI RSA Root CA with subordinates that should support ECDSA

Question

I have a situation for which I am not sure how to approach it. Basicialy I need to find out if it is possible how to issue ECDSA Certificates with a RSA Root Certificate. Is this possible? and how would I go about it?

This is the situation: Currently there is a single tier PKI with a RSA root. We need a tier 2 PKI with 2 subordinates. The plan is to setup the 2tier PKI next to the single tier and then migrate all the templates. One of the requirements now is however that our PKI should support ECDSA certificates because one of our devices we will start using has the following requirements:

• Datapath encryption: AES256 Counter Mode
• Keying messages encryption: EAS256 GCM Mode
• Web access: AES256 GCM Mode
• Digital Signature: SHA-384, ECDSA-521 for load signature
• Key generation: ECC and ECDH P-384 (secp384r1)
• Web browser supported ciphers: TLS_ECDHE_ECDSA_WITH_AES256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES128_GCM_SHA256

I have seen a post that seems to ask something in the same direction, however the answers that follow are a bit unclear to me.

Answer 1

This is actually not uncommon. Just have a look at google.com when forcing ECDSA ciphers:

$ openssl s_client -connect google.com:443 -servername google.com -cipher 'ECDSA' -showcerts
...
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIHxzCCBq+gAwIBAgIIEW2Lf7xzMtQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
...
-----END CERTIFICATE-----

openssl x509 -text on the first certificate (*.google.com) shows that it is as expected an ECC certificate, but that it is signed by an RSA key (sha256WithRSAEncryption):

    Issuer: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    ...
    Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=*.google.com
    ...
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)
            pub: 
                04:94:3c:36:cd:84:17:27:5d:cb:a5:af:ff:b5:4a:
                ...
            ASN1 OID: prime256v1
            NIST CURVE: P-256
Signature Algorithm: sha256WithRSAEncryption
     8a:52:2c:ec:e0:ee:c4:18:33:71:38:10:ea:55:2a:62:68:13:
     ...

The issuer of this certificate is as shown Google Internet Authority G3 and looking at the details of the second certificate provided by the server shows as expected that it has a RSA public key:

    Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
    ...
    Subject: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:ca:52:4b:ea:1e:ff:ce:24:6b:a8:da:72:18:68:
                ...

Creating an certificate with an ECC public key signed by a CA certificate with a RSA public key is nothing special: just create a CSR for the certificate with an ECC public key and let it sign by the CA. There is no difference in signing an ECC certificate vs. a RSA certificate.

Answer 2

That should be fine. As @TomLeek says in the answer that you link to:

a CA can use any signature algorithm, regardless of the type of key in the signed certificates.

---

It's certainly more common for issuing CAs and their roots to use the same signing algorithm, for example, on Entrust's root certificate download page you can see that they have separate PKIs for RSA and ECC:

• RSA: Root CA G2 with issuing CAs L1K and L1M
• ECC: Root CA EC1 with issuing CAs L1F and L1J

I think this makes it more efficient for the client to verify, for example for an ECC PKI you only need to specify the domain parameters in the root cert, and therefore save on bandwidth, or for constrained IoT devices with limited code space you only need to support one algorithm.

That said, I don't think anything will prevent you from having a mixed-algorithm PKI.

---

Summary

Try it, it "should just work".

If it doesn't, then feel free to post another question with details of the error you ran into.