요약

  • Joseph Mandel과 Sean Turner가 공동으로 편집한 RFC 10002는 소유 증명(Proof-of-Possession)을 최종 주체가 공개 키에 해당하는 개인 키를 보유하고 사용할 수 있음을 보여주는 증거로 다룹니다. 이는 그 사실을 신원 증명이나 인증서 수령 자격의 증거로 만들지 않습니다.
  • 신원 증거와 키 보유 증거는 CMC에서 별도로 전달되며 동일한 요청자에 결합되어야 합니다. 등록 기관(Registration Authority)의 변경은 서명된 요청 밖에 존재하고, 인증 기관(Certification Authority)은 여전히 자체 정책을 적용하며 요청된 결과를 수정하거나 보류하거나 거부할 수 있습니다.
  • 내구성 있는 등록 영수증은 모든 전환을 보존해야 합니다: 원본 요청, 소유 증명 방법, 신원 증명 방법, 대체 방지 연계, RA 래퍼, CA 결정, 반환된 상태, 실제 발급된 인증서, 그 이후의 설치와 검증까지. 어떤 '통과' 상태도 그 이전이나 이후의 상태를 덮어쓰지 않아야 합니다.

등록 콘솔에POP verified라는 한 줄의 안심 메시지만 떠 있는 장면을 상상해 보십시오. 요청자가 그 안의 공개 키에 해당하는 개인 키로 PKCS #10 메시지에 서명했고, 서명 검증도 통과했습니다. 이 암호학적 진술은 정확하고 가치 있는 것입니다.

하지만 그것은 결정에 직결되는 질문 대부분을 답하지 못합니다. 요청자는 누구인가? 그 사람이나 장치가 요청된 주체 이름을 주장할 자격이 있는가? Subject Alternative Name은 누가 승인했는가? 중개자가 확장 필드를 추가하거나 제거했는가? 발급자는 어떤 인증 정책을 적용했는가? 인증서가 발급되어 전달되고 설치되었는가? 의존 서비스가 지금 그것을 수용할 것인가?

CMS 기반 인증서 관리(Certificate Management over CMS)가 유용한 것은 바로 이런 질문들을 하나로 뭉개지 않기 때문입니다. 2026년 7월 IETF Standards Track으로 발행된 RFC 10002는 현재의 CMC 메시지 구조를 정의합니다. RFC 10003은 전송 방식의 선택을, RFC 10004는 CMC 에이전트 등급별 준수 요건을 규정합니다. 세 문서 모두 Joseph Mandel과 Sean Turner가 편집자이며, 이 작업은 PKCS #10, CRMF, CMS 그리고 더 넓은 X.509 공개 키 인프라 위에 세대에 걸쳐 축적된 집단적 산출물입니다.

Turner의 긴 표준화 이력은 맥락을 제공할 뿐, 특정 등록에 대한 개인적 권한이 아닙니다. IETF Datatracker는 2026년 9월 1일 기준으로 그가 IETF 34부터 참여했고, 50편이 넘는 RFC를 단독 또는 공동 저술했으며, 2007년부터 2014년까지 보안 영역 디렉터(Security Area Director)를 지냈고, 여러 워킹 그룹의 과거 및 현직 의장을 맡았다고 기록하고 있습니다. 이러한 사실은 왜 보안 표준에 그의 이름이 올라가는지 설명해 줍니다. 하지만 그렇다고 그가, IETF가, 어떤 RFC가 특정 요청의 등록 기관이나 인증 기관이 되는 것은 아닙니다.

서명은 요청을 보호할 뿐, 승인하지 않는다

PKCS #10은 요청자가 공개 키, 주체, 속성을 하나의 서명된 인증 요청으로 묶을 수 있게 해 줍니다. 그 서명을 검증하면 메시지가 경솔하게 변조되지 않았고, 서명자가 대응하는 개인 키로 서명을 만들 수 있음을 확인할 수 있습니다. 공격자가 서명된 객체 안의 공개 키를 몰래 교체하면서 요청을 유효하게 유지하는 것도 막습니다.

이것은 강력한 결과이지만, RFC 2986은 그 다음 단계를 별도로 기술합니다. 인증 기관은 요청 주체를 인증하고, 서명을 검증하고, 요청이 기관의 규칙에 따라 유효하다면 인증서를 구성합니다. 이 연결이 중요합니다. 올바른 서명이 곧 CA에게 발급을 명령하거나, 요청된 모든 필드를 그대로 선택하도록 하거나, 주장된 모든 이름을 수용하도록 하지는 않습니다.

RFC 10002는 키 질문을 소유 증명(Proof-of-Possession, POP)으로 일반화합니다. 서명 기반 증명, 직접 챌린지-응답, 간접 증명, 공개, 증명서 첨부 형태를 인정하지만, 모든 CMC 교환이 모든 형태를 사용하는 것은 아닙니다. 공통 목적은 의도적으로 좁게 정의되어 있습니다: 최종 주체가 공개 키에 해당하는 개인 키를 보유하고 사용할 수 있음을 보이는 것.

POP 자체는 주체가 누구인지에 대해 아무것도 말하지 않습니다. 도난당한 키도 유효한 서명을 만들 수 있습니다. 올바르게 관리된 키가 무단 도메인 이름과 함께 제시될 수도 있습니다. 하드웨어 장치는 키 사용을 증명하면서 자산 대장상의 신원은 틀릴 수 있습니다. 한 사람이 키를 통제하더라도 고용주, 서비스 또는 규제 직무를 위한 인증서를 요청할 권한이 있을 리는 없습니다.

운영상의 실수는 낮은 수준의 참된 진술을 다른, 더 높은 수준의 진술로 승격시키는 것입니다.개인 키 사용 가능이요청자 신원 확인됨으로, 그것이이름 승인됨으로, 다시인증서 승인됨으로 바뀝니다. CMC는 이런 승격에 대한 어떤 면허도 제공하지 않습니다.

신원은 또 하나의 증명이며, 결합 자체가 보안 사건이다

RFC 10002는 신원 증명(Proof-of-Identity)을 별도로 정의합니다. 신원 증명을 포함해야 하는 경우 단순 PKI 요청(Simple PKI Request)을 사용해서는 안 됩니다. 전체 PKI 요청(Full PKI Request)은 공유 비밀 기반의 신원 위트니스를 담거나, 양측이 이해하는 기존 방식의 일부로 기존 인증서를 사용할 수 있습니다.

별도의 증거는 별도의 공격 경로를 만듭니다. 한 주체가 유효한 신원 위트니스를 제공하고 다른 주체가 유효한 키 증명을 제공했다면, 중개자는 이 둘을 하나로 겉보기에 완전한 요청으로 결합해서는 안 됩니다. 그래서 RFC는 신원 정보와 POP가 동일한 주체에 의해 제공되었음을 보이도록 결합을 요구합니다. 위트니스 계산, 공유 비밀과 주체 이름의 대조, 기존 인증서와의 연계가 그 결합을 위한 메커니즘입니다.

이 결합에는 그 자체의 영수증이 필요합니다. 어떤 신원 증거가 수용되었는지, 그 소유자가 누구인지, 어떤 키 증명이 검증되었는지, 어떤 바이트가 결합되었는지, 어떤 대체 검사가 실행되었는지, 어떤 식별자가 둘을 이었는지 기록하십시오.신원과 POP 통과만 적어두면, 개별적으로 올바른 두 증명이 원래 한 쌍이었는지 판단할 방법이 없어집니다.

공유 비밀 방식은 암호학이 사후에 복구할 수 없는 경계를 노출합니다. 그 비밀의 배포는 RFC 10002의 범위 밖입니다. 잘못된 장치에 전달되었거나, 너무 넓게 재사용되었거나, 재시도를 거듭하며 살아남았다면, 올바른 위트니스는 관리가 허술한 비밀에 대한 지식만을 증명할 뿐입니다. 검증자는 방법과 한계를 그대로 남겨 두어야 하며, 결과를 만능 신원 보증으로 다시 이름 붙여서는 안 됩니다.

RA는 계층을 얹을 수 있어도 역사를 다시 쓸 수는 없다

CMC는 최종 주체(End 주체), 등록 기관(Registration Authority), 인증 기관(Certification Authority)을 구분합니다. 최종 주체는 키 쌍을 소유하고 인증서를 추구합니다. RA는 로컬 증명, 일괄 처리, 라우팅, 키 생성, 아카이빙 또는 확장 처리를 수행할 수 있습니다. CA는 인증서를 발급합니다. 동일한 시스템이 최종 주체를 향한 CMC 서버이자 CA를 향한 클라이언트로 동작할 수 있고, 여러 RA가 중첩된 래핑 계층을 만들 수도 있습니다.

프로토콜상의 방향이 곧 권한은 아닙니다. 요청을 받았다고 RA가 조용히 요청자가 되는 것은 아니고, 요청을 전달했다고 RA가 발급자가 되는 것도 아닙니다. 로컬 정책상 행위자에게 권한이 없는 상태에서도 그 홉은 기술적으로 유효할 수 있습니다.

서명된 내부 요청이 결정적 경계입니다. RA는 서명된 PKCS #10 또는 CRMF 요청을 편집해서는 안 됩니다. 편집하면 그 서명과 POP가 무효화되기 때문입니다. RA가 CA에게 필드 변경이나 확장 추가를 요구한다면, CMC는 그 행위를 외부 제어 요소에 배치합니다. 그러면 기록은 최종 주체가 무엇을 요청했는지와 중개자가 별도로 무엇을 제안했는지를 동시에 보여줄 수 있습니다.

이 구분은 확장 필드에서 특히 중요해집니다. 요청자는 키 용도, 이름, 정책 또는 기타 X.509 확장을 요구할 수 있습니다. RFC 10002는 서버가 요청된 모든 확장을 인증서에 재현할 것을 요구하지 않습니다. 서버는 요청을 수정할 수 있지만, 원래 의도를 반대로 바꾸어서는 안 됩니다. 따라서 최종 인증서는 요청의 사본도 아니고, 요청자가 모든 중개자의 결정에 동의했다는 증거도 아닙니다.

발급된 인증서만 보관하면 협상 과정이 사라지고, 원본 요청만 보관하면 그것을 변경한 권한이 사라집니다. 방어 가능한 최소 역사에는 서명된 요청, 모든 중첩 RA 래퍼, 각 수정과 그 정책적 근거, 서명자들, CA가 평가한 템플릿, 반환된 정확한 결과가 포함됩니다.

HTTP 성공과 CMC 성공은 서로 다른 시계

RFC 10003은 HTTP, 파일, 메일, TCP를 통한 CMC 교환을 허용합니다. HTTP에서는 클라이언트가 POST와 정의된 MIME 타입을 사용합니다. HTTPS는 채널을 보호할 수 있지만, 전송 문서는 모든 CMC 클라이언트에게 HTTP 인증 구현을 요구하지 않습니다. 채널 암호화, HTTP 인증, CMC 신원 증명, 키 보유 증명은 서로 다른 질문에 답합니다.

상태 코드도 그렇습니다. 2xx HTTP 응답은 HTTP 교환이 성공적으로 처리되었음을 말할 뿐입니다. 그 안의 CMC 응답은 여전히 처리 보류, 신원 불량, POP 요구, POP 실패, 미지원 확장을 말할 수 있습니다. 전송 성공은 발급 판정으로 사용될 수 없습니다.

성공적인 CMC 응답조차 구체적인 객체를 필요로 합니다. 어떤 인증서가 반환되었는가? 그 공개 키는 요청과 일치하는가? 실제로 발급된 주체, 이름, 용도, 정책, 유효 기간은 무엇인가? 응답이 의도된 최종 주체에게 전달되었는가? 최종 바이트 없이 남겨진 상태 라벨은 발급 영수증이 아닙니다.

RFC 10004는 또 하나의 유용한 한계를 제시합니다. 어떤 구현이 명시된 CMC 준수 등급을 만족하더라도, 그것이 특정 조직이 올바르게 배포했음을 증명하지 않고, 특정 요청이 정책을 충족했음을 증명하지도 않습니다. 표준 적합성은 거래 증거가 아닙니다.

발급은 또 하나의 증거 사슬을 시작한다

발급된 인증서조차 여전히 운영상의 승인이 아닙니다. RFC 5280 경로 검증은 신뢰 앵커, 인증 경로, 이름, 정책, 제약, 유효 기간을 고려합니다. 폐지 검사는 상태와 최신성을 더합니다. 설치는 자산, 구성, 보관 상태를 더합니다. 그리고 서비스는 자체 인가 규칙을 적용합니다.

이 단계들은 갈라질 수 있습니다. CA가 올바른 인증서를 발급했지만 장치에 도달하지 않을 수 있습니다. 장치가 잘못된 개인 키 옆에 그것을 설치할 수 있습니다. 의존 주체가 경로를 거부할 수 있습니다. 유효한 경로가 응용이 인가하고 싶지 않은 신원을 인증할 수도 있습니다. 이후의 폐지가 이전에 유효했던 상태를 끝낼 수 있습니다.

Lu Heng의 러닝 코드 우선 원칙(Running-Code Primacy)이 적절한 규율을 제시합니다: 진술이 이루어진 계층에서 그 진술을 재현하는 데 필요한 증거를 보존하라는 것입니다. 등록의 경우, 그것은 요청 바이트, 증명 방법, 신원 결합, RA 행위, CA 정책, 응답을 의미합니다. 배포의 경우, 인증서 바이트, 키 일치, 설치 대상, 경로 결과, 상태 출처, 서비스 결정을 의미합니다. 하나의 대시보드 필드가 이 모든 것을 담당하면 책임 소재가 파괴됩니다.

유용한 영수증에는 최소한 열한 줄이 있습니다: 요청자와 시각; 요청된 키와 필드; POP 방법과 결과; 신원 방법과 한계; 연계 방법; RA 래퍼와 변경; CA와 정책 버전; CMC 상태; 정확한 인증서; 설치와 검증; 폐지, 교체, 정정. 각 줄은 독립적으로 실패할 수 있고, 각 줄은 다른 줄이 없었던 것처럼 가장하지 않은 채 정정될 수 있습니다.

이것이 Turner의 집단적 CMC 작업의 가치입니다. 유효한 키 증명이 인증서가 되리라고 약속하지 않습니다. 왜 그래서는 안 되는지를 보여 줄 만큼의 구조를 제공합니다.

출처