요약

  • SC101은 공개 신뢰 TLS 인증서에 요청된 정규화된 도메인 이름(FQDN)으로부터 인증 기관(CA)이 인가 도메인 이름(ADN, Authorization Domain Name)을 도출하는 방식을 다시 정의한다.
  • 이 투표안은 이전 정의에 대한 위험한 해석을 지적한다. 먼저 라벨을 가지치기한 다음 CNAME을 따라가는 방식은, 별칭 대상의 운영자가 실제로 통제하지 않는 이름까지 검증할 수 있게 만들 수 있다. 새로운 순서는 검증 방식을 먼저 선택하도록 하고, 두 연산이 모두 허용될 때는 CNAME 추적이 가지치기에 앞서도록 규정한다.
  • TLS Baseline Requirements v2.2.9는 2026년 8월 6일에 발효되었지만, 그 자체의 §3.2.2.4는 11월 15일까지 CA가 해당 조항 또는 v2.2.7의 대응 조항을 따를 수 있도록 허용한다. 따라서 채택이 하루아침에 하나의 운영 규칙을 만든 것은 아니다.
  • 유용한 전환 기록은 요청된 이름, 검증 방식, 적용 규칙집, 관측된 CNAME 체인, 가지치기 연산, 최종 ADN, 검증 증거, CP/CPS 버전, 구현 릴리스를 발급에 결합한다.

현행 문서에는 고의로 남겨진 레거시 경로가 있다

정책 전환은 흔히 새 문서가 자정에 옛 문서를 대체하는 것처럼 서술된다. 여기서 채택된 전환은 그렇지 않았다.현행 TLS Baseline Requirements는 2026년 8월 6일자 v2.2.9이다. 개정표는 이 변경을 SC101, 즉 “인가 도메인 이름 명확화(Clarify Authorization Domain Names)”로 돌린다. 관련 날짜표는 11월 15일을 새 도출 요구 사항의 준수 시점으로 표시한다.

결정적인 문장은 §3.2.2.4 안에 있다. 그 날짜 이전에는 CA가 현행 조항 또는 v2.2.7의 §3.2.2.4를 따를 수 있다. 11월 15일부터는 현행 조항을 사용해야 한다. 이 전환은 이행 침묵에서 추론된 비공식 유예 기간이 아니다. 채택된 규칙집에 명시된 선택이다.

이 구분이 중요하다. 어떤 CA가 9월 30일에 인증서를 발급했고 그 기록에 “현행 Baseline Requirements 준수”라고만 적혀 있다고 가정해 보자. 그 날짜 기준 v2.2.9가 현행이었으므로 이 진술은 정확하게 들린다. 그러나 운영상의 질문에는 답하지 못한다. CA는 새 알고리즘을 사용했을 수도 있고, 통합된 v2.2.7 옵션을 합법적으로 행사했을 수도 있다. 둘 다 준수일 수 있지만, 두 도출은 동일하지 않다.

제도적 사건 자체는 이례적으로 합의적이었다.SC0101v2 투표 기록은 참여한 27개 인증서 발급 기관 전원과 참여한 4개 인증서 소비자 — Apple, Google, Microsoft, Mozilla — 전원의 찬성표를 보고하며, 반대표나 기권은 없었다. 적용 정족수가 충족되었으며 정족수는 17이었다고 기록한다. 논의는 6월 12일부터 19일까지, 투표는 6월 23일부터 30일까지, 지식재산권 검토는 7월 7일부터 8월 6일까지 진행되었다.

이 사실들은 채택을 입증한다. 그러나 31개의 독립 운영 발급 시스템이 같은 날 코드, 테스트, 구성, 문서, 감사 증거를 바꿨다는 것을 입증하지는 못한다. 투표는 규범적 합의를 기록할 뿐이다. 배포는 다른 곳에서 관측되어야 한다.

검증되는 이름은 항상 요청서의 이름과 같지 않다

신청자는 하나 이상의 FQDN을 포함하는 인증서를 요청한다. CA는 승인된 검증 방식에 따라 통제를 확인해야 한다. 그 증명이 수행되는 이름이 인가 도메인 이름(ADN)이다. 때로 ADN은 신청한 이름과 동일하다. 때로는 허용된 알고리즘이 DNS 별칭을 따라가거나 가장 왼쪽 라벨을 제거하여 관련 이름에 도달한다.

이 간접 참조는 유용하다. 도메인 소유자는 승인된 방식이 더 넓은 인가 경계를 허용하는 경우, 모든 호스트에 대해 전혀 무관한 증명을 반복할 필요가 없다. 그러나 이는 동시에 보안 경계이기도 하다. 도출을 지나치게 넓히면 증명이 신청자가 통제하는 이름에서 서비스 제공자나 무관한 운영자가 통제하는 이름으로 옮겨갈 수 있다.

SC101의투표 설명에 따르면 이전 ADN 정의는 서술과 규범적 지시를 결합하고 있었다. 그 연산들을 독립적으로, 순차적으로, 반복적으로 사용할 수 있는지, 아니면 다른 조합인지가 불분명했다. 투표안은 하나의 심각한 해석을 지목한다. CA는 요청된 FQDN의 왼쪽에서 라벨을 먼저 제거한 다음 하나 이상의 CNAME 레코드를 따라갈 수 있었다.

투표안은 순서가 왜 권한을 바꾸는지 보여 주기 위해 간단한 관계를 사용한다.example.com에서example.org로의 CNAME은 트래픽이나 DNS 확인이example.org쪽으로 이동하도록 허용할 뿐이다. 그것이example.org의 운영자에게blog.example.com에 대한 통제권을 주지는 않는다. 알고리즘이 먼저blog를 가지치기한 뒤 별칭을 따라간다면, 대상에 대한 통제를 증명할 수 있는 당사자 — 예를 들어 CDN 운영자 — 는 결코 통제하지 않은 고객 서브도메인에 대한 검증을 만족하는 것처럼 보일 수 있다.

이는 안전하지 않은 해석에 대한 서술이지, 특정 CDN이나 CA가 이를 악용했다는 보고가 아니다. 그런 주장은 필요하지 않다. 규범적 정의가 실질적으로 다른 인가 경계를 지원할 수 있을 때마다 거버넌스 문제는 존재한다.

SC101은 탄력적 정의를 순서화된 절차로 바꾼다

개정된 조항은 단지 하나의 정의를 더 긴 정의로 바꾸지 않는다. 결정들을 분리하고 그 순서를 부여한다.

첫째, CA는 신청된 FQDN에서 시작해 검증 방식을 선택한다. 이 선택은 어떤 변환이 허용되는지를 제한한다. CNAME 단계를 사용할 수 있는 방식은 지정된 방식뿐이고, 가지치기 단계를 사용할 수 있는 방식도 지정된 방식뿐이다. 예컨대 언더스코어 접두 검증 이름에서 통제를 증명하는 방식은, 이름 자체에서 작동하는 방식과 동일한 별칭 자유를 자동으로 얻지 못한다.

둘째, 두 변환이 모두 허용되고 사용될 때, CA는 가장 왼쪽 라벨을 제거하기 전에 CNAME 체인을 따라간다. 이 순서는 별칭 대상에 대한 통제와 별칭 소유자 아래 모든 서브도메인에 대한 통제 사이의 차이를 보존한다. 가지치기를 먼저 사용해 이후 별칭이 인가하는 것처럼 보이는 범위를 넓힐 수는 없다.

셋째, 결과 이름이 ADN이 된다. 선택된 검증 방식이 그 ADN에 대한 통제를 입증하며, ADN은 원래 요청된 이름일 수도 있고 아닐 수도 있다. 현행 문서는 또한 인가 결과를 정의와 방식 서술에 흩어져 있게 하지 않고 하나의 표로 방식 적합성을 정리한다.

이 서술은 설명적이다. 엔지니어는 기사의 여섯 줄 요약이 아니라 완전한 규범 조항과 그 방식 표를 구현해야 한다. 그러나 순서가 거버넌스 혁신이다. 방식, 적격성, CNAME, 가지치기, ADN, 증명. 발급 시스템은 최종 성공 플래그에서 역추적하지 않고도 이 상태들을 노출할 수 있어야 한다.

이 변경은 불변의 소스 이력을 따랐다. 투표안은특정 GitHub 비교를 링크하고, 포럼의문서 페이지는 현행 및 이전 요구 사항을 보존한다. 6월 18일 워킹그룹 회의록은 v2가 다른 영향받는 조항에 별도 발효일을 추가한 이유를 기록한다. 이 기록들은 규범 문서가 어떻게 만들어졌는지를 보여 준다. 그러나 여전히 어떤 발급 엔진이 어느 분기를 실행했는지는 감사자에게 알려 주지 못한다.

영수증은 결과가 아니라 규칙집을 식별해야 한다

일반적인 검증 로그는 성공을 우선시하는 경향이 있다. 방식 완료, 챌린지 일치, 인증서 발급. 전환 로그는 경로를 보존해야 한다. 최소한으로 유용한 영수증은 다음과 같다.

발급 시각 + 신청 FQDN + 선택된 검증 방식 + BR 버전/조항 + CNAME 관측 및 체인 + 순서화된 가지치기 연산 + 선택된 ADN + 검증 증거와 시각 + CP/CPS 버전 + 구현/구성 릴리스 + 테스트 또는 감사 참조 + 예외 사항

각 필드는 서로 다른 모호성을 닫는다.

발급 시각은 어떤 전환 선택이 법적으로 가능했는지를 결정한다. 신청 FQDN과 최종 ADN은 인가가 이동했는지를 보여 준다. 검증 방식은 어떤 변환이 적격했는지 결정한다. 규칙집 필드는 v2.2.7 경로와 v2.2.9 경로를 구분한다. CNAME 관측은 몇 분 뒤라도 바뀔 수 있는 DNS 상태를 보존한다. 가지치기 기록은 연산 순서를 검사 가능하게 만든다. 증거 식별자와 시각은 지금 가져올 수 있는 것이 아니라 실제로 사용된 증명을 보여 준다. CP/CPS와 구현 버전은 선언된 관행과 배포된 코드를 분리한다. 테스트와 감사 참조는 어떤 통제가 그 행동을 검토했는지 보여 준다.

이 필드들은 내구성 있는 발급 또는 인증서 식별자에 결합되어야 한다. CA의 아키텍처가 허용하면 해시는 나중의 치환을 가시화할 수 있다. 민감한 챌린지 자료를 공개할 필요는 없다. 접근 제어와 보존 규칙이 그것을 보호할 수 있다. 요점은 최대한의 공개 로깅이 아니다. 승인된 검토자가 “현행 정책”이라는 표현이 과연 어느 버전을 뜻했는지 추측하지 않고 경로를 재현할 수 있도록 하는 것이다.

이 영수증은 분석적 제안이지, 숨겨진 SC101 요구 사항이 아니다. Baseline Requirements에는 이미 광범위한 로깅, CP/CPS, 감사 의무가 있지만, 본 기사는 그것들이 이 정확한 튜플을 요구한다고 주장하지 않는다. 묻는 것은 두 규칙집의 선택을 이해할 수 있게 만드는 데 어떤 증거가 필요한가이다.

CP/CPS 문서는 필요하지만 여전히 실행 추적은 아니다

Baseline Requirements는 CA가 인증서 정책과 인증 실무 선언서(CP/CPS)를 통해 요구 사항을 공개적으로 실현하고 그 자료를 검토하도록 요구한다. RFC 3647은 이러한 공개에 익숙한 프레임워크를 제공한다. 시의적절한 CP/CPS 업데이트는 CA가 언제 새 도출 절차를 채택할 의사인지, 어떤 시스템이 영향받는지, 예외가 어떻게 관리되는지를 밝힐 수 있다.

그 선언은 중요하지만, 발급별 추적은 아니다. 문서는 마지막 운영 노드가 배포되기 전에 갱신될 수 있다. 코드는 문서가 공개되기 전에 배포될 수 있다. 플릿은 단계적 롤아웃으로 운영될 수 있다. 긴급 롤백은 창 기간 내에 여전히 허용되는 더 오래된 구현을 복원할 수 있다. 감사자는 이 모든 상태를 넘어 표본을 채취할 수 있다.

강한 증거 체인은 세 가지 기록 — 공개된 정책, 배포된 구현, 발급별 경로 — 을 대체가 아니라 연결한다. 셋이 불일치하면 그 불일치는 설명해야 할 지적 사항이다. 정책만 남아 있다면 조사자는 무엇이 의도되었는지는 알 수 있어도 시스템이 어느 분기를 실행했는지는 알 수 없다.

포럼 채택과 신뢰 당사자 집행은 별개의 기록이다

Baseline Requirements는 스스로를 공개 신뢰 TLS 인증서에 필요하되 충분하지 않은 조건으로 소개한다. 또한 신뢰 당사자 애플리케이션 소프트웨어 공급자가 이를 채택하고 집행하기 전까지는 CA에 이 요구 사항이 강제되지 않는다고 명시한다. 이 문장은 흔한 범주 오류를 막는다. 포럼은 공통 기준선을 작성하고, 인증서 소비자가 자신의 루트 스토어가 무엇을 수용하고 정책을 어떻게 집행할지 결정한다.

Mozilla 루트 스토어 정책은 공개적 예이다. 공통 요구 사항을 통합하면서도 통제적이고 잠재적으로 더 엄격한 Mozilla 조항을 유지한다.Apple 루트 프로그램 정책도 통합된 외부 표준을 둘러싼 현행 프로그램 정책을 유지한다. 이 참조들은 계층화된 권위를 확립할 뿐, 본 기사를 어느 프로그램에 대한 평가로 만들지 않는다.

따라서 네 가지 명제가 동시에 참일 수 있다. SC101은 투표에 참여한 이들에 의해 만장일치로 채택되었다. CA는 마감 전에 통합된 v2.2.7 조항에 합법적으로 머물 수 있었다. CA 자신의 CP/CPS는 더 이른 전환을 발표할 수 있었다. 루트 프로그램은 자체 기대를 적용할 수 있었다. “투표가 통과되었다”는 한 문장으로 넷을 모두 답할 수 없다.

인접한 운영 질문 — 브라우저가 포럼 투표에서 승리하지 않고 어떻게 신뢰를 끝낼 수 있는가 — 은 별도의 분석을 요한다. 여기서는 더 좁은 질문이 먼저 온다. CA가 특정 인증서에 적용된 허용된 ADN 도출이 어느 것인지 증명할 수 있는가? 루트 프로그램의 권위는 사후에 빠진 발급 추적을 복원하지 못한다.

불확실성은 마감이 아니라 구현에 집중되어 있다

공개된 규범 상태는 충분히 명확하다. v2.2.9가 현행이고, 그 전환 조항이 대안을 명명하며, 11월 15일이 전환일이다. 공개 문서에서 남는 불확실성은 각 CA가 그 선택을 코드, 구성, 정책 문서, 로그, 테스트 피처, 감사 표본에 어떻게 매핑하는가이다.

공개 구현 공지가 없다는 이유만으로 CA를 비준수로 낙인찍는 것은 옳지 않다. 현행 BR 준수라는 일반적 주장만으로 새 알고리즘을 추론하는 것도 옳지 않다. 증거는 적절한 계층에서 획득해야 한다. 그때까지 정직한 상태는 “레거시” 또는 “갱신 완료”가 아니라 “규칙집이 입증되지 않음”이다.

출처