結論（忙しい方向け）
- PGPのWeb of Trust運用はスケール限界が見えており、DID/VCで“複数の保証”を組み合わせる方向に舵を切ろうとしている。
- ただしDID/VCは学習コストとエコシステム依存が重く、当面はPGPとのデュアル運用が現実的。
- 企業側は『今すぐ全面移行』ではなく、署名フロー棚卸し＋Sigstore等での底上げを先にやるのが安全。
想定読者：OSSの署名運用・サプライチェーンセキュリティに関わる開発者／SRE／セキュリティ担当
Linuxカーネルにパッチを送るたびに、GPGキーの管理でため息をついたことはありませんか？
鍵の有効期限が切れていてやり直し、キーサーバはどれを信じればいいか分からない、対面署名会なんてどこの時代の儀式だよ……と感じた人は多いはずです。
その「長年放置されてきた痛み」に、かなりラディカルなメスを入れようとしているのが、今回の「PGPから分散型ID（DID）＋VCへの移行」構想です。
一言で言うと、「SSHからFIDO2へ」のID版がカーネルに来た
今回Linuxカーネル界隈で提案されているのは、ざっくり言えばこうです。
「PGP鍵とWeb of Trustでやってきた開発者認証をやめて、
W3C準拠の分散型ID（DID）とVerifiable Credential（VC）でやり直そう」
一言で言うと、これは「SSH鍵からFIDO2/WebAuthnに移行しよう」という動きにかなり近いです。
- SSH/PGP：
- シンプルでローカル完結、歴史は長いが、人間の運用に強く依存。
- FIDO2/DID：
- 仕組みは複雑だが、より明確なアイデンティティとポリシーベースの検証が可能。
Linuxカーネルという、正直「一番保守的で変化を嫌うOSSインフラ」の代表格が、DIDというWeb3/SSI寄りの技術に手を出し始めた。
この事実だけで、ID・セキュリティ界隈としてはかなり大きな事件です。
なぜ今、PGPではなくDIDなのか：カーネル側の本音
PGPがダメになったというより、「PGPが前提の運用モデルがもう限界」になっているのが実情です。
kernel.orgアカウント取得プロセスは、もはや儀式を通り越して苦行
ZDNetの記事にもある通り、今のkernel.orgアカウント取得はだいたいこんな流れです。
- 既存の「PGPの信頼の輪」にいる人を探す
- どこかのカンファレンスで実際に会う
- 公的身分証を見せてPGPキーに署名してもらう
- その情報をもとに運営側がスクリプトでゴニョゴニョ管理
正直、2020年代にやる運用ではないです。
しかも：
- 鍵の更新漏れ
- どこに誰が住んでいるかが暗黙に分かる「位置マップ」がプライバシーリスク
- ぜんぶ人力・スクリプト・Excel感覚の管理
Greg Kroah-Hartmanが「管理も運用も苦痛」と言い切っているのは、相当です。
「xzバックドア事件」で露呈した、「本人っぽければOK」問題
最近のxzバックドア騒ぎでよく分かったのは、
- PGP署名済みだからといって、安全とは限らない
- 「それっぽいアカウント」「長年コントリビュートしている風」の人物が一番怖い
という不都合な真実です。
PGPのWeb of Trustモデルは、あくまで「ある鍵が、ある人物のものであるらしい」という紐付けに強いだけで、その人物の振る舞いの継続的なモニタリングや、雇用主・組織・他の発行者からの複数の保証を組み合わせるところまでは面倒を見てくれません。
Linux ID構想が狙っているのはここです。
- 「実在の人間であること（Proof of Personhood）」
- 「どこかの企業に雇用されている」
- 「既存メンテナから信頼されている」
- 「Linux FoundationなどからのVCが付いている」
こうした複数の「検証可能な資格（VC）」を組み合わせることで、単一のPGP鍵奪取よりずっとコストの高い攻撃面に持っていこうとしている。
正直、この発想自体はかなり妥当です。
「1個の鍵」と「数年寝かせた人格ロールプレイ」だけで中枢に侵入できてしまう現状は、さすがにそろそろ見直すべきフェーズです。
PGP vs DID vs Sigstore：誰が一番ダメージを受けるのか
この動きは、「PGPを置き換える」話に見えて、実はそれ以上のインパクトがあります。
一番痛いのは、レガシーPGPワールド
- Debian、Fedora、各種ディストロのパッケージ署名
- kernel.orgのリリース署名
- Gitタグ署名の慣習
みんな「PGP一択」で組み上がっている世界です。
Linuxカーネルが「PGPはもうID基盤の中心にはしないかも」と言い始めた時点で、
- 「OSS界の正統IDはPGP」という暗黙の前提が崩れる
- 新規コントリビュータに「GPG覚えろ」と言い続ける説得力が弱くなる
これは地味ですが、長期的には大きい変化です。
実は思想的に揺さぶられているのは「Sigstore陣営」
SigstoreはSigstoreで、サプライチェーンの世界をかなり変えました。
- OIDCログイン（Google/GitHub/Microsoft）で短命な証明書を取る
- cosignでコンテナやアーティファクトに署名
- Rekorという透明ログに記録
開発者体験としては素晴らしいですし、「クラウド寄りOSS」には非常にフィットします。
一方で、SigstoreはID基盤としてはかなり「中央集権」寄りです。
- OIDCプロバイダ（Google/GitHubなど）を信頼の根にしている
- 特定の運営組織・インフラへの依存が前提
そこに対して、Linuxカーネル側が言っているのはこうです。
「プラットフォーム（GitHubやGoogleアカウント）に依存しない、
自己主権的なIDレイヤーを作りたい」
この思想は、Sigstoreの「実務的な中央集権モデル」に対するカウンターパンチになっています。
もちろん、当面Sigstoreが駆逐されることはないですが、
- 「コード署名のIDは全部Sigstore＋OIDCでいいでしょ」
と考えていた人には、かなり強い「待った」がかかった形です。
DID/VC導入の“現実的な落とし穴”：正直、ここが一番心配です
ここまで割と前向きに書きましたが、正直、この構想にはかなり重い懸念もあります。
DID/VCの学習コストは、PGPより明らかに高い
PGPは「鍵ペア作って、公開鍵配って、署名して検証する」という比較的素朴な世界観です。
一方DID/VCは、用語だけでもこれです。
- DIDメソッド（did:web, did:ion, did:ethr, did:key, …）
- DID Document
- Verifiable Credential（VC）
- Verifiable Relationship Credential（VRC）
- DID Resolver
- DIDComm / メッセージング基盤
ぶっちゃけ、普通のカーネルコントリビュータがここまで理解したいかというと、かなり怪しいです。
「git commit -SのノリでDID署名できるUX」を提供できるかどうかが、最大の勝負どころですが、
現状のDID/VCエコシステムは、そこまで“開発者フレンドリー”とは言い難いです。
DIDメソッドの乱立と「標準の寿命」問題
カーネルは10年以上のスパンで運用されるインフラです。
対して、DIDメソッド界隈は以下のような世界です。
- メソッドが乱立（did:web, did:ion, did:ethr, …）
- どれが10年後も生きているか、正直誰にも分からない
- Resolverやホスティングの長期運用責任はどこが持つのか
Linux IDの構想では、ひとまずdid:webなどを使いつつ、上位層にDIDComm的なメッセージングを載せるようですが、「この技術スタックが2040年まで持つのか？」という問いに自信を持ってYesと言える人は多くないはずです。
PGP/GnuPGは古くさいけれど、「20年以上とりあえず死んでない」という実績があります。
この「実績の重さ」を超えるには、相当慎重な設計が必要です。
「分散型」と言いつつ、新しい中央集権を生むリスク
Linux IDは、
- 政府発行のデジタルID
- 雇用主（企業）
- Linux Foundation
- 第三者機関
- 既存メンテナ
など、複数のIssuerからVCを発行できる、という柔軟さを売りにしています。
設計思想としてはとても良いのですが、実運用ではこうなる可能性があります。
- 「LF発行のVCがないと、事実上信用されない」
- 「大手企業発行のVCが“実質ルート”みたいな扱いになる」
- 「結局、Issuerリストをメンテする組織の力が強くなる」
つまり、PGPのWeb of Trust的な「みんな勝手にやってね」から、
- 公式Issuer
- ポリシーエンジン
- 信頼リスト
といった、より構造化されたヒエラルキーに寄っていく可能性が高い。
それはそれで現実的ですが、「分散型」を旗印にしながら、別の形の中央集権を作ってしまう懸念は拭えません。
ツールチェーンとエコシステム更新の“静かな地獄”
DID/VCが本格運用されると、変わるのはカーネル開発フローだけではありません。
- ディストロのビルド・署名パイプライン
- CI/CDの署名検証ロジック
- 社内のソースコード署名／リリースフロー
- 各種OSSセキュリティツール（SLSA, SBOMツール, etc.）
これら全部が、「GPGで署名検証」から「DID Resolver＋VC検証」に対応する必要が出てきます。
gpg --verifyで済んでいた処理が、- DID解決
- VC検証
- ポリシールックアップ
に化ける。
正直、これはかなり重いです。
しばらくはPGPとDIDのデュアル運用になるでしょうが、その間はポリシーもツールも2倍複雑になる可能性があります。
それでも「Linuxカーネルがやる」意味は大きい
懸念点ばかり並べましたが、「これをカーネルが真面目に検討し始めた」事実は、やはり無視できません。
- 単に論文やWeb3界隈だけで語られていたDID/VCが、
- 「現実のサプライチェーン攻撃（xzバックドア）」という具体的事件を受けて、
- 世界最大級のOSSインフラプロジェクトのIDレイヤとして候補に上がった
これは、「分散型IDが本当に使い物になるのか？」を測る、最高レベルのリトマス試験紙です。
もしLinuxカーネルが、
- DID/VCベースのLinux IDをうまく運用
- 教育コストとツールチェーンを現実的なレベルに落とし込み
- PGPからの段階的移行シナリオを示す
ことに成功すれば、それは他のOSSコミュニティや企業にもそのままテンプレートとして転用できます。
逆に言えば、ここで転ぶと、
- 「やっぱりDID/VCは複雑すぎて現場には降ろせない」
- 「PGP＋α（Sigstore等）で当面行こう」
という空気がさらに強まるでしょう。
プロダクションで使うか？正直まだ様子見です
自分が企業側のセキュリティ担当／SREの立場だとして、
「来年度から社内のコード署名と開発者IDをDID/VCに統一します」
と言えるかというと、正直まだ完全にNoです。
現時点の立ち位置を整理すると、こんな感じです。
- 今すぐやるべきこと
- xz事件を他山の石にして、PGPベースでもいいので現状の署名フローと権限管理を棚卸しする。
- Sigstore/cosignなど、すでに実用レベルのツールでサプライチェーンセキュリティを底上げする。
- 1〜3年スパンでウォッチすべきこと
- Linux IDのPoCとツールチェーン（git連携、CI連携、ディストロ側の対応）がどう進むか。
- DIDメソッドとResolver実装の“生存率”と、OSSコミュニティでの実運用例。
- 5年スパンで判断すること
- 「PGP中心の世界から降りるかどうか」を決めるのは、そのときにLinuxカーネルと主要ディストロがどこまで移行できているか次第。
ぶっちゃけ、DID/VCを今からプロダクションに全振りするのは、リスクが高すぎます。
ただし、「PGPのままでいいや」と思考停止するのも同じくらい危うい。
自分の立場としてはこうです。
- xz事件やPGP運用の限界を踏まえると、「開発者IDの再設計」が必要なのは完全に同意。
- DID/VCは、その候補の一つとして真面目に検証する価値はある。
- ただし、PGPを一気に捨てるのではなく、
- まずはデュアル署名
- ツールとUXがこなれてから徐々に重心を移す
くらいの、かなり“腰の重い移行”が現実的だと思う。
「Linuxカーネルが分散型IDを試し始めた」というニュースを、
- Web3界隈のバズワードとして消費するか
- 20年以上同じIDモデルに頼ってきたインフラ側の“悲鳴”として受け止めるか
ここでの捉え方が、数年後の自分たちのサプライチェーン設計にそのまま跳ね返ってくるはずです。
PGPに飽きている人ほど、この動きは「飛びつく理由」ではなく、「ちゃんと向き合うきっかけ」として見たほうがいい、というのが自分の結論です。
関連記事
FAQ（よくある疑問）
Q. PGPはもう不要になりますか？
A. すぐに消える可能性は低く、当面はPGPと新方式（DID/VC等）の併用が現実的です。移行は数年スパンの話になりがちです。
Q. Sigstoreがあるのに、なぜDID/VCを検討するの？
A. Sigstoreは実務で強力ですが、OIDC等の中央集権的な信頼の根に依存します。プラットフォーム非依存のID層を持ちたい、という動機がDID/VC側にあります。
Q. 企業が今すぐ着手すべきことは？
A. まずは現状の署名・権限・リリースフローの棚卸しと、監査可能なログ/検証の整備です。その上で既存ツール（例：cosign等）で段階的に改善するのが安全です。
Q. 一番のリスクは何ですか？
A. DIDメソッド乱立やResolver運用など、技術スタックの“寿命”が読みにくい点です。長期運用を前提に、依存先と移行計画を明確にしておく必要があります。
コメント