요약

  • RFC 9810은accepted와grantedWithMods에 서로 다른 의미를 부여한다. 전자는 요청자가 요청한 것을 정확히 받았다는 뜻이고, 후자는 유사한 무언가를 받았으며 그 차이를 스스로 확인할 책임이 요청자에게 있다는 뜻이다.
  • 인증된 CMP 응답은 트랜잭션의 출처와 연속성을 증명할 수 있지만, 주체 이름, 유효 기간, Key Usage, Extended Key Usage, 제약 조건, 정책 또는 공개 상태가 여전히 요청자의 승인된 의도와 일치함을 증명하지는 못한다.
  • 로컬 인증서 의도 영수증(certificate-intent receipt)은 요청, 발급된 인증서, 필드 수준의 델타, 각 중요 변경에 대한 권한 근거, 수용 또는 거부 결정을 결합하면서도 개인 키를 보존하거나 공개 인증서 도시즈를 만들지 않도록 할 수 있다. 이는 Daniel Kade의 편집 제안이며 RFC의 필드가 아니다.

위험한 인터페이스는 흔히 초록색 행이다. 등록 클라이언트가 보호된 요청을 보냈고, 인식된 CA가 보호된 응답을 돌려주었다. 인증서는 파싱되고, 서명은 검증되며, 워크플로우는 트랜잭션을 완료로 표시한다. 인터페이스가 두 가지 긍정적 CMP 상태를 모두 "성공"으로 압축한다면, RFC 9810이 요청자에게 검토를 요구하는 그 차이를 폐기하는 셈이다.

이 표준은 이례적으로 직설적이다. 상태 정의에서accepted는 요청자가 요청한 것을 정확히 받았음을 의미한다.grantedWithMods는 요청한 것과 비슷한 무언가를 받았으며, 그 차이를 확인할 책임이 요청자에게 있음을 의미한다. RFC 9810은 다른 곳에서도, 발기인이 원하는 인증서를 완전히 명시했더라도 CA는 실제로 발급하는 인증서의 필드를 자유롭게 변경할 수 있다고 말한다. 결과가 수용 불가능하다면, 요청자는 인증서 확인(certificate confirmation)을 통해 이를 거부해야 한다.

이러한 내용이grantedWithMods를 오류로 만들지는 않는다. CA는 식별 이름을 정규화하거나, 유효 기간을 상한 제한하거나, 발급자가 선택한 일련번호를 삽입하거나, 정책 식별자를 적용하거나, Key Usage를 제한하거나, 지원하지 않는 확장을 거부하거나, 승인된 프로필에 따라 주체 대체 이름을 구성하는 데 타당한 이유를 가질 수 있다. 거버넌스 문제는 기술적으로 유효한 변경이 발급과 사용 사이에서 보이지 않게 될 때 나타난다.

상태는 판정이 아니라 갈림길이다

RFC 9810은 2025년 7월 IETF Standards Track으로 공표되었으며, X.509 인증서를 생성하고 관리하기 위한 Certificate Management Protocol을 통합한다. 이 문서는 최종 개체(end 주체)와 등록 기관(Registration Authority), 인증 기관(Certification Authority) 같은 PKI 구성 요소 간의 교환을 정의한다. RFC 4210을 대체하며, RFC 9811과 함께 RFC 9480도 대체한다. 문서는 KEM 관련 지원을 추가하고 암호화된 자료를 CMS EnvelopedData 쪽으로 옮기지만, 그 거버넌스적 가치는 더 오래되고 더 근본적이다. 요청, 발급, 확인을 별개의 행위로 유지한다는 점이다.

요청자는CertTemplate을 통해 원하는 인증서 내용을 표현한다. 이 구조는 X.509 인증서의 서명 예정 부분과 유사하며, 그 필드들은 선택적이거나 상황에 따라 달라진다. 템플릿은 공개 키, 주체, 유효 기간, 확장을 지정할 수 있다. 요청자는 등록 전에 인증서 요청 청사진을 먼저 요청하여 CA가 무엇을 기대하는지 알 수도 있다.

그러나 그 템플릿은 발급자를 구속하는 주문이 아니다. CA는 자신이 서명하는 것에 대해 계속 책임을 진다. CA의 정책은 필드를 공급, 제거 또는 변경하도록 요구할 수 있다. 따라서 CMP는 모든 성공적인 발급이 요청을 바이트 단위로 재현한다고 약속할 수 없다. 대신 두 가지 긍정적 결과를 노출한다.

이 설계는 정직하다. 이진 성공 플래그는 매우 다른 사건들을 하나의 범주로 몰아넣을 것이다. 정확한 이행과 정책에 따라 형성된 이행은 모두 성공적인 프로토콜 응답이지만, 동일한 결정은 아니다.grantedWithMods는 갈림길이다. 수용 여부를 판단할 권한을 다시 요청자에게 돌려준다.

그 갈림길을 초록으로 칠하고 즉시 인증서를 설치하는 관리 시스템은 그 판단을 조용히 인터페이스 코드에 넘겨준 것이다. 거버넌스를 없앤 것이 아니라, 변경된 범위를 누가 승인했는지 보존하지 않은 채 기본값이 결정을 내리도록 허용한 것이다.

차이는 권한을 바꿀 수 있다

비교는 두 양식 사이의 외견적 diff가 아니다. RFC 5280은 서명된 인증서 본체를 정의한다. 버전, 일련번호, 서명 알고리즘, 발급자, 유효 기간, 주체, 주체 공개 키 정보, 확장이다. 일부 필드는 발급자의 기계 장치이고, 다른 필드는 인증서가 누구 또는 무엇을 지명하는지, 언제 작동하는지, 그 키가 무엇을 할 수 있는지를 서술한다.

Key Usage는 디지털 서명, 키 암호화(encipherment), 키 합의, 인증서 서명, CRL 서명을 구분할 수 있다. Extended Key Usage는 하나 이상의 용도를 부착할 수 있다. Basic Constraints는 최종 개체와 인증 기관을 구분하고 인증 경로를 제한할 수 있다. 주체 대체 이름은 어떤 서비스 신원이 표현되는지를 결정할 수 있다. 인증서 정책은 의존 당사자(relying party)가 사용을 평가하는 규칙 집합을 가리킬 수 있다.

모든 델타가 동일한 무게를 지니는 것은 아니다. CA가 생성한 일련번호는 예상된 것이다. 등가 이름의 재포맷은 프로필에 따라 무해할 수 있다. 유효 기간 단축은 노출을 줄일 수 있다. 지원되지 않는 비중요(non-critical) 확장의 제거는 수용 가능할 수 있다. 그러나 CA 서명 능력을 추가하거나, 서비스 신원을 바꾸거나, EKU를 넓히거나, 공개 키를 교체하거나, critical 여부를 변경하거나, 예상 밖의 정책으로 이동하는 것은 운영 권한을 바꿀 수 있다.

RFC 9810은 이런 결과 하나를 명시적으로 다룬다. CA가 PKI 관리 역할을 위한 특정 Extended Key Usage 값을 담은 인증서를 발급하면, 원래 CA 인증서 자체에 귀속된 권한을 위임하는 것이다. RFC는 이를 민감한 행위로 규정하고, 정당한 개체만 그 EKU를 받도록 특별한 주의를 요구한다. 이런 상황에서 "수정됨"은 서체 문제가 아니다. 제도적 권력의 이전일 수 있다.

따라서 올바른 비교에는 의미론이 필요하다. 바이트 수준 해시는 두 아티팩트가 다르다는 것만 증명하고, 그 차이가 예상된 것인지 실질적인 것인지는 증명하지 않는다. 필드 수준 디코더는 유효 기간이 한 구간에서 다른 구간으로 이동했거나, EKU가 추가되었거나, SAN이 정규화되었음을 보여줄 수 있다. 그 다음 로컬 정책이 그 변경이 허용되는지, 지명된 승인자를 필요로 하는지, 새 요청을 필요로 하는지, 거부되어야 하는지를 말해야 한다.

메시지 인증은 더 좁은 명제를 증명한다

CMP는 메시지를 보호하고, 식별자·nonce·응답 관계로 그것들을 트랜잭션에 결합한다. 프로필에 따라 보호는 공유 비밀 또는 서명을 사용할 수 있다. 소유 증명(proof of possession)은 요청자가 인증 대상 공개 키에 연관된 개인 키를 통제함을 보여줄 수 있다. RA는 요청을 검증·승인하고, 추가 보호 아래 전달하거나, 정의된 메커니즘에 따라 수정할 수 있다.

이러한 통제는 중요하다. 이것이 없으면 요청자는 공격자의 개체를 자신의 요청과 비교하고 있을 수 있다. 그러나 교환의 진정성이 요청과 인증서를 의미상 동일하게 만들지는 않는다. 서명된 소포는 올바른 발신자로부터 올 수 있고, 수신자가 수용 여부를 판단해야 하는 승인된 대체를 여전히 담고 있을 수 있다.

이것이 바로 이 글이 소유 증명 이후에서 시작하는 이유이기도 하다. 개인 키를 보유했다고 해서 신원이나 모든 인증서 필드에 대한 권한이 확립되는 것은 아니다. CA의 결정으로도 사슬이 끝나지 않는다. CA는 승인된 요청과의 관계를 여전히 요청자가 평가해야 하는 서명된 개체를 만들 뿐이다.

RA는 또 하나의 경계를 만든다. RA는 원래의 보호된 요청을 그대로 전달하고 자신의 보호를 추가할 수 있다. 또한 요청을 수정하면서 선택적으로 원본 메시지를 함께 담아 CA가 무엇이 바뀌었는지 검토하도록 할 수 있다. 유용한 증거는 "RA가 관여했다"가 아니라, 어떤 값이 최종 개체에서 왔고, 어떤 값이 RA에 의해 도입 또는 정규화되었으며, 어떤 값이 CA가 서명했고, 각 실질적 변환이 어떤 권한 아래 발생했는지이다.

인증서 확인은 결정 표면이다

RFC 9810의certConf메시지는 클라이언트가 직전 응답에서 제공된 인증서를 수용하거나 거부하도록 한다. 지명된 인증서에 대해statusInfo를 생략하면 수용을 나타낸다. 해당CertStatus구조를 생략하면 거부를 나타내며, 빈 시퀀스는 모두를 거부할 수 있다. 클라이언트는 인증서 해시를 지명하고 명시적 거부 상태를 제공할 수도 있다.

이 구조는 프로토콜 정리 작업처럼 취급하기 쉽지만, 인증서가 일상적인 운영 상태가 되기 전에 요청자가 내리는 마지막 되돌릴 수 있는 결정을 담고 있다. 확인은 요청 식별자나 CA가 응답했다는 사실이 아니라, 실제 발급된 인증서에 대응해야 한다.

경량 CMP 프로필은 상태 기계를 더 명확히 한다. 긍정적 응답은accepted또는grantedWithMods일 수 있다. 암묵적 확인(implicit confirmation)이 요청되고 승인되지 않았다면, 최종 개체는certConf를 보내고 PKI 관리 개체는pkiConf로 응답하며 트랜잭션이 닫힌다. 예상된 확인이 도착하지 않으면, 프로필은 그것을 거부처럼 처리하라고 말한다.

명시적 확인은implicitConfirm으로 생략할 수 있다. 최종 개체가 별도의 확인을 보내지 않도록 요청하면, CA 또는 RA는 그 최적화를 승인할 때 확장을 되돌려준다. 이는 왕복 하나를 절약한다. 그러나 클라이언트가 검증되지 않은 인증서를 설치해도 된다는 뜻은 아니다. 수용이 전달되는 방식을 바꾸는 것이지, 발급된 개체가 로컬 정책에 따라 수용 가능해야 하는지 여부를 바꾸는 것은 아니다.

이 구분은 자동화에서 중요해진다. 기기 플릿이 암묵적 확인을 요청한다면, 그 등록 구성 요소는 요청을 보내기 전에, 혹은 되돌려진 응답을 배포 가능한 것으로 취급하기 전에 의미 비교를 완료해야 한다. 그렇지 않으면 지연 최적화가 거버넌스 지름길이 된다. 시스템이 분류하지 않은 수정을 미리 수용하기로 합의하는 것이다.

정책은 차이가 왜 정당할 수 있는지 설명한다

RFC 3647은 인증서 정책을 인증 업무 기술서(CPS)와 구분한다. 인증서 정책은 커뮤니티 또는 응용 등급에 대한 요건을 서술하고, CPS는 CA가 자신의 실무와 통제를 어떻게 구현하는지를 서술한다. 이 구분은 유용하다. CMP 상태는 발급된 모든 필드에 대한 제도적 이유를 전부 담을 수 없기 때문이다.

요청이 2년 유효 기간과 서버 인증 EKU를 요구한다고 하자. CA의 정책은 1년을 허용하고, 관리 대상 기기 프로필에 대해 서버와 클라이언트 인증을 모두 요구한다. 발급된 개체는 기술적으로 유효하고 CA의 공표된 실무를 충실히 구현하면서도, 요청자의 로컬 배포 설계와는 실질적으로 다를 수 있다. 올바른 결과는 어느 쪽이 형식에 맞는지가 아니라, 요청자가 그 프로필을 승인했는지에 달려 있다.

따라서 요청자는 발급에 사용된 프로필과 정책의 신원, 버전을 포함하여 알아야 한다. 여러 프로필이 존재한다면 "CA 정책"은 너무 넓다. 이후 검토자는 예상된 프로필 변환과, 운영자의 예외, 낡은 클라이언트 템플릿, 검토되지 않은 발급자 변경을 구분할 수 있어야 한다.

비교는 또한 요청이 모든 필드를 공급한다고 가정하지 말아야 한다. 일부 필드는 발급자가 선택하는 것이 옳다. 규율 있는 영수증은 그것들을 의심스러운 차이로 보고하지 않고, 발급자 소유로 라벨링한다. 목적은 바이트 동일성을 요구하는 것이 아니라, 결정 권한의 배분을 명시적으로 만드는 것이다.

공개는 관찰이지 수용이 아니다

Certificate Transparency는 발급을 관찰 가능하게 만들 수 있다. RFC 9162는 append-only 로그를 서술하며, 관심 있는 당사자가 CA 활동을 감사하고 의심스러운 인증서를 알아차리도록 한다. 또한 한계를 명시한다. 로그 자체는 잘못된 발급(misissuance)을 막지 못한다. CT 항목은 인증서 또는 예비 인증서(precertificate)가 프로토콜의 규칙 아래 기록되었음을 증명할 수 있다. 그러나 요청자가 인증서를 수용했다는 것, 인증서가 로컬 의도와 일치한다는 것, 배포가 승인되었다는 것은 증명할 수 없다.

RFC 9810은 간접 소유 증명에 대해 특히 날카로운 순서 규칙을 노출한다. 그 방법을 사용하는 CA는, 인증서 해시를 담고 증명을 완성하는certConf를 받기 전에는 최종 인증서를 CT에 공개해서는 안 된다. 예비 인증서는 동일한 위험을 만들지 않는다. 이 순서는 "발급됨", "확인됨", "공개됨"이 하나의 타임스탬프로 압축될 수 없는 이유를 보여준다.

그 POP 사례를 벗어나더라도, 공개는 별개의 상태로 남아야 한다. 인증서는 로그에 나타난 뒤 로컬에서 거부될 수 있다. 수용되었지만 설치되지 않을 수도 있다. 한 서비스에 배포되고 다른 서비스는 그것을 거부할 수도 있다. 자동화가 이미 전파한 뒤에야 실질적 차이가 발견되어 폐기와 재발급이 필요할 수도 있다.

따라서 거버넌스 기록은 CA의 응답 이후 단계가 모두 CA에 귀속된다고 주장하지 않으면서 개체를 따라가야 한다. 수용은 요청자가 통제한다. 배포는 서비스 소유자가 통제한다. 의존 당사자는 자신의 경로 검증과 응용 정책을 적용한다. CT 모니터는 발급을 관찰한다. 이 행위자들은 연결되어 있지만 서로 바꿔 쓸 수는 없다.

인증서 의도 영수증은 델타 검토를 가능하게 한다

제안된인증서 의도 영수증은 보호된 요청,CertTemplate, 적용 가능한 프로필, 반환된 인증서의 정규화된 신원에서 시작한다. 공유 비밀, 개인 키, 복호화된 중앙 키 패키지 또는 불필요한 주체 증거를 저장하지 않으면서 CMP 트랜잭션과 응답 상태를 기록한다.

이어서 정규화된 비교를 제시한다. 발급자 소유의 예상 값은 그렇게 식별된다. 요청자 소유의 값은 필드별로 비교된다. 실질적 필드에는 공개 키, 주체 및 주체 대체 이름, 유효 기간, Key Usage, Extended Key Usage, Basic Constraints, 인증서 정책, 관련 경우의 이름 제약, critical 여부, 그리고 응용이 의존하는 모든 확장이 포함된다. 알 수 없는 critical 확장은 fail closed로 처리한다. 허용된 정규화는 그것을 허용하는 규칙을 인용한다.

모든 실질적 차이에는 처분(disposition)이 부여된다. 프로필상 예상됨, 승인된 역할에 의해 수용됨, 거부됨, 또는 미해결. 영수증은 누가 그 결정을 행사했는지, 이 서비스 또는 기기 등급에 대해 어떤 권한을 가졌는지, 평가에 사용된 소프트웨어와 정책 버전, 확인이 명시적이었는지 암묵적이었는지를 기록한다. 인증서의 수용은 공개 또는 배포 권한과 분리하여 유지된다.

마지막으로 공개와 배포 상태, 예외 만료, 롤백 대상, 필요 시 폐기 또는 재발급, 수정 이력을 기록한다. 수정된 영수증은 이전 결정을 덮어쓰지 않는다. 대체되는 상태를 링크하여 검토자가 시점마다 시스템이 무엇을 믿었는지 이해할 수 있게 한다.

이 기록은 접근이 통제되고 최소화되어야 한다. 일부 인증서가 공개적이라는 이유만으로 공개 페이지에 있어서는 안 된다. 내부 주체 이름, 기기 식별자, 프로필 예외, 등록 메타데이터는 민감한 자산 목록을 노출할 수 있다. 공개 TLS의 경우 CT가 이미 의도적으로 범위를 한정한 공개 관찰 계층을 제공한다. 영수증은 로컬 결정 계보를 공급한다.

실행 코드는 프로토콜이 이미 만든 구분을 보존해야 한다

Lu Heng의 명세, 국지적 미래 결정, 자발적 채택, 실행, 관찰된 결과의 구분은 여기서 특히 유용하다. RFC 9810은 수정을 인정하는 어휘를 명세한다. CA는 로컬 발급 결정을 내린다. 요청자는 수용 여부를 결정한다. 운영자는 배포 여부와 위치를 결정한다. 의존 당사자는 관찰된 결과를 만든다. 어떤 이전 계층도 이후 계층 전체를 증명할 수 없다.

실행 코드 우위(running-code primacy)는 등록 클라이언트가 설치한 것이 곧 정당해진다는 뜻이 아니다. 실제 전이가 명시된 규칙에 대해 검증 가능할 만큼 충분히 보여야 한다는 뜻이다. 클라이언트가accepted와grantedWithMods를 하나의 불리언으로 만든다면, 구현은 프로토콜이 제공한 거버넌스 정보를 버린 것이다.

Policy Mirror는 보완적인 경고를 준다. 정책 언어는 의도된 통제를 서술하는 동안 운영은 다른 일을 할 수 있다. 프로필이 필드 검토를 요구하는 동안 플릿 관리자는 모든 긍정적 응답을 자동 설치할 수 있다. BTW의 현실 계층은 실패를 발명하지 않으면서 그 차이를 보고해야 한다. 질문은 검사 가능하다. 구현된 워크플로우가 델타를 보존했는지, 올바른 정책을 적용했는지, 배포 전에 승인된 처분을 기록했는지.

결론은 CA가 요청 수정을 멈추라는 것이 아니다. 명시적 인간 승인이 모든 인증서를 막아야 한다는 것도 아니다. 안전한 자동화는 수동 검토보다 빠르고 일관될 수 있다. 필요한 것은 실제 결정을 자동화하는 것이다. 요청된 권한과 발급된 권한을 비교하고, 모든 실질적 차이를 분류하고, 수용할 자격이 누구에게 있었는지 보존하는 것.

초록 응답은 프로토콜 교환을 끝낼 수 있다. 그것만으로 새 자격 증명이 무엇이 될 수 있는지를 결정할 수는 없다.

출처