인증 기관(CA)을 만들려면 먼저 CA의 지원 Cloud Key Management Service 키의 서명 알고리즘을 선택해야 합니다. Certificate Authority Service를 사용하면 지원되는 비대칭 서명 알고리즘을 사용하거나 이러한 알고리즘의 소규모 하위 집합을 선택하고 서비스가 키 수명 주기를 만들고 관리하도록 지정하는 방식으로 기존 Cloud KMS 키를 사용해서 CA를 만들 수 있습니다.
이 페이지에서는 CA 서명 알고리즘을 결정할 때 고려해야 하는 요소들에 대해 설명합니다.
알고리즘 계열
Cloud KMS는 비대칭 서명 작업을 위해 RSA와 ECDSA라는 두 가지 알고리즘 계열을 지원합니다.
RSA
RSA 기반 서명 스킴은 오래된 사용 기간 만큼이나 여러 플랫폼에서 폭넓은 호환성을 누립니다. 기존 운영체제, 프로토콜, 펌웨어, 기타 기술 스택을 사용하는 클라이언트를 지원해야 하는 경우 RSA가 일반적으로 선택됩니다.
Cloud KMS에서는 RSA_SIGN_PSS와 RSA_SIGN_PKCS1이라는 두 가지 주요 RSA 서명 알고리즘을 이용할 수 있습니다. PSS 변형에는 RFC 8017의 섹션 8.1에 설명된 RSASSA-PSS 서명 스키마가 사용되며, 이는 최신 기술로서 보다 안전한 것으로 고려됩니다. PKCS1 변형에는 RFC 8017의 섹션 8.2에 설명된 이전의 PKCS#1 v1.5 서명 스킴이 사용됩니다.
새로운 계층 구조에서는 이러한 인증서를 사용할 수 있는 모든 애플리케이션에서 지원될 경우 PSS 변형을 사용하는 것이 좋습니다. 그렇지 않으면 지원 범위가 넓은 PKCS1 변형이 더 적합합니다.
ECDSA
타원 곡선 기반의 비대칭 키가 다른 RSA 변형보다는 비교적 최신 기술이지만 지난 10년 동안 출시된 인기 있는 많은 기술 스택에서도 여전히 지원됩니다. 이러한 기술은 RSA 키와 보안 수준이 비슷하지만 사용되는 키 크기가 작기 때문에 특히 인기가 많습니다. ECDSA 키를 사용하는 애플리케이션은 저장 및 전송되는 데이터 양이 적습니다.
Cloud KMS에서는 EC_SIGN_P256와 EC_SIGN_P384이라는 두 가지 주요 ECDSA 서명 알고리즘을 이용할 수 있습니다.
혼합 체인
혼합(또는 하이브리드) 체인은 하나 이상의 인증서에 일부 인증서의 RSA 및 다른 인증서의 ECDSA와 같은 여러 다른 키 알고리즘 계열이 사용되는 인증서 체인을 의미합니다. 일부 기술 스택은 혼합 인증서 체인을 파싱하는 데 문제가 있으며, 이러한 경우 예상치 않은 오류가 발생할 수 있습니다. 또한 일부 산업에서는 규정 준수 요구사항에 따라 CA 체인에 단일 알고리즘 계열을 사용해야 할 수 있습니다.
RSA 키에 사용되는 것과 달리 ECDSA 키에 대해 별개의 CA 체인을 설정하는 것이 일반적입니다.
키 크기
동일한 계열 내에서 키 크기가 더 크면 보안 강도를 높일 수 있지만 저장 및 전송되는 데이터도 증가합니다. 또한 경우에 따라서는 너무 작아서 인지하지 못할지라도 키 크기가 커서 암호화 및 서명 작업에 시간이 오래 걸릴 수 있습니다.
루트 또는 장기 실행 종속 CA와 연관된 것과 같이 장기적으로 지속되는 키의 경우에는 다른 키보다 보안 강도가 높은 키 크기를 사용하는 것이 일반적인 방식입니다.
의사결정 가이드
CA 키에 적합한 서명 알고리즘을 선택할 때는 다음과 같은 간단한 가이드가 도움이 될 수 있습니다.
알고리즘 계열 선택
기존 루트 CA까지 연결되는 종속 CA 체인을 만들 경우 루트와 동일한 계열을 사용합니다.
새로운 루트 CA를 만들 때 ECDSA를 지원하지 않는 기존 시스템을 사용해야 할 경우에는 RSA 서명 알고리즘 중 하나를 사용합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eWhen setting up a Certificate Authority (CA), you must select a signing algorithm for the Cloud Key Management Service key, choosing between RSA and ECDSA families.\u003c/p\u003e\n"],["\u003cp\u003eRSA algorithms are ideal for compatibility with legacy systems due to their widespread support, with \u003ccode\u003eRSA_SIGN_PSS\u003c/code\u003e being preferred for newer systems and \u003ccode\u003eRSA_SIGN_PKCS1\u003c/code\u003e for older ones.\u003c/p\u003e\n"],["\u003cp\u003eECDSA algorithms offer strong security with smaller key sizes, making them efficient for storage and data transmission, and they are available in \u003ccode\u003eEC_SIGN_P256\u003c/code\u003e and \u003ccode\u003eEC_SIGN_P384\u003c/code\u003e variants.\u003c/p\u003e\n"],["\u003cp\u003eFor new root CAs or long-lived subordinate CAs, it's recommended to use the largest key size available within the chosen algorithm family, such as 4096 bits for RSA or 384 bits for ECDSA.\u003c/p\u003e\n"],["\u003cp\u003eThe guide recommends choosing an algorithm family first (based on root CA's or legacy system support), then selecting a specific signature algorithm (PSS or PKCS1 for RSA), and finally determining the key size based on CA lifetime and security needs.\u003c/p\u003e\n"]]],[],null,["# Choose a key algorithm\n======================\n\nBefore creating a certificate authority (CA), you must choose a signing\nalgorithm for the CA's backing Cloud Key Management Service key. Certificate Authority Service allows\ncreation of CAs with preexisting Cloud KMS keys using any of the\nsupported [asymmetric signing algorithms](/kms/docs/algorithms#asymmetric_signing_algorithms),\nor by choosing from a\n[smaller subset](/certificate-authority-service/docs/reference/rest/v1/projects.locations.caPools.certificateAuthorities#signhashalgorithm)\nof those algorithms and having the service create and manage the key lifecycle.\n\nThis page mentions the factors you must consider when deciding a CA's\nsigning algorithm.\n\nAlgorithm families\n------------------\n\nCloud KMS supports two families of algorithms for asymmetric signing\noperations: RSA and ECDSA.\n| **Note:** CA Service doesn't support Ed25519 algorithms.\n\n### RSA\n\nRSA-based signature schemes enjoy wide compatibility across multiple platforms\nby virtue of their age. If you need to support clients using legacy operating\nsystems, protocols, firmware or other technology stacks, RSA is a common choice.\n\nCloud KMS exposes two major variants of RSA signature algorithms:\n`RSA_SIGN_PSS` and `RSA_SIGN_PKCS1`. The `PSS` variants use the RSASSA-PSS\nsignature scheme described in\n[section 8.1](https://tools.ietf.org/html/rfc8017#section-8.1)\nof RFC 8017, which is newer and considered more verifiably secure. The `PKCS1`\nvariants use the older PKCS#1 v1.5 signature scheme described in\n[section 8.2](https://tools.ietf.org/html/rfc8017#section-8.2) of RFC 8017.\n\nNewer hierarchies are encouraged to use the `PSS` variants if all the applications\nthat might use those certificates support it. Otherwise, the `PKCS1` variants\nare a more suitable choice due to their wider support.\n\n### ECDSA\n\nWhile asymmetric keys based on elliptic curves are relatively newer than their\nRSA counterparts, they are still supported in many of the most common technology\nstacks released over the last decade. They are especially popular because they\ncan achieve similar levels of security strength to RSA keys using smaller key\nsizes. Applications that use ECDSA keys store and transmit less data over the wire.\n\nCloud KMS exposes two major variants of ECDSA signature algorithms:\n`EC_SIGN_P256` and `EC_SIGN_P384`.\n\n### Mixed chains\n\nA mixed (or hybrid) chain is a certificate chain where one or more certificates\nuse different key algorithm families, such as RSA in some certificates and\nECDSA in others. Some technology stacks have trouble parsing mixed certificate chains,\nand might show unexpected errors for those cases. In addition, some industries\ncan have compliance requirements that require a CA chain to use a single\nalgorithm family.\n\nIt is typical to set up a separate CA chain for ECDSA keys than the ones used\nfor RSA keys.\n| **Note:** Unlike algorithm families, using different key sizes within a chain is a common practice.\n\nKey size\n--------\n\nWhile larger key sizes (within the same family) provide greater security\nstrength, they also result in more data being stored and transmitted over the\nwire. In addition, encryption and signing operations can sometimes take longer\nwith larger key sizes, though this is usually too small to notice.\n\nA typical practice is for longer-lasting keys, such as those associated with\nroot or long-lived subordinate CAs, to use key sizes with greater security\nstrength than other keys.\n| **Note:** Regardless of the chosen key size or intended CA lifetime, we recommend defining a process for key rotation. A CA key may need to be rotated earlier than expected due to events such as key compromise, or newer advancements in cryptography that might result in weakened security.\n\nDecision-making guide\n---------------------\n\nYou can use this simple guide to help you choose an appropriate signing\nalgorithm for your CA key:\n\n1. **Choose an algorithm family**\n\n If you are creating a subordinate CA chaining up to an existing root CA, use\n the same family as the root.\n\n If you are creating a new root CA but need to work with legacy systems\n that don't support ECDSA, use one of the\n [RSA signing algorithms](/kms/docs/algorithms#rsa_signing_algorithms).\n\n Otherwise, use one of the\n [Elliptic curve signing algorithms](/kms/docs/algorithms#elliptic_curve_signing_algorithms).\n2. (RSA only) **Choose a signature algorithm**\n\n If you expect to work with older libraries or frameworks that don't support\n PSS, use one of the `RSA_SIGN_PKCS1` algorithms.\n\n Otherwise, use one of the `RSA_SIGN_PSS` algorithms.\n3. **Choose a key size**\n\n For a new root CA or a subordinate CA that is expected to have a lifetime in\n the order of years, we recommend that you use the largest key size available\n for that algorithm family.\n - For RSA, the largest supported key size is 4096 bits.\n - For ECDSA, the largest supported key size is 384 bits.\n\n For subordinate CAs with a shorter lifetime, it is sufficient to use smaller\n key sizes, such as 2048 bits for RSA or 256 bits for ECDSA.\n\nWhat's next\n-----------\n\n- Learn about [Cloud KMS: Key purposes and algorithms](/kms/docs/algorithms).\n- Learn about [Cloud KMS: Digital signatures](/kms/docs/digital-signatures).\n- Learn how to [manage resources](/certificate-authority-service/docs/managed-resources)."]]
