Choosing a key algorithm

Before creating a Certificate Authority (CA), you must choose a signing algorithm for its backing Cloud KMS key. CA Service allows creation of CAs with preexisting Cloud KMS keys using any of the supported asymmetric signing algorithms, or by choosing from a smaller subset of those algorithms and having the service create and manage the key lifecycle.

There are a number of factors that should be considered when deciding on a CA's signing algorithm. Read on to understand these factors, or skip to the decision-making guide below.

Algorithm families

Cloud KMS supports two families of algorithms for asymmetric signing operations: RSA and ECDSA.


RSA-based signature schemes enjoy wide compatibility across multiple platforms by virtue of their age. If you need to support clients using legacy Operating Systems, protocols, firmware or other tech stacks, RSA is a common choice.

Cloud KMS exposes two major variants of RSA signature algorithms: RSA_SIGN_PSS and RSA_SIGN_PKCS1. The PSS variants use the RSASSA-PSS signature scheme described in RFC 3447, which is newer and considered more verifiably-secure. The PKCS1 variants use the older PKCS#1 v1.5 signature scheme described in RFC 2313.

Newer hierarchies are encouraged to use the PSS variants if all applications that will use those certificates support it. Otherwise, the PKCS1 variants are a more suitable choice due to their wider support.


While asymmetric keys based on Elliptic Curves are relatively newer than their RSA counterparts, they are still supported in many of the most common tech stacks released over the last decade. They are especially popular because they can achieve similar levels of security strength to RSA keys using smaller key sizes, which means less data being stored or transmitted over the wire by applications that use those keys.

Mixed Chains

Some tech stacks have trouble parsing certificates whose issuing chain includes both RSA and ECDSA keys, and might show unexpected errors for those cases. In addition, some industries may have compliance requirements that require a CA chain to use a single algorithm family.

It is typical to set up a separate CA chain for ECDSA keys than the ones used for RSA keys.

Key size

While larger key sizes (within the same family) provide greater security strength, they also result in more data being stored and transmitted over the wire. In addition, encryption and signing operations can sometimes take longer with larger key sizes, though this is usually too small to notice.

A typical practice is for longer-lasting keys, such as those associated with root or long-lived subordinate CAs, to use key sizes with greater security strength than other keys.

Decision-making guide

You can use this simple guide to help you choose an appropriate signing algorithm for your CA key:

  1. Choose an algorithm family

    If you are creating a subordinate CA chaining up to an existing root CA, use the same family as the root.

    If you are creating a new root CA but need to work with legacy systems that don't support ECDSA, use one of the RSA signing algorithms.

    Otherwise, use one of the Elliptic curve signing algorithms.

  2. (RSA only) Choose a signature algorithm

    If you expect to work with older libraries or frameworks that don't support PSS, use one of the RSA_SIGN_PKCS1 algorithms.

    Otherwise, use one of the RSA_SIGN_PSS algorithms.

  3. Choose a key size

    For a new root CA or a subordinate CA that is expected to live longer than 5 years, use a 4096-bit key (for RSA) or a 384-bit key (for ECDSA).

    Otherwise, it is sufficient to use a 2048-bit key (for RSA) or a 256-bit key (for ECDSA).

See also