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.
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:
PSS variants use the RSASSA-PSS
signature scheme described in
which is newer and considered more verifiably-secure. The
use the older PKCS#1 v1.5 signature scheme described in
Newer hierarchies are encouraged to use the
PSS variants if all applications
that will use those certificates support it. Otherwise, the
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.
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.
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.
You can use this simple guide to help you choose an appropriate signing algorithm for your CA key:
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.
(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
Otherwise, use one of the
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).