CA/B 포럼 초안은 폐기의 끝점을 공개한다. 시계는 CA 내부에서 시작된다

요약

• CA/Browser Forum의 풀 리퀘스트 622는 여전히 공개된드래프트 투표안(Draft Ballot SC-XX)이다. 최종 투표 번호가 부여되지 않았고, 표결, IPR 검토 통과, 효력 발생 모두 이루어지지 않았다.
• 현재 TLS Baseline Requirements는 인증서 문제 보고서 또는 관련 통지의 접수 시점부터 공개된 폐기까지의 기간을 측정한다. 이 제안은 먼저 CA에 보고서가실행 가능(actionable)한지 판단할 24시간을 주고, 해당 판단 시점부터 관련 폐기 기간을 시작하게 한다.
• 실행 가능성은 접수 기준선이며, CA가 규칙을 위반했다는 판정이 아니다. 동결된 초안은 최소 하나의 유효 식별자(시간상 유효하고 폐기되지 않은 인증서에 대한 것)와 기술된 정책 위반 또는 폐기 사유를 요구한다.
• 동일한 실행 가능성 타임스탬프가 CA가 발급한 다른 모든 시간상 유효한 미폐기 인증서에 대한 120시간 평가를 시작한다. 추가로 영향받은 인증서가 발견되면, 해당 인증서의 시계는 최초 식별 시점부터 새로 시작된다.
• 초안은 또한폐기됨(Revoked)을 관찰 가능한 조건으로 정의한다. 인증서에 선언된 모든 적용 가능한 CRL 및 OCSP 위치는 신뢰 당사자에게 폐기 상태를 노출해야 한다. 이는 보이지 않는 데이터베이스 플래그보다 강력하지만, 모든 캐시가 동시에 갱신된다는 보장은 아니다.
• 프라이버시 범위가 지정된 폐기 영수증은 공식 채널 접수, 실행 가능성, 실질적 판정, 대상 확대, 사유별 기한, 상태 공개에 연동되어야 한다. 보고서 본문, 유출된 키, 구독자 데이터를 공개하지 않으면서 시각, 상태 코드, 건수를 노출할 수 있다.

하나의 사고가 들어오고, 여러 시계가 흐른다

인증서 문제 보고서는 기만적으로 작은 객체로 도착할 수 있다. 이메일 하나, 양식 제출 하나, 일련번호 하나, 때로는 개인 키나 검증 방법을 더 이상 신뢰해서는 안 된다는 증거 하나. 운영상의 결과는 훨씬 클 수 있다. 잘못된 인증서 하나가 공유된 발급 결함을 드러낼 수 있다. 유출된 키 하나가 여러 인증서에 존재할 수 있다. 검증 실수는 보고자가 열거할 수 없는 대상 집단에 영향을 미칠 수 있다.

풀 리퀘스트 622는 이 혼란스러운 접수 과정을 더 명확한 순서로 바꾸려 한다. CA는 인증서 문제 보고서 접수 후 24시간 내에 실행 가능한지 판단해야 한다. 실행 가능하다면, CA는 접근 가능한 보고자에게 24시간 내에 판정 결과를 통보해야 한다. 사유별 폐기 기간은 실행 가능성 판정 시점부터 계산된다. 별도의 120시간 기간에는 CA가 동일한 비준수 사안에 대해 발급한 다른 모든 시간상 유효한 미폐기 인증서를 평가해야 한다. 점검에서 추가 영향 인증서가 발견되면, 해당 인증서의 폐기 기간은 최초 식별 시점부터 시작된다.

이것은 하나의 시계가 아니다. 시계들의 연쇄이며, 각 전달 단계는 증명해야 할 것을 바꾼다.

현재 버전 2.2.9는 더 단순한 방식을 택한다. 접수 후 24시간 내 예비 보고를 요구하고, 인증서 문제 보고서 또는 폐기 관련 통지의 접수부터 공개된 폐기까지의 기간이 4.9.1.1절의 기한을 초과하지 않아야 한다고 규정한다. 이 기한은 균일하지 않다. 개인 키 유출 증거나 신뢰할 수 없는 도메인 검증 같은 특정 사건은 24시간 내 폐기를 요구한다. 기타 나열된 상황은 24시간 SHOULD와 5일 MUST를 갖는다. 따라서 유용한 기록은 트리거 시각과 사유 등급을 모두 필요로 한다.

이 제안은 외부 시작점을 접수에서 실행 가능성으로 옮긴다. 제안 자체의 근거는 그 구간을 이득으로 제시한다. CA는 폐기 시계가 적용되기 전에 보고서에 충분한 정보가 있는지 확인할 정의된 시간을 얻는다. 합리적일 수 있다. 식별 불가능한 인증서나 이해할 수 없는 주장에 붙은 기한이 반드시 더 안전한 것은 아니다. 그러나 분류가 컴플라이언스 시계를 바꾸는 순간, 그것은 더 이상 단순한 수신함 정리가 아니다.

실행 가능은증명됨을 의미하지 않는다

초안의 기준선은 의도적으로 소박하다. 보고서에는 CA가 발급한 시간상 유효하고 폐기되지 않은 인증서에 대한 유효 식별자가 최소 하나 있어야 한다. 일련번호는 필수이며, 인증서 또는 사전 인증서의 SHA-256 지문은 SHOULD이다. 또한 보고서는 인증서가 Baseline Requirements나 CA 정책을 어떻게 위반하는지 설명하거나, 키 유출과 같은 폐기 사유를 명시해야 한다.

이 기준은 보고자가 논쟁에서 이겨야 함을 요구하지 않는다. 보고서는 실행 가능하면서도 틀릴 수 있다. 실제 인증서 하나를 식별하고 실제 조항을 인용하면서도 사실을 오해할 수 있다. CA가 영향받은 대상 집단을 확인하는 데 며칠이 필요하더라도 실행 가능할 수 있다. 풀 리퀘스트의 댓글들은 분류, 비준수 판정, 모든 시정 조치 완료를 반복적으로 구분한다.

이 구분은 양측을 보호한다. 보고자가 필수 필드를 채우는 것만으로 폐기를 명령할 권한을 얻어서는 안 된다. CA가 “실행 가능”을 “우리가 동의한다”의 동의어로 취급해 시계를 미루어서도 안 된다. 제안된 “포함하면 실행 가능한 것으로 간주한다(is considered actionable if it includes)”는 문구는 결과 기준이 아니라 입력 기준을 가리킨다.

접수 채널이 이 경계를 복잡하게 만든다. 제안은 CA의 인증서 실무 선언서(Certification Practice Statement) 1.5.2절에 명확한 안내를 요구하고, 접근 가능한 페이지, FAQ 또는 지식 기반 문서를 권고한다. CA는 실행 불가능한 양식 제출을 차단할 수 있지만, 실행 가능한 보고서를 받을 수 있어야 한다. 검토자들은 개인 키, 도메인 이름, 일련번호, 지문이 양식을 충족할지, 이메일이 필수여야 하는지, 임의 직원에게 직접 전송된 보고서는 어떻게 되는지를 논쟁했다.

그 댓글들은 규칙이 아니다. 그러나 하나의 설계 사실을 드러낸다. 접수는 공식 채널이 알려져 있을 때만 의미가 있다. 인사 담당 직원에게 이메일로 보낸 키가 그 직원에게 24시간 기술 대응 시계를 합리적으로 부과할 수 없다. 보고자가 제공할 수 있는 유일한 증거를 조용히 거부하는 보안 양식도 의미 있는 채널이 아니다. 따라서 영수증은 채널과 그것을 규율한 공개 지침의 버전을 명시해야 한다.

초안은 정지 사건을 검증 가능하게 만든다

제안의 다른 절반은 이례적으로 구체적이다.폐기됨(Revoked)의 정의를 추가한다. 인증서에 CRL Distribution Point URI가 있으면, 그 위치에서 제공되는 CRL에 인증서 일련번호가 포함되어야 한다. Authority Information Access OCSP URI가 있으면, 해당 위치에 대한 OCSP 요청이 일련번호에 대해certStatus가revoked인 응답을 반환해야 한다.

이 문구는 2021년 이후 servercert 이슈 252에서 열려 있던 질문에 답한다. 폐기는 운영자가 데이터베이스 필드를 변경하는 순간인가? 새 CRL이나 OCSP 응답의 서명인가? 오리진 서버에서의 공개인가? 아니면 신뢰 당사자가 인증서가 지정한 배포 시스템을 통해 변경된 상태를 검색할 수 있는 시점인가?

내부 비트는 외부 신뢰 판단에 충분하지 않다. 오리진을 벗어나지 않는 서명 객체도 마찬가지다. 제안된 정의는 신뢰 당사자가 실제로 조회할 수 있는 인터페이스에 완료를 위치시킨다. 두 상태 메커니즘이 모두 선언되었다면, 자연스러운 해석은 두 적용 조건이 모두 충족되어야 한다는 것이다.

그렇다고 배포가 즉각적인 것은 아니다. 이슈 토론은 CDN 전반의 콘텐츠 제거 또는 갱신의 어려움을 기록한다. 캐시는 유한한 기간 동안 서로 다른 뷰를 노출할 수 있다. 온디맨드 OCSP 응답기는 조회 시에만 관련 응답을 생성할 수 있다. 따라서 초안의 끝점 기준은 세계의 모든 기기가 같은 밀리초에 같은 답을 본다는 약속이 아니라, 관찰 가능한 완료 조건으로 이해하는 것이 적절하다.

이제 비대칭성이 가시화된다. 정지는 CA 외부에서 검증할 수 있다. 시작(실행 가능성 판정)은 먼저 CA 내부에서만 존재한다.

120시간 점검은 두 번째 대상 집단을 만든다

가장 강력한 추가 항목은 대상 집단 규칙일 수 있다. 실행 가능성 판정 후 120시간 내에 CA는 보고된 비준수 사안의 추가 사례에 대해 자신의 모든 시간상 유효한 미폐기 인증서를 평가해야 한다. 보고자는 전체 집단을 열거할 필요가 없다. 인증서 하나가 보고서를 실행 가능하게 만들고, 발급 데이터와 구현 이력을 통제하는 CA가 형제 인증서를 찾아야 한다.

DigiCert CNAME 검증 사고는 초안이 이를 예방했으리라 증명하지 않으면서, 왜 그것이 중요한지 보여준다. 사고 기록에 따르면 제3자가 알려진 일련번호를 제시하지 않은 채 검증 문제를 보고했다. DigiCert의 이후 보고서는 일련번호 없는 보고를 심각하게 받아들이지 못한 점을 하나의 근본 원인으로 식별했다. 또한 전체 보고서 시점에 해당 방식으로 발급된 유효 인증서 83,267건을 보고했다. 초기 단서와 영향받은 집단은 완전히 다른 객체였다.

외부인에게 모든 영향받은 인증서를 나열하도록 요구하는 규칙은 정보 우위를 뒤집을 것이다. 보고자는 종종 증상을 본다. CA는 발급 로그, 검증 방법, 계정 관계, 코드 배포 이력을 보유한다. 초안의 한 인증서 기준선과 CA 전체 점검은 발견을 가장 적임자에게 배정한다.

그러나 새로운 시계 시작점도 만든다. 120시간 기간은 접수가 아니라 실행 가능성 판정에서 시작된다. 추가 영향 인증서 각각의 폐기 기간은 CA가 최초로 식별한 시점에 시작된다. 내구성 있는 흔적이 없으면 세 가지 질문을 분리할 수 없다. 점검이 언제 시작되었는가, 시스템이 실제로 인증서를 매칭한 언제인가, 조사자가 매칭을 기록한 언제인가.

“대상 집단 검토 완료” 같은 단일 문장으로는 답할 수 없다. 증명에는 시작 집단 정의, 방법 또는 쿼리 버전, 시작·완료 시각, 검사 건수, 신규 식별 건수, 예외 등급, 후속 정정이 필요하다. 쿼리나 고객 목록을 공개할 필요는 없다. 다만 새로 발견된 배치가 원래의 120시간 검색 범위 안에 있었다는 사실이 마치 없었던 것처럼 보이지 않도록 해야 한다.

더 나은 보고서가 약한 보고서의 소멸 허가가 되어서는 안 된다

초안은 부분적으로 보고 마찰에서 비롯되었다. DigiCert 사고는 초기에 제공되지 않은 알려진 일련번호를 포함했다. SSL.com에 대한 Mozilla Bugzilla 불만은 이메일에서 양식으로의 전환과 양식의 “thumbprint” 입력의 불명확성을 기술했고, 그 버그는 최종적으로INVALID로 해결되었다. 별도의 GoDaddy 스레드는 공식 주소가 유출된 키 자료를 담은 아카이브 첨부 파일을 거부했다고 기술했으며, 그 이슈는FIXED로 해결되었다.

이 기록들은 하나의 보편적 채널 설계를 입증하지 않는다. 이메일 첨부는 정당한 보안 사유로 필터링될 수 있다. 양식은 스팸과 무관한 지원 문의를 거부할 수 있다. 평문 개인 키는 특별한 처리가 필요하다. 보고자가 틀릴 수도 있다. 제안이 모든 메시지를 폐기 명령으로 바꾸지 않는 것은 옳다.

위험은 다른 곳에 있다. 품질 기준선이 소멸 메커니즘이 될 수 있다는 점이다. 동결된 초안은 일반적으로 보고서에 필드가 하나 부족하면, 실행 불가능 판정 후 24시간 내에 연락처가 존재하는 경우 무엇이 빠졌는지 요청하도록 규정한다. 보고자가 나중에 누락 자료를 제공하면, 그 자료의 접수가 이후 타임라인의 기준이 된다.

그 전환은 서로 무관한 두 수신함 항목이 아니라 하나의 케이스로 유지되어야 한다. 보고서 식별자는 접수에서 실행 불가능, 보완, 실행 가능으로 이동하는 동안 유지되어야 한다. 그렇지 않으면 CA는 경과된 여정을 잃으면서 각 국소 단계를 충족할 수 있다. 보고자가 월요일에 상세한 주장을 보내고 금요일에 일련번호를 제공하면, 공개 기록은 마치 월요일이 없었던 것처럼 금요일에 시작된다. 제안에 따라 폐기 기한이 금요일에 합법적으로 시작될 수 있다. 그럼에도 이력은 그 이유를 보여주어야 한다.

폐기 영수증은 좁게 유지될 수 있다

필요한 아티팩트는 사고 증거의 공개 덤프가 아니다. 초안이 이미 만드는 상태들 간의 연결(join)이다.

공개 계층은 타임스탬프, 건수, 상태 코드를 공시할 수 있다. 조기 공개가 구독자나 조사에 피해를 줄 때 인증서 식별자는 해시 처리되거나 지연될 수 있다. 평문 개인 키, 보고서 본문, 계정 기록, 내부 탐지 쿼리, 보안 민감 양식 제어는 공개되어서는 안 된다. 감사인이나 루트 프로그램은 공개 세부 정보가 위험할 때 보호 계층을 검사할 수 있다.

여기서 Lu Heng의 현실 계층 구분이 유한한 방식으로 유용하다. 그것은 Web PKI 교리가 아니며 CA/B 포럼 정책을 결정하지 않는다. 하나의 규율을 제공한다. 상태의 이름은 그 상태에 결과를 부여하는 실행 가능한 사건과 연결되어야 한다.실행 가능은 시계를 바꾼다.폐기됨은 신뢰 당사자가 받아들일 수 있는 것을 바꾼다. 그 라벨들은 신화가 아니라 타임스탬프와 관찰을 받을 자격이 있다.

초안의 날짜는 효력 발생일이 아니다

연구 기준 시점에 풀 리퀘스트 622는 공개되어 있었다. 제목은 여전히SC-XX였다. 포럼 사이트에서 이용 가능한 최신 SCWG 회의록은 이 작업을 Draft Ballots 아래 두고, 기안자가 진전시키기 전에 미해결 댓글을 다룰 의향이 있다고 밝혔다. 동결된 브랜치는 2026년 9월 15일 제안 날짜를 포함했지만, 그것은 버전 2.2.2 스냅샷에 기반했고 현재main은 버전 2.2.9였다.

따라서 그 날짜는 의무가 아니라 수정·모니터링할 필드이다. 확인된 증거는 공식 토론 기간, 투표 지지자, 표결 결과, IPR 검토, 병합된 지침, 루트 프로그램 시행을 보여주지 않는다. Baseline Requirements 자체가 마지막 경계를 명시한다. 신뢰 당사자 애플리케이션 소프트웨어 공급자가 채택하고 시행하기 전까지는 CA에 강제적이지 않다.

이것이 초안의 중요성을 줄이지는 않는다. 정확한 상태 언어를 필수로 만들 뿐이다. 공개된 풀 리퀘스트는 검토를 통해 개선될 수 있다. 투표안은 날짜를 바꾸고 현재 main을 병합할 수 있다. 최종 지침은 효력 발생일을 얻을 수 있다. 이후 루트 프로그램이 시행을 명시할 수 있다. 각 전환은 서로 다른 질문에 답한다.

제안은 자신의 시계 양 끝을 모두 노출할 수 있다

풀 리퀘스트 622는 두 가지 실제 문제를 해결한다. 외부인이 전체 영향 집단을 알 필요 없이 문제 보고서에 최소 형태를 부여한다. 폐기에 보이지 않는 행정적 의미가 아니라 신뢰 당사자가 볼 수 있는 종료 조건을 부여한다.

남은 거버넌스 결함은 수리 가능하다. 검사 대상 행위자가 주 시계를 시작하는 타임스탬프를 만들고, 외부 세계는 끝만 검증할 수 있다. 영수증은 그 판정을 보고자에게 이전할 필요가 없다. 판정을 귀속 가능하게 만들면 된다.

제안의 가장 강력한 버전은 공식 채널 접수와 실행 가능성 시각을 공개하고, 보완된 보고서의 계보를 보존하며, 대상 집단 점검을 기록하고, 각 사유별 기한을 그것을 닫는 상태 끝점에 바인딩할 것이다. CA는 여전히 실질 판단으로 주장을 거부할 수 있다. 기밀 증거를 보호할 수 있다. 적용 기한 내에 피해를 줄이기 위해 교체를 조율할 수 있다.

불가능한 것은 시작이 기관 내부에서 소멸하면서, 외부적으로 가시적인 끝이 전 구간이 통제되었다는 증거로 제시되는 것이다.

증거의 한계

어떤 인용 출처도 이 제안 하에서 CA가 실행 가능성 타임스탬프를 조작했다는 것을 보여주지 않는다. 제안은 아직 효력이 없다. 어떤 출처도 공개 영수증이 DigiCert, SSL.com, GoDaddy의 보고 문제를 예방했으리라 증명하지 않는다. 사고 스레드는 사실과 결과가 다르며, SSL.com 이슈는INVALID로 해결되었다.

동결된 PR에는 문구 결함과 오래된 브랜치 기반이 있다. 공식 토론 전에 변경될 수 있다. 본 기사는 명시된 기준 시점의 정확한 헤드를 평가하며 최종 투표 문구를 예측하지 않는다. 모든 CRL과 OCSP 캐시가 즉시 일치할 것, 모든 보고자가 공시를 받을 자격이 있을 것, 실행 가능성이 비준수를 확립할 것을 주장하지 않는다.

입증된 점은 더 좁다. 초안은 실질적 상태 전환을 만들고 폐기 구간의 한 끝을 외부 관찰 가능하게 만든다. 최소한의 기록은 보고서 자체를 공개하지 않으면서 다른 끝도 감사 가능할 만큼 관찰 가능하게 만들 수 있다.

출처

1. Lu Heng, “On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile”
2. CA/Browser Forum servercert 풀 리퀘스트 622
3. 동결 헤드ef1dda7b…기준 제안된 Baseline Requirements
4. 동결된main커밋5c13e270…기준 현재 Baseline Requirements
5. servercert 이슈 252: 폐기의 의미 명확화
6. Mozilla Bugzilla 1910322: DigiCert CNAME 검증 사고
7. Mozilla Bugzilla 1942270: SSL.com 보고 메커니즘 불만
8. Mozilla Bugzilla 1942241: GoDaddy 첨부 파일 불만
9. SCWG 회의록, 2026년 8월 13일
10. Server Certificate Working Group 헌장
11. CA/Browser Forum 운영규정