Choose a key algorithm

Before creating a certificate authority (CA), you must choose a signing algorithm for the CA's backing Cloud Key Management Service key. Certificate Authority 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.

This page mentions the factors you must consider when deciding a CA's signing algorithm.

Algorithm families

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

RSA

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 technology 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 section 8.1 of RFC 8017, which is newer and considered more verifiably secure. The PKCS1 variants use the older PKCS#1 v1.5 signature scheme described in section 8.2 of RFC 8017.

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

ECDSA

While asymmetric keys based on elliptic curves are relatively newer than their RSA counterparts, they are still supported in many of the most common technology 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. Applications that use ECDSA keys store and transmit less data over the wire.

Cloud KMS exposes two major variants of ECDSA signature algorithms: EC_SIGN_P256 and EC_SIGN_P384.

Mixed chains

A mixed (or hybrid) chain is a certificate chain where one or more certificates use different key algorithm families, such as RSA in some certificates and ECDSA in others. Some technology stacks have trouble parsing mixed certificate chains, and might show unexpected errors for those cases. In addition, some industries can 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 have a lifetime in the order of years, we recommend that you use the largest key size available for that algorithm family.

    • For RSA, the largest supported key size is 4096 bits.
    • For ECDSA, the largest supported key size is 384 bits.

    For subordinate CAs with a shorter lifetime, it is sufficient to use smaller key sizes, such as 2048 bits for RSA or 256 bits for ECDSA.

What's next