要約

  • pull request 679は、ML-DSA-44、ML-DSA-65、ML-DSA-87をTLS Baseline Requirementsに加え、Subscriber/CA Certificate、CRL、OCSP responseでの鍵と署名を定めるDraftである。
  • 提案はroot store operatorに信頼を強制せず、SCTの署名algorithmも変えないと明記する。必要性の説明ではSDK client、組み込み・IoT、企業middleware、OS trust storeを使うapplicationを挙げる。
  • SCWG CharterはInternetから到達可能なserverのTLS certificateを範囲に含める。しかし投票権を持つCertificate Consumerは、一般公衆がWebを安全に閲覧するためのsoftwareを作る組織である。
  • internal-only PKIの除外は明示的だが限定的である。したがって「非ブラウザはすべて範囲外」とも、「公開rootを使う全softwareが代表済み」とも言えない。
  • 2026年9月2日の締切時点でSC-106はopenのDraft PRであり、公式ballot status pageに掲載されていなかった。公開commentと2025年の議事録は異論の証拠で、Working Groupの決定ではない。
  • 共通profileの前に、対象利用者、根拠条項、投票・参加経路、共通invariant、root/CT/pathの権限、実装証拠、代替venue、見直し条件をmandate receiptに記録すべきである。

必要性を語る名詞と投票資格を語る名詞

SC-106の核心は量子計算機の予測ではなく、誰が困っていると書かれているかにある。PRは、現在のX.509 public trust infrastructureではpost-quantum authenticationへの実用的な道を持たないrelying partyが多いと述べる。そしてSDK-based service client、embedded/IoT system、enterprise middleware、OS vendorが管理するtrust storeで認証するapplicationを具体的に挙げる。

それらはTLS certificateを検証し得るが、必ずしもbrowserではない。SCWG CharterでCertificate Consumer voting memberになるには、一般公衆向けに安全なWeb閲覧用softwareを提供し、更新、root list、issuer complianceの文書を公開しなければならない。Certificate Issuer側の資格も、そのcertificateが同じクラスのbrowserでvalidとして扱われることに結び付く。

同じ企業がbrowser、OS、libraryを運営することはある。しかし一社の組織範囲が、Charter上の投票根拠を自動的に広げるわけではない。非Web clientを理解する専門家が会議にいることも、そのclientからの委任を証明しない。

Lu Hengのstakeholderとprincipalの区別は、この点を過度な非難なしに整理する。参加は知識、警告、異議を供給する。mandateは、誰が誰の損失を伴う決定を許したかを示す。SC-106は、Web minimumの副次的利用なのか、Charter上のancillary workなのか、複数の利用者階層に向けたpublic-trust profileなのかを明示する必要がある。

固定commitに含まれる技術的選択

eefc670…のdiffは、FIPS 204の三つのparameter setを追加する。public keyのencoding検査、Subscriber CertificateのKey Usage、正確なAlgorithmIdentifier byteを定める。parameterはabsentでなければならず、HashML-DSAは許されない。

さらに、certified keyとcertificate signatureを双方向に対応させる。ML-DSA subject public keyはML-DSA signatureでなければならない。ML-DSA certificate/precertificate signatureはML-DSA public keyだけをcertifyできる。CRLとOCSP responseはpublic keyをcertifyしないため、後者の制限から除外される。

一方、PRのpreambleは権限の境界も認める。この変更が通ってもroot store operatorはML-DSA hierarchyを信頼する義務を負わない。SCTを署名するalgorithmもCT log operatorの管理下に残る。BR上のpermission、root trust、CT operationは三つの状態である。

そのため、各non-Web clientの障害を特定する必要がある。CA auditなのか、root policyなのか、certificate tooling、path building、trust-store distribution、server configurationなのか。公開資料には対象client数、blockされたversion、共通profileで解決した実測結果がない。必要性が虚偽だという意味ではない。まだ検証単位が示されていないという意味である。

Draftをballotと先取りしない

repositoryのtitleにはSC-106があり、本文も将来のballotを説明する。しかし調査時点のUIはOpen、Draft、one commitである。SCWGの公式pageにはVoting、IPR Review、Discussion、Draft / Under ConsiderationのどこにもSC-106がなかった。

したがって、確定できる状態はDraft pull requestである。formal discussion、proposer/endorser、vote window、結果、IPR、Final Maintenance Guideline、effective dateは確認できない。

手続は単なる飾りではない。authorがdiffを作り、Working Groupが特定versionをformal processに載せ、二つのclassが投票し、IPR reviewを経て、final textが効力を持つ。その後にCA、root program、CT、clientが実装を選ぶ。最初のdocumentに後続決定の権限をまとめて与えると、proposalとadoptionの境界が消える。

immutable comparisonは、この制約のために有用である。後日変わっても、何が提案されていたかを証明する。最終状態を予測するものではない。

Activityの範囲は広く、voting constituencyは狭い

Charterの一文だけでは結論を出せない。Scopeは、InternetからaccessできるserverをauthenticationするTLS server certificateのissuance/management requirementを作ること、emerging threatに対応して更新すること、主要活動にancillaryな仕事を認める。これは特定browser productだけの説明ではない。

しかしmembership clauseは別の働きをする。Consumer voteの根拠はWeb browsing softwareである。Issuer voteの根拠もbrowser acceptanceである。X.509 pathを検証できる全softwareの集合と、意思決定に参加するconsumer classは一致しない。

Out of Scope clauseは、enterpriseがinternal purposeだけに運営し、そのrootがCertificate Consumerから配布されないPKIを除外する。code signing、S/MIMEなども別である。この文は、system trust storeを使うnon-browser clientをすべて禁止するとは書いていない。一方、境界を明示する必要性をCharter自身が認めている。

したがって、現在の証拠が支えるのはscope tensionであり、違反の判決ではない。Working GroupがInternet-server clauseまたはancillary clauseで進めるなら、その解釈と限界を公開し、誰が解釈権を持つかを記録すべきである。

東京の議事録は未解決状態を保存した

2025年3月のF2F 64 minutesには「Clarify scope of TLS Baseline Requirements」という独立sectionがある。browser/non-browser、OS trust store、server-to-server、private PKI、agility、新しいWGが議論された。

一方はbrowser root policyこそBRの実際の強制力であり、遅いnon-browser use caseがWeb securityを拘束すべきでないと考えた。他方はOSとapplicationが同じrootを利用し、代替文書がなく、browser-specific ruleが分断を招くと警告した。

minutesは二つのperspectiveをまとめたが、voteやCharter amendmentを記録しなかった。それでも重要である。SC-106のscope問題は、ML-DSAに反対するため後から作られたものではない。組織が以前から認識していた設計上の継ぎ目である。

2026年のPR commentsにも同じ継ぎ目が現れた。ある参加者はfocusをnon WebPKIと表現した。Ben Wilsonはassuranceがrelying partyのconstruct/acceptしたpathに依存すると述べた。Chromeの参加者はmixed chainの二方向を分け、non-browser needとCharter mandateの不整合を指摘し、別WGを提案した。

commentはdecisionではない。vendor名、GitHub reaction、technical reputationのいずれもballotの代わりにならない。

Pure chain論争はcontrol surfaceを可視化する

Draft rationaleは、presented pathのどこかにclassical signatureがあれば、そのpathはclassical assuranceまでだと説明する。この命題と「全てのmixed constructionをBRで禁止すべきか」は同じではない。relying partyがpure PQ pathだけをacceptし、classical alternativeを無視する設計もあり得る。

RFC 5280ではprospective certification pathとtrust anchor informationがvalidation inputである。trust anchor selectionはpolicyであり、すべてのpathが同じanchorを使う必要はない。CA profileはissuanceを制約できるが、clientのpath choiceを代行しない。

それでもcommon restrictionが不要とは限らない。classical CA→PQ EE keyは既存root配下の大きなobjectとCT負荷を生む一方、PQ CA→classical EE keyはtransition/downgrade signalに使われ得る。方向によってrisk ownerが違う。

共通化するならinvariantを一つずつ書くべきだ。Web CT capacity、accepted pathのPQ integrity、root signalling、legacy compatibility、non-Web transitionを一つの「purity」に押し込めば、別々のownerの判断がdocument内で混ざる。

実装は一つの普遍解ではなく複数のrouteを示す

Chromium roadmapはWeb向けの段階移行を描く。certificate negotiation、classical/PQ pair、downgrade protection、最終的なclassical option除去を含むが、完了まで非常に長いと認める。Chromeのpublic Web計画はtraditional X.509 ML-DSAよりMerkle Tree Certificatesを中心に置く。

CQR Programのtesting instructionsはさらに細かい。Chrome 150からtraditional ML-DSA certificateをprivate PKIでtestできる。MTC向けには別のtest root storeを用意し、cosignerをproductionでは信頼しない状態に明示的に分類する。log、mirror、algorithmにも独自条件がある。

これはChrome方式を全てのIoTに押しつける根拠ではない。異なるcompatibility setを分離して試せるrunning evidenceである。

FIPS 204はalgorithmを定義する。BR profileはcertificate encodingとissuanceを定義する。root policyはtrustを決める。CTはadmission/transparencyを決める。clientはpathを決める。deploymentは結果を示す。Lu HengのMinimum Initial Specificationは、この分離を保ち、publicationをrealityと呼ばないための規律として使える。

mandate receiptのフィールド

最初にproposal identityを置く。base/head、status、formal proposer/endorser、discussion/voting、class別vote、IPR、final version、effective dateである。次にtarget populationをbrowser、OS validator、SDK、embedded、IoT、middleware、private/public PKIに分ける。

各populationについて、Charter clause、interpretation owner、vote route、consultation route、formal routeの不存在を記録する。参加経路がないことはvetoではないが、representation claimを制限する。

技術欄ではkey format、path assurance、downgrade、CT capacity、root admissionを別行にし、invariant、decision owner、evidence、uncertainty、local choiceを示す。implementation欄にはtest vector、library/version、certificate size、selected path、pilot、failureを載せる。

最後にvenueとreviewを比較する。現SCWGで公開解釈を伴って進む、Charterをclarify/amendする、non-browser consumer WGを作る、root-specific pilotを続ける。transition ruleにはreview dateとexitを付ける。

証拠がまだ言えないこと

SC-106が採択済み、無効、不要、技術的に完成したとは言えない。SCWGのcollective charter interpretation、対象clientの需要census、production root commitment、CT capacity resultはいずれもない。

Chrome roadmapはForum decisionではない。Mozilla参加者のcommentはsecurity proofではない。PR preambleはOS vendorを代表しない。ballot pageにないことはpublic statusの証拠であって、隠れた意図の証拠ではない。

この不確実性こそ、今なら低いcostで記録を直せる理由である。audit、procurement、toolingがSC-106をindustry standardと呼び始めた後では、deploymentが起源のmandateを逆向きに正当化する。

明示的なmandateはprofileを弱くしない

SCWGがInternet-accessible server scopeで十分だと判断するなら、解釈と代表範囲を公開できる。non-Web clientのconstraintがWeb CTと異なるなら、別WGが適するかもしれない。root programごとのpilotで足りるなら、common textはevidenceを待てる。

どの選択もML-DSAを否定しない。documentの置き場所にconstitutional decisionを代行させないだけである。

SC-106はすでにprofile permission、root trust、SCT signatureを分けた。次はbeneficiaryとvoterを分けるべきだ。そのreceiptがあれば、technical profileはmandate以上にも以下にもならない。

情報源

  1. Lu Heng「The Multi-Stakeholder Mirage」
  2. Lu Heng「Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption」
  3. CA/Browser Forum servercert pull request 679 — SC-106
  4. SC-106のimmutable comparison
  5. 固定headのproposed TLS Baseline Requirements
  6. Server Certificate Working Group Charter
  7. SCWG F2F 64 minutes
  8. CA/Browser Forum Bylaws
  9. SCWG ballot status
  10. NIST FIPS 204
  11. RFC 5280 Section 6
  12. Chromium Post-Quantum HTTPS Authentication Roadmap
  13. Chrome Quantum-resistant Root Program testing instructions