요약

  • 초안 풀 리퀘스트 679는 ML-DSA-44, ML-DSA-65, ML-DSA-87을 가입자·CA 인증서, CRL, OCSP 응답을 위한 TLS 베이스라인 요구사항에 추가한다. 상태 객체 예외를 둔 “순수(pure)” 키·서명 쌍도 제안한다.
  • 이 제안은 루트 스토어 신뢰를 강제하거나 Certificate Transparency 타임스탬프 서명을 바꾸지 않는다고 명시한다. 명시된 수요에는 SDK 클라이언트, 임베디드 및 IoT 시스템, 미들웨어, 시스템 트러스트 스토어에 의존하는 애플리케이션이 포함된다.
  • SCWG 헌장은 인터넷 접근 서버용 TLS 서버 인증서에 대한 작업을 승인한다. 그러나 표결권을 가진 인증서 소비자(Certificate Consumer)는 안전한 웹 브라우징을 위한 소프트웨어로 정의되고, 표결권을 가진 인증서 발급자(Certificate Issuer)는 그런 브라우저가 수용하는 인증서로 정의된다.
  • 헌장은 한쪽 범주만 명시적으로 제외한다—루트가 인증서 소비자에 의해 배포되지 않는 내부 전용 기업 PKI. 공개 문서는 실제 해석 경계를 드러낼 뿐, 모든 비브라우저 사례가 범위 밖임을 증명하지는 않는다.
  • SC-106은 9월 2일 기준 시점에 여전히 열린 초안 PR이었고 공식 투표 현황 페이지에는 없었다. 공개 댓글과 2025년 도쿄 회의록은 불일치를 보여줄 뿐, 워킹 그룹의 결정이 아니다.
  • 권한 위임 영수증은 프로필 허용이 보편적 대표성이나 배포로 오해되기 전에, 의도된 신뢰 당사자, 지배적 헌장 조항, 표결 선거구, 공통 불변 조건, 루트 스토어·CT 경계, 구현 증거, 대체 포럼, 검토 트리거를 식별해야 한다.

같은 제안에 두 선거구가 등장한다

SC-106에서 가장 계몽적인 문장은 객체 식별자가 아니다. 행동의 이유로 제시된 사용자 목록이다.

풀 리퀘스트 679는 많은 신뢰 당사자들이 기존 X.509 공개 신뢰를 통한 포스트퀀텀 인증의 실질 경로가 없다고 말한다. SDK 기반 서비스 클라이언트, 임베디드·IoT 시스템, 기업용 미들웨어, 운영체제 벤더가 관리하는 트러스트 스토어로 검증하는 애플리케이션을 명명한다. 이들은 구체적인 선거구이며 단순한 “생태계”가 아니고, 상당수는 브라우저가 아니다.

SCWG 헌장은 다른 무게중심을 쓴다. 표결권을 가진 인증서 소비자는 일반 대중이 안전하게 웹을 브라우징하도록 고안된 소프트웨어를 만들어야 한다. 표결권을 가진 인증서 발급자는 소비자 회원이 만든 브라우저가 유효하다고 간주하는 공개 접근 웹 서버용 인증서를 발급해야 한다. 투표 규칙은 발급자·소비자 표결 클래스 모두의 지지를 요구한다.

두 문서 모두 실재하는 수요를 서술할 수 있다. 문제는 그것들이 자동으로 같은 주체를 서술하는 것처럼 다뤄질 때 시작된다.

이 초안은 기기 플릿, 서버 간 클라이언트, 기업 애플리케이션에 유용할 수 있다. 브라우저로 정의된 소비자 클래스는 공개 신뢰, 인증서 처리, 이행 리스크에 대한 깊은 전문성을 가질 수 있다. 전문성은 가치 있는 증거다. 그러나 Lu Heng의 권한 위임 원칙에서 전문성과 참여는 그 자체로 누가 피영향 당사자를 위해 결정을 승인했는지를 식별하지 않는다. 표준 기구는 자신이 부수적 비웹 효용을 가진 웹 최소 기준을 세우는지, 여러 신뢰 당사자 클래스를 위한 공유 공개 신뢰 프로필을 세우는지, 아니면 표결 정의 밖의 사용자가 주로 위탁한 프로필을 세우는지 밝힐 수 있어야 한다.

SC-106은 아직 그런 제도적 영수증을 제공하지 않는다.

동결된 초안이 실제로 바꾸는 것

기술적 제안은 구체적이다. 동결된 헤드 커밋eefc670…에서 베이스라인 요구사항은 FIPS 204로 표준화된 세 개의 ML-DSA 파라미터 세트—ML-DSA-44, ML-DSA-65, ML-DSA-87—를 인정한다. 인코딩 검증, 가입자 키 용도 제약, 정확한 알고리즘 식별자를 추가한다. HashML-DSA는 금지되고 “순수(pure)” ML-DSA 형식만 허용된다.

초안은 양방향으로 인증되는 키와 인증서 서명을 결합한다. 인증서 서명이 ML-DSA가 아니라면 ML-DSA 주체 공개키가 나타날 수 없다. ML-DSA 인증서 서명은 고전적 주체 키를 인증할 수 없다. 두 번째 규칙은 CRL과 OCSP 응답에는 적용되지 않는데, 그 객체들은 공개키를 인증하지 않기 때문이다.

전문은 이 추가 사항 주위에 두 중요한 한계를 둔다. 제안 통과는 루트 스토어 운영자가 ML-DSA 계층을 수용하도록 요구하지 않는다. Certificate Transparency 로그가 SCT를 서명하는 데 쓰는 알고리즘을 대체하지도 않는다. 따라서 이 초안은 권한 허용 프로필이지 신뢰 결정도 CT 배포 명령도 아니다.

이 한계들은 양호한 제도적 위생의 신호다. 동시에 범위 문제를 더 예리하게 만든다. 루트 프로그램이 결정적 신뢰 선택을 유지하고 CT 운영자가 자체 서명·용량 선택을 유지한다면, SCWG가 명명된 각 비웹 클라이언트를 위해 제거하는 정확한 공통 장애물은 무엇인가? 그 장애물은 CA 감사 규칙인가, 루트 정책 규칙인가, 인증서 툴링인가, 경로 구축인가, 트러스트 스토어 업데이트인가, 아니면 단순히 공통 인코딩 프로필의 부재인가? 답에 따라 책임 주체가 달라진다.

이 글에서 검토한 어떤 자료도 명명된 신뢰 당사자들의 조사, 현재 BR 문서에 의해 차단된 배포 목록, 그 선거구가 SCWG에 이행 프로필 선택을 위임한다는 성명을 제공하지 않는다. 이 부재는 필요성을 반박하지 않는다. 아직 없는 증거를 정의한다.

초안은 절차적 상태이지 투표의 별명이 아니다

저장소 제목은 이 제안을 SC-106이라 부르고, 풀 리퀘스트 본문은 반복해서 투표라고 부른다. 조사 기준 시점에 공개 저장소는 여전히 초안(Draft)으로 표시했다. 커밋 하나, 공식 검토 없음, 열린 토론 스레드가 있었다. 공식 SCWG 투표 페이지는 Voting, IPR Review, Discussion, Draft, 역사적 투표 목록 어디에도 SC-106을 올리지 않았다.

범위가 제한된 결론은 단순하다: SC-106은 2026년 9월 2일 기준 초안 풀 리퀘스트였다. 이 증거는 공식 토론 기간, 지지자, 투표 기간, 결과, IPR 검토, 최종 유지보수 가이드라인, 시행일을 확립하지 않는다.

이것은 용어 이상의 문제다. 저장소 작성자는 문서를 제안할 수 있다. 워킹 그룹은 자격을 갖춘 문서를 투표 절차에 올릴 수 있다. 표결 클래스는 채택하거나 거부할 수 있다. IPR 절차는 배제를 드러낼 수 있다. 최종 가이드라인은 명시된 날짜에 요구사항을 시효시킬 수 있다. 그 후 루트 프로그램, CA, CT 시스템, 신뢰 당사자들이 각자의 권한 안에서 이행하거나 축소하거나 거부할 수 있다. 모든 초기 상태를 “투표”라고 부르면 이 모든 결정이 첫 문서로 압축된다.

문서가 내일 바뀌더라도 불변 비교는 유용하다. 그것은 정확히 하나의 초안이 제안한 것을 증명한다. 워킹 그룹이 무엇을 결정했는지는 증명할 수 없다.

헌장은 동시에 더 넓고 더 좁다

“브라우저”라는 단어만 인용해서는 깨끗한 범위 논거가 될 수 없다. SCWG 헌장 제1조는 인터넷을 통해 접근 가능한 서버를 인증하는 데 쓰이는 TLS 서버 인증서의 발급·관리 요구사항과 수용 가능한 실무를 승인한다. 새로 등장하는 온라인 보안 위협과 그 작업에 부수적인 활동에 대한 갱신도 승인한다. 그 언어는 하나의 브라우저 구현으로 한정되지 않는다.

반대 논거도 “인터넷을 통해 접근 가능한 서버”만 인용할 수 없다. 멤버십은 누가 소비자 클래스 표를 행사할 수 있는지를 정의한다. 그 정의는 명시적으로 안전한 웹 브라우징 소프트웨어에 자격을 두고 있다. 발급자 자격도 소비자 회원이 만든 브라우저의 수용으로 검증된다. 절차의 결정 선거구는 따라서 X.509 경로를 검증할 수 있는 소프트웨어 전체보다 좁다.

범위 밖 조항은 또 하나의 경계를 더한다. 루트가 인증서 소비자에 의해 배포되지 않는 경우에 한해, 내부 목적 전용 기업 PKI가 발급한 인증서를 제외한다. 코드 서명과 S/MIME 같은 여러 주요 용도도 제외한다. 이것은 모든 시스템 트러스트 스토어 클라이언트나 모든 비브라우저 TLS 사용이 금지된다는 뜻이 아니다. 헌장이 용도 클래스를 명시적으로 제외할 줄 안다는 것을 보여준다.

정직한 독해는 판결이 아니라 긴장이다. 활동 조항은 비브라우저 수혜자를 둔 공통 인터넷 TLS 프로필을 포괄할 만큼 넓게 읽힐 수 있다. 표결 정의는 이 기구가 대표하는 소비자 이익이 웹 브라우징이라는 증거로 읽힐 수 있다. 내부 PKI 제외는 일부 공개 또는 시스템 루트 비브라우저 용도를 안에 두고 다른 것을 밖에 둘 수 있다. “부수적(ancillary)”이라는 단어가 중요할 수 있으나, 주된 정당성이 다른 곳에 있는 작업의 무제한 용기가 되어서는 안 된다.

공개 해석은 어느 조항이 작동하고 누가 그 해석을 소유하는지 명명해야 한다. 침묵하면 기술 문서가 헌법적 질문을 우회적으로 결정하게 된다.

포럼은 ML-DSA 이전에 이 논쟁을 겪었다

이 불일치는 양자내성 서명과 함께 온 것이 아니다. SCWG의 2025년 3월 도쿄 회의록은 “TLS 베이스라인 요구사항의 범위 명확화”라는 제목의 긴 토론을 기록한다. 참석자들은 브라우저 대 비브라우저 용도, 운영체제 트러스트 스토어, 사설·공개 PKI, 서버 간 애플리케이션, 별도 워킹 그룹 필요성을 두고 논쟁했다.

회의록은 상반된 실무적 우려를 보존한다. 일부는 브라우저 루트 프로그램이 BR이 결박되어야 할 운영 현실을 제공한다고 주장했다. 다른 이들은 운영체제와 애플리케이션이 같은 루트를 사용하며, 비브라우저 사용자에게는 대안이 없고, 브라우저 특화 요구사항이 그 용도를 분열시킬 수 있다고 경고했다. 기록된 요약은 두 관점을 식별했다: BR이 더 넓은 용례를 위한 유일한 실용적 안식처라는 관점, 또는 점점 브라우저 특화가 되어 분리하거나 명확화해야 한다는 관점.

그 회의록은 헌장 개정이 아니다. 합의가 아닌 토론을 기록한다. 그 의미는 더 좁고 더 강하다: SC-106은 워킹 그룹이 이미 알고 있던 문서화된 단층선 위에 놓였다.

2026년 8월의 풀 리퀘스트 댓글은 그 선을 재현한다. 한 기여자는 초점 사례들을 “non WebPKI”라고 묘사했다. Ben Wilson은 경로 보증이 신뢰 당사자가 구축하고 수용하는 경로에 달려 있으며, 전 포스트퀀텀 경로 옆에 이행 경로를 위한 여지가 남는다고 주장했다. 이후의 Chrome 댓글은 혼합 체인의 두 방향을 구분하고, 비브라우저 초점이 헌장과 부합하는지 의문을 제기하며, CA/B Forum의 다른 워킹 그룹을 제안했다.

각각은 귀속 가능한 견해다. 어느 것도 집단적 입장이 아니다. 이 글은 GitHub 반응 수를 표로 만들지 않고, 벤더 견해를 거부권으로 만들지 않고, 회의록을 헌법으로 만들지 않는다.

경로 순수성은 결정 권한의 지도이기도 하다

순수 체인 논쟁은 암호학적처럼 보이지만 거버넌스 표면을 드러낸다.

초안의 근거는 제시된 체인 어디든 고전적 서명이 있으면 그 체인은 고전적 보증을 가진다고 말한다. 그 진술은 혼합 구조 전체를 금지해야 하는지에 대한 질문에 답하지 않고서도, 검사 중인 체인에 대해 참일 수 있다. Ben Wilson의 댓글은 인접한 점을 만든다: 신뢰 당사자는 고전적 대안을 거부하고 별도의 전 포스트퀀텀 경로를 검증할 수 있다; 다른 경로의 존재는 수용된 경로의 서명을 바꾸지 않는다.

RFC 5280은 층을 분리하는 데 도움이 된다. 잠재적 인증 경로와 트러스트 앵커 정보는 검증의 입력이다. 트러스트 앵커의 선택은 정책의 문제이며 서로 다른 경로는 같은 앵커로 시작할 필요가 없다. 베이스라인 요구사항 프로필은 CA가 무엇을 발급하는지 제약할 수 있다. 그 자체로 신뢰 당사자가 어떤 경로를 구축하거나 지역 신뢰 정책이 어떤 앵커를 수용하는지 선택하지 않는다.

이 분리가 혼합 체인 제한을 제거해야 한다는 증명은 아니다. 포스트퀀텀 가입자 키에 서명하는 고전적 CA는 이용자를 위한 고전적 키에 서명하는 포스트퀀텀 CA와는 다른 CT 용량·보안 결과를 만들 수 있다. 공통 프로필이 공유 불변 조건을 보호하기 위해 구조를 금지하는 것은 정당할 수 있다.

그러나 불변 조건은 명시되어야 한다. “ML-DSA를 실은 인증서는 모든 가능한 경로에서 종단 간 포스트퀀텀으로 표시 가능해야 한다”인가? “기존 웹 CT 로그는 고전적 루트 아래에서 더 큰 가입자 객체를 물려받지 않아야 한다”인가? “브라우저가 수용하는 경로는 다운그레이드에 저항해야 한다”인가? 이들은 동일한 규칙이 아니다.

하나의 제한이 경로 보증, CT 수용, 루트 신호, 레거시 호환성, 비브라우저 이행을 동시에 해결하려 하면, 공통 필요성이 입증되기 전에 지역적 결정을 공통 층에 넣는 위험이 있다.

실행 중인 구현은 단일 승자가 아니라 복수 경로를 보여준다

Chrome의 공개 로드맵은 웹 특화 경로 하나를 보여준다. 단계적 포스트퀀텀 HTTPS 인증, 인증서 협상, 고전·포스트퀀텀 짝 자격, 다운그레이드 보호, 고전적 옵션 제거까지의 매우 긴 경로를 서술한다. 선호하는 공개 웹 아키텍처는 전통적 X.509 ML-DSA 인증서가 아닌 Merkle Tree 인증서를 쓴다.

Chrome의 양자내성 루트 프로그램은 이 분리를 관측 가능하게 만든다. Chrome은 전통적 ML-DSA X.509 인증서를 Chrome 150부터 사설 PKI 계층에서 지원한다고 말한다. 별도로, 프로덕션용으로는 명시적으로 신뢰되지 않는 코사이너를 둔 테스트 전용 MTC 루트 스토어를 제공한다. 테스트 프로그램은 자체 알고리즘, 로그·미러링 요구사항과 미래 프로덕션 경로를 사용한다.

이것이 Chrome의 설계가 모든 SDK나 임베디드 클라이언트를 지배해야 한다는 증거는 아니다. 표준 라벨이 실험의 유일한 경로가 아니라는 증거다. 브라우저는 한 인증서 아키텍처를 테스트하고, 다른 것을 사설 PKI에서 지원하고, 프로덕션 신뢰를 분리할 수 있다. 다른 루트 프로그램과 시스템 트러스트 스토어는 다르지만 귀속 가능한 결정을 내릴 수 있다.

이것은 Lu Heng의 최소 명세 원칙에 가깝다: 필요한 공유 불변 조건만 공통 층에 두고, 지역 검증을 보존하며, 이후 채택이 실행 중인 시스템에서 관측 가능하도록 한다. 신중히 적용하면 이 원칙은 “절대 표준화하지 말라”가 아니다. 상호운용이 가능해지기 전에 어떤 사실이 공통이어야 하고 어떤 선택이 명명된 호환성 세트에 남을 수 있는지를 묻는다.

FIPS 204는 하나의 공통 질문에 답한다: ML-DSA가 무엇이고 세 파라미터 세트가 어떻게 작동하는가. 인증서 프로필은 인코딩과 발급 질문에 답한다. 루트 정책은 어떤 계층이 신뢰되는지에 답한다. CT 정책은 어떤 객체가 수용되고 투명성이 어떻게 증명되는지에 답한다. 신뢰 당사자는 지역 정책 아래에서 경로를 선택한다. 배포 증거는 실제로 무엇이 돌아가는지 보여준다. 어느 답도 다른 모든 답을 대행할 수 없다.

공통 프로필에 앞서 권한 위임 영수증

누락된 산출물은 헌법적 글일 필요가 없다. 하나의 공개 표면 충분하다.

제안의 정체성.불변 베이스, 제안된 커밋, 상태, 제안자, 공식 지지자, 토론·투표 기간, 투표 영수증, IPR 상태, 최종 버전, 시행일을 기록한다. 초안 편집은 승인된 문서와 구분 가능해야 한다.

의도된 신뢰 당사자.브라우저, 운영체제 검증자, SDK, 임베디드 클라이언트, IoT 기기, 기업용 미들웨어, 사설·공개 PKI를 별도로 명명한다. “인증서 소비자”라는 가방으로 어느 클래스가 의미되는지 숨기지 않는다.

권한 원천.포함된 각 클래스에 대해 정확한 헌장 조항, 그 해석 권한을 가진 기구, 미해결 이의를 인용한다. 이 작업이 부수적 효용을 가진 웹 최소 기준인지, 부수적 프로필인지, 더 넓은 복수 선거구 표준인지 기록한다.

대표성 경계.어느 명명된 신뢰 당사자가 소비자 클래스에서 표를 행사할 수 있고, 어느 것이 이해관계자나 전문가로만 참여하며, 어느 것이 결정에 들어가는 공식 경로가 없는지 식별한다. 부재는 거부권을 만들지 않는다; 대표성 주장을 막는다.

공유 불변 조건.지역 프로필이 아니라 공통 규칙을 요구하는 위해를 진술한다. 인증서 인코딩, 경로 강도, 다운그레이드 저항, CT 용량, 루트 수용을 별도 행으로 유지한다.

지역 결정 권한.루트 프로그램은 신뢰를 선택하고, CT 프로그램은 수용과 운영 정책을 선택하며, CA는 허용된 규칙 안에서 발급 여부와 방법을 선택하고, 신뢰 당사자는 수용된 경로와 앵커를 선택한다는 것을 기록한다. 제안이 그 선택 중 하나를 의도적으로 제약하는 곳을 명명한다.

구현 증거.테스트 벡터, 라이브러리, 인증서 크기, 경로 구축 결과, CT 실험, 루트 파일럿, 버전별 실패 관찰을 나열한다. 한 선거구가 차단되었다는 주장은 재현 가능한 장애물을 가리켜야 한다.

포럼과 검토.SCWG에서 진행하는 것, 헌장을 개정·명확화하는 것, Forum의 다른 워킹 그룹을 만드는 것, 더 좁은 프로필을 다른 곳에 발표하는 것을 비교한다. 검토 날짜와 개정 트리거를 정해 실험적 제한이 단순히 살아남는 것으로 영구화되지 않게 한다.

이 영수증은 만장일치를 요구하지 않는다. 모든 SDK 벤더에게 거부권을 주지 않는다. 필요에서 권한으로, 권한에서 배포로 가는 체인을 검사 가능하게 한다.

9월 2일에 결론할 수 없는 것

공개 증거는 SC-106이 무효하거나, 장악되었거나, 불필요하거나, 기술적으로 결함이 있다고 보여주지 않는다. SCWG가 범위 이의에 집단적으로 동의했다고 보여주지 않는다. 모든 명명된 비브라우저 클라이언트가 헌장 밖이거나, 인터넷 서버 조항이 자동으로 그 모두를 포함한다고 보여주지 않는다.

또한 전통적 ML-DSA X.509 인증서가 프로덕션 브라우저 루트에 들어갈 것인지, CT가 특정 용량을 감당할 수 있는지 없는지, 혼합 체인의 어느 방향이 채택될지 보여주지 않는다. 초안 자체가 루트 신뢰 강제와 SCT 서명 변경 권한을 부인한다. Chrome의 로드맵은 Forum 결정이 아니라 제품 전략이다. 공개 댓글은 확정 문서가 아니라 제안과 이의다.

이 구분이 중요한 이유는 지금이 기록을 값싸게 고칠 수 있는 단계이기 때문이다. 프로필이 채택되면 감사 기준, 발급 툴링, 조달 문서가 그 제도적 출처를 확정된 것으로 처리할 수 있다. 이후 워킹 그룹은 최초의 선거구 질문이 답되지 않았더라도 그 제한을 “업계 표준”으로 물려받을 수 있다.

프로필은 약하지 않으면서 좁을 수 있다

최선의 결과는 반드시 더 큰 권한도 더 작은 권한도 아니다. 명시적인 권한이다.

SCWG가 인터넷 접근 서버 인증이 프로필을 승인하며 브라우저로 정의된 표결 클래스가 적절한 결정 메커니즘이라고 판단하면, 그 해석을 공표하고 영향받는 비웹 용도의 경계를 정할 수 있다. 프로필이 웹 CT와 브라우저 민첩성에서 갈라진 시스템, SDK, 임베디드 클라이언트를 주로 위한 것이라면, 별도 워킹 그룹이 그 소비자들에게 더 명확한 자리를 주고 다른 제약을 허용할 수 있다. 실행 중인 파일럿이 루트별 정책 아래 진행될 수 있다면, 공통 문서는 증거가 쌓이는 동안 기다릴 수 있다.

각 경로는 자기 영수증 안에서만 정당하다. 어느 것도 나머지를 구현 세부라 부르며 몰래 도입되어서는 안 된다.

SC-106의 초안은 이미 하나의 유용한 행위를 수행했다: Forum의 권한 허용을 루트 스토어 신뢰와 CT 서명에서 분리했다. 다음 분리는 제도적이어야 한다. 신뢰 당사자를 명명하라. 헌장 권한을 명명하라. 지역에 남는 결정을 명명하라. 그러면 기술 프로필은 그것을 산출한 권한 위임보다도, 이하에서도, 아무것도 아니게 될 것이다.

출처

  1. Lu Heng, “The Multi-Stakeholder Mirage”
  2. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  3. CA/Browser Forum servercert 풀 리퀘스트 679, SC-106
  4. SC-106 불변 비교
  5. 동결된 헤드 시점의 제안된 TLS 베이스라인 요구사항
  6. 서버 인증서 워킹 그룹 헌장
  7. SCWG 대면 회의 64차 회의록
  8. CA/Browser Forum 정관
  9. 서버 인증서 워킹 그룹 투표 현황
  10. NIST FIPS 204
  11. RFC 5280, 6절
  12. Chromium, “Post-Quantum HTTPS Authentication Roadmap”
  13. Chrome Quantum-resistant Root Program 테스트 지침