Company-Certsのアンカー更新を誰が承認したのか

Summary

個人提出のInternet-Draftは、OSの全体トラストストアを変更せず、用途を限定したプライベートCAのトラストアンカーをHTTPSの/.well-known/company-certsで発見する仕組みを提案している。
オリジンの認証、X.509パスの有効性、最も新しいvalid_fromを選ぶ規則は、それぞれ有用だが、組織内でアンカー交代を承認した権限までは示さない。重複期間には、その証跡がないまま実効的な信頼が切り替わり得る。
Daniel Kadeは、メタデータの厳密な版、新旧の指紋、用途、重複期間、承認権限、ローカル方針、別経路の確認、訂正手段を結ぶ「トラストアンカー変更レシート」を提案する。これは編集上の提言であり、IETFの要件ではない。

攻撃を仮定しなくても境界は見える

通常のロールオーバーを考えれば十分だ。組織は一斉切替による停止を避けるため、数日間だけ旧チェーンと新チェーンを同時に公開する。両方とも有効期間内にあり、同じusage_contextとドメイン制約を持つ。クライアントは新しい開始時刻を持つチェーンを選び、予定どおり移行する。

この設計には明確な利点がある。メールでCAファイルを配るより出所が明確であり、OS全体へ投入するより影響範囲が狭い。選択規則が一定なら、実装ごとの気まぐれも減る。しかし、正しい配信が正しい社内決裁を自動的に意味するわけではない。

クライアントが証明できるのは、認証されたオリジンが特定のオブジェクトを返し、ローカル方針がその中のチェーンを選んだことだ。PKI責任者が新しいアンカーを認めたか、アプリケーション所有者が用途を了承したか、緊急例外に期限があったかは、同じ通信からは分からない。

トラストアンカーは単なる配布物ではない。パス検証が前提として受け取るローカル入力である。集合に追加されれば、それまで受け入れられなかった証明書パスが、限定された用途とはいえ受理される可能性が生まれる。公開能力は、ソフトウェアが認める権威を変える能力でもある。

草案が定めるもの

draft-doehle-company-certs-discovery-00は2026年7月22日付の個人Internet-Draftで、Standards Trackを意図している。調査時点では-00だけであり、RFCでもIETF合意でもない。実装や運用実績を示す資料でもない。

提案は/.well-known/company-certsにバージョン付きJSONを置く。そこにはauthority_informationとtrust_anchorsがあり、各アンカーはusage_contextと複数のcertificate_chainsを持ち得る。チェーンにはvalid_from、valid_until、同一オリジンのHTTPS URL、PEM形式のX.509チェーン、CRLやOCSP、SHA-256指紋を記録できる。

適用範囲にも制約がある。permitted_domainsは、検証済みのエンドポイントTLS証明書に含まれるDNS識別子と同一か、そのサブドメインでなければならない。isolated_store_requiredは、そのアンカーを用途専用の領域に隔離してほしいという公開者の意思を示す。

この仕組みはプライベートCAをOSのグローバルストアに追加するものではない。Web PKIを置き換えず、エンドエンティティ証明書を発行せず、公開されたCAがあらゆる目的で安全だとも宣言しない。価値はむしろ、必要なアプリケーションだけに信頼を限定できることにある。

HTTPSの証明書検証は必須で、ドメインを支配する者にそのオリジンでの公開権限を与える。一方で草案は、その事実だけではCAの品質、安全性、運用品質を証明しないと線を引く。社内でDNS、ホスティング、CDN、TLS鍵、デプロイ、CA運用を誰が握るかは、別の問題である。

オリジンは組織図ではない

RFC 8615はwell-known URIの名前空間を整備する。そのセキュリティ節は、well-knownリソースへの書込み権限がオリジン全体を代表する力になり得ると注意する。共有ホスティングや細分化された運用権限では、小さく見える権限が大きな意味を持つ。

だからといってオリジン認証の価値が低いわけではない。誰の名前空間から発言されたかを確定する重要な証拠だ。ただし「正しいドメインが配った」と「正しい社内権限が承認した」は別々に立証すべき命題である。

Web運用者がファイルを展開し、ネットワーク担当がDNSを管理し、CDN事業者がエッジから配信し、PKIチームがCAを構成し、アプリ所有者が利用目的を決めることは珍しくない。「会社が公開した」という一文に圧縮すると、どの引継ぎで権限が変わったかが消える。

RFC 9525はTLSの参照識別子を検証し、クライアントが意図した名前に提示されたサーバーIDが適合するかを判断する。これは正しいサーバーへ到達したことの根拠にはなるが、社内変更会議の議事録にはならない。認証済みエンドポイントが、権限の裏付けを欠く変更を配る可能性は論理的に残る。

自動化も例外ではない。承認済みの自動方針は正当な権限になり得るが、変更できる用途、新旧アンカーの条件、必要な第二証拠、重複期間、停止権限を先に定義する必要がある。パイプラインの成功は実行の証跡であって、権限を自給する印章ではない。

新しい時刻は順番を決める

同一用途に複数のチェーンが適用できる場合、草案では有効期間外を除外し、ローカル方針が上書きしない限りvalid_fromが最も新しいものを選ぶ。自動移行には合理的な規則だ。ただし、この規則が答えるのは優先順位であって承認者ではない。

RFC 3339による時刻表現は相互運用性を高める。それでも、誰が日付を設定したか、なぜその重複期間なのか、複数部門が合意したかは分からない。適切な変更にも誤操作にも侵害された公開にも、構文上正しい「より新しい」値は書ける。

RFC 5280のパス検証も社内決裁を検査しない。トラストアンカーと方針はローカル入力として与えられ、その前提の下でチェーンを評価する。新しいパスが正しく検証できることと、そのアンカーを入力に追加する決定が正しかったことは別だ。

したがって「最新を選ぶ」こと自体を欠陥と呼ぶべきではない。問題は、運用画面が「方針どおり新チェーンを選択」を「組織が新アンカーを承認」に書き換えるときに生じる。

隔離は値ではなく挙動である

isolated_store_requiredは公開者の意図であり、技術的な強制ではない。草案は、隔離できないクライアントがアンカーを拒否すべきだとする。フィールドがtrueであるだけでは、隔離が成立した証拠にならない。

実際にどのストアへ読み込んだか、どの検証APIが参照できるか、共通ライブラリやOS連携が他用途へ広げていないかを調べる必要がある。JSONを変えなくても、アプリ改修によって専用コレクションが共有化されることはある。

permitted_domainsもクライアントが実行して初めて制御になる。パーサーが値を保存し、パス構築側が無視することもあり得る。用途間でキャッシュを共有すれば、境界が混ざる。公開された制約と観測された挙動を結ぶ証跡が要る。

この仕組みの最も大切な安全特性は、信頼を局所化する点にある。アプリ専用アンカーがグローバルなストアへ漏れたなら、実装上の小さな変更ではなく、権限範囲の拡大として扱うべきだ。

新鮮な応答と生きた承認は違う

RFC 9110とRFC 9111はHTTPの意味、キャッシュ、新鮮さ、再検証を扱う。草案も保守的なキャッシュ、定期的な再取得、リプレイや古いメタデータへの対策を求め、クライアント独自の最長新鮮期間を認める。

これらは、オリジンの表現をどの程度新しく保つかという問いに答える。組織上の承認がまだ有効かは別の時計だ。二時間だけ許された緊急変更よりキャッシュが長く残るかもしれない。セキュリティ責任者が取り消しても、一部エッジが旧版を返すかもしれない。逆に、オリジンから今届いたJSONでも、アプリ所有者が認めていないことはある。

初回取得は特別なブートストラップである。取得前にはこの経路のアンカーが一つもなく、取得後には新しい認証パスが開く。草案も初回成功をセンシティブな出来事とみなす。初回登録、定期更新、重複、切替、旧アンカー削除、緊急回帰を同じGET成功として数えてはいけない。

頻繁な取得は、どの組織や用途に関心があるかを漏らし得る。キャッシュは可用性だけでなくプライバシーにも役立つ。そのため、キャッシュ期限は単なる通信最適化ではなく、訂正が届くまで許容する時間として決める必要がある。

証明書の失効は承認の失効ではない

メタデータはCRLやOCSPの場所を示せる。RFC 6960は証明書の状態確認に役立つ。だが、下位証明書が失効しているかどうかと、アンカー集合を変更する権限があったかどうかは別の問いだ。

未承認で追加されたCAが、失効していない証明書を発行することは可能だ。組織が退役させたかった旧アンカーも、暗号学的には有効なままかもしれない。OCSP応答はアンカー交代の理由、承認者、重複範囲を復元しない。

エンドポイントから削除しても即座に全ては戻らない。キャッシュ、オフライン端末、継続セッション、別ストアへの複製が残る。訂正には対象クライアント、最大伝播時間、再検証、隔離維持の確認まで必要だ。

トラストアンカー変更レシート

Daniel Kadeが提案するのは、実質的なCompany-Certs変更ごとのトラストアンカー変更レシートである。公開JSONへの新しい必須フィールドではなく、IETFへの規範要求でもない。公開事実と組織権限とローカル判断を結ぶ運用記録だ。

最初にメタデータの版を固定する。オブジェクトの厳密なダイジェスト、オリジン、検証した参照識別子、取得時刻、キャッシュと再検証の状態を残す。さらに用途、許可ドメイン、隔離要件を加える。一つのダイジェストへの承認が、将来同じURLに置かれる別内容を正当化しないようにする。

次に変化そのものを名付ける。旧アンカーと新アンカーの指紋、チェーン識別子、開始・終了時刻、重複窓、予定された切替状態を一組にする。追加、優先、削除、緊急ロールバックは異なる操作であり、「更新済み」の一語で潰してはならない。

権限欄には、承認した役割、方針または範囲限定の自動化と、それが認めた変更記録への保護された参照を置く。個人名や会議内容を公開エンドポイントに出す必要はない。大切なのは、実行した公開経路とは独立に、その委任を検証できることだ。

クライアント欄には、最新規則かローカル上書きか、初回やルート変更に別経路の確認を求めたか、隔離とドメイン制約を実装できたか、再検証期限、到達不能時の扱いを記す。訂正欄はCRL、OCSP、緊急削除、ロールバック、対象群、最大反映時間と終了証拠を結ぶ。レシート自身にも期限を設ける。

影響に見合う別経路

低権限の社内テストなら、オリジン認証と署名済みリポジトリ承認で十分かもしれない。決済、署名、インフラ制御なら、別管理域の承認鍵や二者統制が必要になり得る。全てを同じ儀式にするのではなく、起こり得る結果に応じて基準を選ぶ。

同じアカウントから届く確認や、同じCDNに載った第二URLは、独立に見えて同じ故障を共有する。PKI管理系、署名マニフェスト、保護された変更台帳、ハードウェア鍵、別管理ドメインなど、失敗点が異なる証拠が望ましい。

RFC 5011は限定的な比較材料にすぎない。DNSSECの自動アンカー更新では追加、保持、削除の状態を明示するが、その規則はCompany-Certsには適用されない。参考になるのは、ソフトウェアが自分の信頼基盤を更新するなら、単一の「現在値」だけでなく遷移の記憶が必要だという点である。

動詞を混ぜない

このInternet-Draftに企業統治全体を背負わせる必要はない。認証済みオリジン、用途、ドメイン、有効期間、隔離という境界を与えるだけでも、無文脈のCAファイル配布やグローバルストアへの投入より一歩進んでいる。

資料は実際の導入、事故、侵害、誤更新を示していない。冒頭は草案の複数チェーン選択から作った設計テストであり、特定企業への主張ではない。

成熟した運用は動詞を守る。HTTPSは取得元を「認証」する。JSONはメタデータを「表現」する。X.509は与えられた入力でパスを「検証」する。クライアント方針はアンカーを「選択」する。組織権限は変更を「承認」する。レシートは各判断をつなぐが、一つを他の代用品にはしない。

Company-Certsエンドポイントではトラストアンカー更新の承認者は証明できない

なぜ重要か

Summary

攻撃を仮定しなくても境界は見える

草案が定めるもの

オリジンは組織図ではない

新しい時刻は順番を決める

隔離は値ではなく挙動である

新鮮な応答と生きた承認は違う

証明書の失効は承認の失効ではない

トラストアンカー変更レシート

影響に見合う別経路

動詞を混ぜない

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説