인증 기관

어떤 공개키가 누구의 것인지를 대신 보증해 주는 곳입니다. 보증한다는 표시로 인증서에 자기 서명을 붙여 내줍니다. 그 서명을 믿기로 한 쪽은 상대를 직접 확인하지 않고도 공개키의 주인을 판단합니다.

상세

처음 보는 사람이 정말 자기가 말하는 그 사람인지는 본인 말만 들어서는 알 수 없습니다. 그래서 우리는 누구 소개로 왔는지, 그 소개한 사람은 또 누가 아는 사람인지를 거슬러 올라가 봅니다. 어느 이름이 나오면 더 묻지 않을지는 묻는 쪽이 저마다 정해 둡니다.

인증 기관(Certification Authority, CA)은 공개키 값을 주체에 묶고 그 묶음이 참이라고 주장하는 쪽입니다. RFC 5280 은 공개키를 쓰는 쪽이 그 공개키와 짝인 개인키를 정말 상대가 갖고 있다는 확신을 필요로 한다고 적습니다. 그 확신은 공개키 인증서로 얻습니다. 인증서는 공개키 값을 주체에 묶는 자료 구조이고, 그 묶음은 신뢰받는 인증 기관이 인증서마다 디지털 서명을 붙임으로써 주장됩니다.

인증 기관은 이 주장을 여러 근거 위에 세울 수 있습니다. 도전-응답 규약으로 소유를 증명하게 하는 기술적 수단일 수도 있고, 개인키를 직접 제시받는 것일 수도 있고, 주체 자신의 진술일 수도 있습니다. 인증서에는 제한된 유효 기간이 있습니다. 그 기간은 서명된 내용 안에 적힙니다.

인증서의 서명과 시의성은 인증서를 쓰는 클라이언트가 따로 검사할 수 있습니다. 그래서 인증서는 믿지 못하는 통신 경로와 서버를 거쳐 배포해도 되고, 보호되지 않은 저장소에 캐시해 둬도 됩니다.

검증하는 쪽은 아무 데서나 검사를 시작할 수 없습니다. RFC 5280 은 유효한 인증 경로가 신뢰 시작점이 발급한 인증서에서 시작한다고 적습니다. 경로 검증 알고리즘은 그 인증 기관의 공개키와 이름, 그리고 그 키로 검증할 수 있는 경로에 걸리는 제약을 요구합니다.

무엇을 신뢰 시작점으로 삼을지는 정책 문제입니다. 계층형 공개키 기반구조(Public Key Infrastructure, PKI)의 맨 위 인증 기관일 수도 있고, 검증하는 쪽 자신의 인증서를 발급한 인증 기관일 수도 있고, 망형 공개키 기반구조의 다른 어느 인증 기관일 수도 있습니다. 어느 쪽을 골라도 경로 검증 절차 자체는 같습니다. 응용마다 서로 다른 시작점에 기대기도 합니다. 여러 시작점 가운데 어느 것에서 시작하는 경로든 받아들이기도 합니다.

배경

공개키는 그 자체로는 누구 것인지가 적혀 있지 않은 값입니다. 그 공개키로 암호화를 하거나 서명을 검증하려는 쪽은 짝이 되는 개인키를 정말 상대가 갖고 있다는 확신을 필요로 합니다. 키를 직접 건네받지 않는 한 그 확신은 저절로 생기지 않습니다.

그래서 공개키 값을 주체에 묶어 두는 자료 구조가 필요했습니다. 그리고 그 묶음이 참이라고 대신 말해 줄 쪽이 필요했습니다. 그 자료 구조를 공개키 인증서라 부르고, 거기에 디지털 서명을 붙여 묶음을 주장하는 쪽을 인증 기관이라 부릅니다.

묶는 쪽과 검사하는 쪽이 갈리자 하나가 더 따라왔습니다. 검사하는 쪽은 확실하다고 여기는 인증 기관 공개키를 제한된 수만 갖고 출발합니다. 그래서 대체로 인증서 한 장으로 끝나지 않습니다. 여러 장이 이어진 사슬이 필요해질 수 있습니다. RFC 5280 은 최종 주체의 인증서 한 장과 다른 인증 기관들이 서명한 인증 기관 인증서 0장 이상으로 이어진 그 사슬을 인증 경로라 부릅니다.

예시

Issuer 필드

인증서 안에서 발급한 쪽을 가리키는 자리가 Issuer 필드입니다. RFC 5280 은 이 필드가 인증서에 서명해 발급한 개체를 식별한다고 적습니다. 값은 비어 있지 않은 식별 이름(Distinguished Name, DN) 이어야 하고, X.501 의 Name 타입으로 정의됩니다. Name 은 국가 이름 같은 속성과 US 같은 값이 짝을 이뤄 계층으로 쌓인 이름입니다.

basicConstraints 확장의 cA

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

basicConstraints 확장은 이 인증서의 주체가 인증 기관인지, 그리고 이 인증서가 낀 유효한 인증 경로의 최대 깊이가 얼마인지를 밝힙니다. cA 불리언은 인증된 공개키를 인증서 서명 검증에 써도 되는지를 가리킵니다. cA 가 서 있지 않으면 키 용도 확장의 keyCertSign 비트를 세워서는 안 됩니다. 버전 3 인증서에 이 확장이 없거나, 있어도 cA 가 서 있지 않으면, 그 공개키를 인증서 서명 검증에 써서는 안 됩니다. cA 의 기본값은 FALSE 입니다. 아무것도 적지 않으면 서 있지 않은 것으로 봅니다.

ISRG Root X1 과 Let's Encrypt R10

Let's Encrypt 는 자기가 운영하는 인증 기관을 공식 문서에 값으로 적어 둡니다. 루트 하나는 이렇습니다.

Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Key Type: RSA 4096
Trusted until: 2030-06-04 (generated 2015-06-04)

같은 문서는 인증 기관을 키와 이름의 짝으로 보는 것이 가장 정확하다고 적습니다. 한 인증 기관이 같은 주체 이름과 공개키 정보를 담은 인증서 여러 장으로 나타날 수 있기 때문입니다. 최종 인증서를 실제로 발급하는 것은 이 루트가 아니라 그 아래 중간 인증 기관입니다.

Subject: C=US, O=Let's Encrypt, CN=R10
Key Type: RSA 2048
Valid until: 2027-03-12
CA details: (signed by ISRG Root X1)

R10 은 ISRG Root X1 이 서명했습니다. Issuer 필드가 서명해 발급한 개체를 식별하므로, R10 인증서의 Issuer 자리에는 ISRG Root X1 의 식별 이름이 들어갑니다.

갈래

인증 기관이 갈리는 축은 그 기관의 인증서가 인증 경로의 어느 칸에 놓이느냐입니다.

flowchart TD
    R["루트 인증 기관"] -->|서명| I["중간 인증 기관"]
    I -->|서명| E["최종 주체 인증서"]

경로는 신뢰 시작점에서 시작해 중간 인증 기관을 거쳐 최종 주체의 인증서에서 끝납니다. 앞 칸이 뒤 칸의 인증서에 서명합니다.

루트 인증 기관

경로를 여는 자리입니다. 검증하는 쪽이 이 인증 기관의 공개키와 이름을 미리 갖고 있어야 경로 검증이 시작됩니다. 어느 것을 그 자리에 둘지는 검증하는 쪽의 정책입니다.

그 정책을 소프트웨어 배포자가 대신 정하기도 합니다. Mozilla 는 Firefox·Thunderbird 를 비롯한 자사 소프트웨어를 배포할 때 여러 인증 기관 운영자의 X.509v3 루트 인증서 묶음을 함께 싣는다고 적습니다. 실린 인증서에는 용도별 신뢰 비트가 세워져 있습니다. 그래서 소프트웨어가 사용자에게 따로 묻지 않고 TLS(Transport Layer Security, 전송 계층 보안) 서버와 S/MIME(Secure/Multipurpose Internet Mail Extensions) 전자우편 사용자의 인증서에 신뢰 사슬을 걸 수 있습니다. 이 정책이 걸리는 자리는 둘입니다. 하나는 그 저장소에 실렸거나 실릴 것을 검토받는 인증 기관 인증서입니다. 다른 하나는 그런 인증서까지 유효하고 폐기되지 않은 경로가 이어지는 중간 인증서입니다. 실제로 서버나 전자우편 인증서를 낼 수 있는 것들입니다.

중간 인증 기관

위에서 서명을 받고 아래에 서명을 내주는 자리입니다. 검사하는 쪽이 확실한 인증 기관 공개키를 제한된 수만 갖고 출발하기 때문에 이 칸이 생깁니다. 어느 인증 기관의 공개키를 아직 확실한 사본으로 갖고 있지 않을 때가 있습니다. 그러면 그 공개키를 얻으려고 인증서가 한 장 더 필요해질 수 있습니다. 그렇게 여러 장이 이어집니다.

깊이에는 상한을 걸 수 있습니다. pathLenConstraint 필드는 cA 불리언이 서 있을 때에만 뜻이 있습니다. 키 용도 확장이 있다면 그 확장이 keyCertSign 비트를 세워야 한다는 조건도 함께 붙습니다. 이 값은 유효한 인증 경로에서 이 인증서 뒤에 따라올 수 있는, 자기발급이 아닌 중간 인증서의 최대 개수를 정합니다. 0이면 뒤에 중간 인증 기관 인증서가 하나도 올 수 없습니다. 필드가 아예 없으면 상한이 걸리지 않습니다. 실제 운영도 이 모양을 따릅니다. Let's Encrypt 는 루트 키 자료를 오프라인에 안전하게 보관합니다. 가입자에게 주는 최종 인증서는 중간 인증 기관에서 냅니다. 중간은 네 장을 돌려 씁니다. ECDSA(Elliptic Curve Digital Signature Algorithm, 타원곡선 디지털 서명 알고리즘) 공개키를 담은 가입자 인증서는 ECDSA 중간에서 나옵니다. RSA(Rivest-Shamir-Adleman) 공개키를 담은 것은 RSA 중간에서 나옵니다.

PEM 이 정한 세 층

인증 기관을 어떻게 배치할지에는 여러 방식이 있습니다. RFC 5280 은 그중 하나로 RFC 1422 가 프라이버시 강화 전자우편(Privacy Enhanced Mail, PEM)을 위해 정한 고정 계층을 듭니다. 이 계층에는 세 종류의 인증 기관이 있습니다. 인터넷 정책 등록 기관(Internet Policy Registration Authority, IPRA)이 1층에서 뿌리 노릇을 합니다. 다음 층인 정책 인증 기관에만 인증서를 냅니다. 모든 인증 경로가 이 기관에서 시작합니다. 정책 인증 기관(Policy Certification Authority, PCA)은 2층입니다. 각각 IPRA 에게 인증받습니다. 인증 기관은 3층과 그 아래에 놓입니다. 3층의 것은 정책 인증 기관에게 인증받습니다. 이 층의 인증 기관은 특정 조직이나 조직 단위, 특정 지리 영역을 대표합니다.

관련 항목

인증서를 이루는 구성 요소

공개키 · 개인키 · 디지털 서명 · 공개키 인증서 · X.509 · X.501 · 식별 이름 · 인증서 확장 · 키 용도 · basicConstraints · 소유 증명 · RSA · ECDSA

신뢰 사슬을 이루는 개념과 기관

공개키 기반구조 · 신뢰 시작점 · 인증 경로 · 경로 검증 · 루트 저장소 · 최종 주체 · 이름 제약 · 자기발급 인증서 · Mozilla 루트 저장소 정책 · IPRA · 정책 인증 기관 · 인증

인증서를 나르고 쓰는 규칙

TLS · S/MIME · ACME(Automatic Certificate Management Environment, 자동 인증서 관리 환경) · PEM

인증서가 거치는 처리 단계

유효 기간 · 배포 · 인증서 폐기

실제 값으로 확인되는 인증 기관 사례

Let's Encrypt · ISRG Root X1 · Let's Encrypt R10