요약

  • SC100은 참여한 인증서 발급 기관 22표와 인증서 소비 측 3표의 찬성으로 통과했으며, 반대표와 기권은 없었다. 지식재산권(IPR) 검토는 2026년 9월 5일 종료 예정이고, 이 글의 8월 31일 기준 시점에는 현행 TLS 베이스라인 요구사항에 아직 포함되지 않았다.
  • 초안은 기존 DNSSEC 규칙을 통합한다. 좁은 이메일 방식 예외를 조건으로 하여 관련 도메인 통제 및 CAA 질의에 대해 프라이머리 네트워크 퍼스펙티브에서 검증을 요구하며, 원격 네트워크 퍼스펙티브의 DNSSEC은 선택 사항으로 남는다.
  • MPIC(다중 퍼스펙티브 발행 입증, Multi-Perspective Issuance Corroboration)는 이 비대칭과 무관하다. 원격 관찰은 프라이머리 판단을 입증하며, 규칙이 그 원격에 DNSSEC을 의무화하지 않아도 MPIC 절차에서 집계될 수 있다.
  • 초안은 DNS 조회 전체 집합을 지정된 로깅 및 자체 감사 범위에서 제외하면서도 충분한 보관 증거를 요구하므로, 유용한 기록은 시간 경계가 있는 리졸버 통제 영수증을, 프라이머리 퍼스펙티브를 명명하고 각 원격별 DNSSEC을 별도로 기록하는 발행 영수증과 결합해야 한다.

두 문서가 2.2.9를 말하더라도 동일한 지위를 갖는 것은 아니다

공식 SC100 페이지는 이례적으로 깨끗한 표결을 기록하고 있다. 참여한 인증서 발급 기관 22곳이 찬성했다. Apple, Cisco Systems, Mozilla가 인증서 소비 측 찬성 3표를 냈다. 반대표와 기권은 없었으며, 기록된 정족수 15도 충족되었다.

이는 채택 절차의 끝이 아니라 표결 결과일 뿐이다. 같은 페이지에 따르면 지식재산권 검토는 8월 6일 19:00 UTC에 시작해 9월 5일 19:00 UTC에 종료 예정이다. 기준 시점에 회원들은 배제 통지를 제출할 시간이 아직 있었다. 8월 13일워킹그룹 회의록역시 SC100이 최근 지식재산권 검토에 들어갔다고 기술했다.

이 지위를 잘못 읽기 쉬운 이유는 수정이 수용된 첨부문서가 8월 6일자 버전 2.2.9로 표기되어 있기 때문이다.현행 요구사항 페이지역시 공개된 TLS 베이스라인 요구사항을 8월 6일자 버전 2.2.9로 식별한다. 그러나 현행 개정 이력표는 SC101에서 끝난다. SC100은 공개된 개정판으로 등재되어 있지 않다. 포럼의문서 색인과 투표의 검토 공지가 필요한 구분을 제공한다. 하나의 2.2.9는 현행 최종 지침이고, 다른 하나는 검토용으로 생성된 완전한 초안 유지보수 지침이다.

이것은 사무적 잔설이 아니다. 컴플라이언스 서술은 머리글에 인쇄된 번호만이 아니라 문서 상태를 식별해야 한다. '버전 2.2.9'만으로는 화자가 현행 공개본을 뜻하는지, SC100 수용 초안을 뜻하는지, 아니면 그것을 통합할지 모르는 이후 공개본을 뜻하는지 검토자가 알 수 없다.

투표는 또 다른 제약을 제공한다. SC100은 명확화와 통합을 목적으로 하며 기존 요구사항을 수정할 의도가 없어서 발효일이 없다고 명시한다. 따라서 본 글은 새로운 통제를 선언하지 않는다. 어떤 증거가 명확화된 통제를 검증 가능하게 만드는지 묻는다.

필수 행위는 'DNSSEC'이라는 단어가 아니라 역할에 귀속된다

근본 의무는SC085v2에서 왔다. 2026년 3월 15일부터 프라이머리 네트워크 퍼스펙티브에서 수행되는 관련 도메인 통제 및 CAA 질의는 체인이 존재할 때 DNSSEC 검증을 거쳐야 한다. 현행 2.2.9는 그 요구를 여러 곳에 담고 있다.

SC100은 이를 제안된 §4.2.2.2로 통합한다. 초안의 깨끗한초안 PDF는 먼저 프라이머리 네트워크 퍼스펙티브가 사용하는 리졸버를 기술한다. 그 리졸버는 RFC 4035 §5에 따라 검증을 수행하고, NSEC3와 SHA-2를 지원하며, RFC 6840 §4가 지적한 보안 이슈를 처리해야 한다.

이어지는 하위 조항들이 행위를 배분한다. 프라이머리 네트워크 퍼스펙티브는 도메인 인가·통제 및 CAA 처리와 관련된 모든 DNS 질의에 대해 DNSSEC 검증을 수행해야 한다. 이메일 기반 검증 방식에는 부분 예외가 있다. 인가 도메인 명(Authorization Domain Name)을 얻기 위한 CNAME, CAA, TXT 질의는 여전히 의무이며, 나머지 질의에는SHOULD표현이 적용된다. 다른 방식과 CAA에 대해서는 로컬 정책이 검증을 비활성화할 수 없다. 프라이머리 퍼스펙티브에서 관찰된 DNSSEC 오류 —SERVFAIL이 그 예시다 — 는 명시된 예외 경계 내에서도 발행 허가로 취급될 수 없다.

원격 규칙은 다르다. MPIC에 사용되는 원격 네트워크 퍼스펙티브는 IANA 루트 신뢰 앵커까지 DNSSEC 검증을 수행할 수 있다.MAY는MUST가 아니지만MUST NOT도 아니다. 초안은 원격 검증을 결함이 있거나 불필요하거나 금지된 것으로 선언하지 않는다. 최소 의무 통제를 프라이머리 역할에 두면서 CA가 원격 암호화 검증을 추가하도록 허용한다.

이 역할 배정이 실제 증거 경계다.dnssec_status=secure를 담은 데이터베이스 행은 그 상태를 만들어낸 네트워크 퍼스펙티브를 식별하지 않으면 거의 아무것도 증명하지 못한다. 동일한 프로토콜을 사용했다는 이유만으로 원격의 적합한 결과가 결여된 프라이머리 결과를 대체할 수 없다. 마찬가지로 프라이머리 결과를 원격에 복사해 각 퍼스펙티브가 독립적인 DNSSEC 판단을 했던 것처럼 제시할 수 없다.

MPIC은 독립적 관찰을 더할 뿐, DNSSEC 의무(MUST)를 곱하지 않는다

SC067v3 투표는 도메인 검증에 대한 동일 수준의 정밀 BGP 공격을 더 어렵게 만들기 위해 MPIC을 도입했다. 현행 §3.2.2.9는 그 절차를 인증서 발행 전에 원격 네트워크 퍼스펙티브에서 프라이머리 네트워크 퍼스펙티브의 도메인 검증 및 CAA 판단을 입증하는 것으로 기술한다.

두 통제는 서로 다른 지점을 보호한다.

DNSSEC은 리졸버가 프로토콜의 신뢰 모델 하에서 인증 부존재(authenticated denial of existence)를 포함해 DNS 데이터의 암호화 체인을 검증할 수 있는지를 묻는다.RFC 4035는 리졸버에 익숙한Secure,Insecure,Bogus,Indeterminate범주를 부여한다. 이 라벨들은 검증 상태를 기술할 뿐 CA의 발행 방식, 관찰 역할, 최종 결정을 식별하지 않는다.

MPIC은 충분히 구별되는 원격 관찰이 프라이머리 퍼스펙티브가 본 것을 입증하는지를 묻는다. SC100 초안은 단계적 시행 일정을 재현한다. 2026년 6월 15일부터 해당 검증은 최소 네 개의 원격 퍼스펙티브를 사용하고, 정족수 표를 충족해야 하며, 최소 두 개의 RIR 서비스 지역에 걸쳐 입증을 확보해야 한다. 12월 15일부터 최소치는 다섯이 된다. 이들은 원격 관찰 수이지 의무적인 DNSSEC 검증기 수가 아니다.

따라서 원격 퍼스펙티브는 베이스라인 요구사항이 그 원격에 DNSSEC 검증을 의무화하지 않아도 입증적 챌린지나 CAA 결과를 보고할 수 있다. CA는 거기서 DNSSEC을 검증하고 더 풍부한 상태를 기록할 수도 있다. 두 경우 모두 초안에 부합할 수 있다. 증거는 어느 쪽이 발생했는지 말해야 한다.

두 통제를 붕괴시키면 두 가지 나쁜 추론이 나온다. 하나는 유효한 MPIC 정족수가 모든 관찰이 DNSSEC 검증되었음을 증명한다는 것이다. 다른 하나는 선택적인 원격 DNSSEC이 MPIC 정족수를 공허하게 만든다는 것이다. 어느 쪽도 텍스트에서 따르지 않는다. 지리적·네트워크 다양성이 암호화 검증이 되는 것도, 암호화 검증이 지리적 다양성이 되는 것도 아니다.

포럼은 로깅 구현을 의도적으로 열어두었다

증거 문제는 우연히 온 것이 아니다.SC096은 DNSSEC 검증을 광범위한 DCV·CAA 로깅에서 분리했다. 그 요약은 리졸버가 광범위한 로깅을 위해 설계되지 않았다고 밝히고, 적절한 통제가 작동 중임을 보이는 방법으로 변경관리 기록을 지적했다.

SC100의 제안된 §4.2.2.2.7은 배제를 유지한다. DNSSEC 검증과 관련된 DNS 조회 정보 전체 집합은 §8.7 자체 감사와 §5.4.1 로깅의 범위 밖으로 남는다. 그리고 중요한 문장을 추가한다. 이 배제에도 불구하고 CA는 DNSSEC 절의 나머지에 대한 컴플라이언스를 검증할 수 있을 만큼 충분한 정보를 보존해야 한다.

7월 16일 회의록은 설계 결정을 기록한다. 남은 쟁점은 특정 로깅을 규정할지 여부였다. 참여자들은 보관 방식의 유연성을 유지하면서 충분한 증거를 선호했다. 수정된 문안이 논의를 재개했고,7월 30일 회의록은 이후 투표 전에 추가 의견이 없었다고 기록했다.

합리적인 표준 선택이다. 규범 문서가 모든 CA에 동일한 리졸버나 저장 아키텍처를 강제해서는 안 된다. 그러나 유연성은 일을 증거 설계자에게 넘긴다. 초안이 의도적으로 제외한 전체 DNS 전송을 재현하지 않으면서 역할별 통제를 증명하는 최소 기록은 무엇인가?

한 영수증은 통제를, 다른 영수증은 발행을 기술한다

답은 '모든 것을 기록하라'가 아니어야 한다. 두 영수증 사이의 경계가 있는 결합이어야 한다.

통제 영수증(control receipt)은 정의된 구간 동안의 리졸버와 프라이머리 퍼스펙티브 구성을 기술한다. 최소한 다음을 보존해야 한다:

control receipt ID + Primary perspective ID + resolver/service ID + software/build + configuration or policy hash + trust-anchor set/version + RFC 4035 validation state + NSEC3/SHA-2/RFC 6840 capability references + local-policy exception state + test-run IDs + valid-from/valid-to + approved change record

이 영수증은 비밀이나 완전한 구성을 노출하는 대신 해시와 통제된 참조를 사용할 수 있다. 그 목적은 'DNSSEC이 활성화되었다'는 일반적 주장을 시간 경계가 있고 귀속 가능한 통제 상태로 바꾸는 것이다. 변경관리 증거가 여기서 가치를 가진다. 운영자가 무엇을 승인했고 리졸버 릴리스에 어떤 테스트가 결부되었는지 증명하기 때문이다.

발행 영수증(issuance receipt)은 한 번의 검증 시도에 대해 무엇이 일어났는지 기술한다. 다음을 결합해야 한다:

attempt and certificate/precertificate ID + request and decision time + requested name and validation scope + validation method + CAA scope + governing BR/draft version + Primary perspective ID + resolver/control-receipt ID + query families + DNSSEC state + error/fail-closed decision + remote perspective IDs + per-remote DNSSEC-performed flag and state + RIR-region references + MPIC observations/quorum + retry lineage + immutable record hash

가장 중요한 필드는 가장 긴 것이 아니다.Primary perspective ID와 원격별DNSSEC performed플래그다. 첫째가 없으면 secure 상태는 규범적 역할이 없다. 둘째가 없으면 침묵이 모호해진다. 선택적 검증이 수행되지 않았거나, 결과가 유실되었거나, 데이터 모델이 그 선택을 표현하지 않았다는 뜻일 수 있다.

원격이 DNSSEC을 수행하지 않았다면 기록은 중립적으로 그렇게 말해야 한다. 허용된 선택적 상태 하에서 수행되지 않았다는 뜻이다.Insecure를 만들어서는 안 된다.Insecure에는 프로토콜적 의미가 있다. 원격이 검증했다면 그 결과는 그 원격과 그 리졸버에 속한다. 프라이머리 결과를 편의상 원격 행에 복사해서는 안 된다.

발행 영수증에 전체 패킷, 모든 리소스 레코드, 완전한 리졸버 디버그 트레이스가 필요한 것은 아니다. 검토 대상 명제를 재구성할 만큼이면 충분하다. 필요한 프라이머리 역할이 관련 질의 집합에 대해 적합한 통제를 사용했고, 검증 오류가 발행 허가로 전환되지 않았으며, 별개의 MPIC 절차가 정족수를 충족했다는 것.

이 두 영수증 설계는 Daniel Kade의 제안이다. SC100은 이 필드들을 열거하지 않고, 본 글은 이를 DigiCert, 투표 지지자, 표결자, 감사인, RFC 에디터에 귀속시키지 않는다. 포럼은 충분성 기준을 선택했다. 영수증은 충분성을 검증 가능하게 만드는 한 가지 방법이다.

성공 플래그는 정책·실행·결정을 연결할 수 없다

네 가지 진술을 생각해 보자:

  1. CA의 CP/CPS는 DNSSEC 검증이 활성화되어 있다고 선언한다.
  2. 리졸버 구성이 적합성 테스트를 통과했다.
  3. 검증 시도가Secure를 반환했다.
  4. MPIC 정족수 이후 인증서가 발행되었다.

네 가지가 모두 참일 수 있고, 그럼에도 필요한 프라이머리 퍼스펙티브가 그 시도의 관련 질의에 대해 테스트된 구성을 사용했음을 보여주지 못할 수 있다. 빠진 정보는 결합(join)이다.

CP/CPS는 패킷 수준 관찰이 아니라 실무 선언이다. 테스트는 그 테스트 조건 하의 행동을 증명할 뿐 이후의 모든 호출을 증명하지 않는다.Secure는 DNSSEC 상태를 기술할 뿐 결과가 프라이머리 역할에서 나왔는지 말하지 않는다. 인증서는 발행 사건을 증명할 뿐 CA가 도달한 경로를 증명하지 않는다. MPIC 정족수는 입증을 기록할 뿐 각 멤버의 의무적 DNSSEC을 기록하지 않는다.

거버넌스 오류는 낯익다. 규칙의 기록이 규칙이 배정한 행위로 착각되는 것이다. SC100은 배정된 역할을 더 명확히 한다. 증거는 그 역할을 구성된 역량에서 발행 결정까지 끝까지 따라가야 한다.

공개 기록이 입증할 수 없는 것

공개 자료는 특정 CA가 이미 SC100 초안을 구현했는지, 내부 리졸버를 어떻게 조직했는지, 발행 로그에 무엇을 보존하는지 보여주지 않는다. 만장일치 표결이 배포를 증명하지 않는다. 공개된 구현 세부의 부재가 불이행을 증명하지도 않는다. 본 글은 오발행, 오염 사건, 은폐된 로그를 특정하지 않는다.

또한 공개 자료는 9월 5일 전에 배제 통지가 제출될지, 수용된 문안이 바뀔지, 이후 공개본이 어떤 버전 번호를 달지 예측할 수 없다. 정확한 지위는 그대로다. 표결 통과, 검토 진행 중, 현행 공개본 변동 없음.

출처