## 更新履歴 | 日付 | 内容 | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2026-05-06 | 初版作成 | --- ## はじめに 筆者は30年ほど前、仕事でPGP鍵を作って使っていた。当時は単一の鍵ペアを作り、必要に応じて組織の鍵管理者に署名してもらい、相手と鍵交換するという運用を取っていた。 それから長らく PGP から離れ、最近になって個人用の PGP 鍵を新たに作ろうとしたところ、現在の Web 上の解説では**「主鍵（primary key／master key）と副鍵（subkey）を分けて作るのがベストプラクティス」**という記述が随所に見られる。30年前にもこの概念は OpenPGP 規格に存在した様だが、私はそのような運用をしていなかった。 現在のベストプラクティスについて、最初に違和感を覚えたのは、副鍵を分けることのメリットの説明が腑に落ちなかった。「副鍵が漏洩した際にローテーションしやすい」という説明をよく見かけるが、副鍵の秘密鍵が漏れれば副鍵の公開鍵もローテーションせざるを得ず、結局は鍵を作り直すのと同じではないか――そう感じた。 本稿は、この違和感の出発点から始めて、**30年前と現在の PGP 鍵運用の何がどう変わったのか**を整理した記録である。結論を先に言えば、筆者の違和感は「30年間の技術的・社会的変遷を見落としていた」ことから生じていた。鍵そのものの構造が進化したのではなく、PGP を取り巻く**インフラと社会的前提が根本的に変わった**結果として、主鍵・副鍵分離という運用形態が必然になっていた。 本稿は、自分と同じように「かなり以前に PGP を使っていたが、現在のベストプラクティスに戸惑っている」読者に向けて書かれている。同時に、「PGP の歴史を辿りながら現代の運用を理解したい」読者にも有用であることを期待する。 なお、この整理の過程で、もう一つ見えてきたことがある。それは、**「Web of Trust（信用の輪）」という言葉の意味そのものが、この30年で変質している**のではないか、という観察である。 30年前、Web of Trust は「AさんとBさんが、PGP 鍵交換という過程を経てお互いに信用できること」を指した。信用は二人の間に成立し、それが連鎖して「輪」を成す概念だった。 現在、「Web of Trust」が指すものは、しばしば「Aさんの副鍵が、Aさんの主鍵によって証明されていること」になっている様だ。ここに B さんは登場しない。信用は A さん一人の鍵階層の内部で成立し、外部との接続は WKD や keys.openpgp.org といった技術インフラに移譲される。 同じ言葉が、社会的な信頼関係を指すものから、個人内部の暗号学的検証を指すものへと変質した様に思える。これは Phil Zimmermann が PGP 2.0 マニュアルで「emergence（創発）」という言葉に込めた、人と人の関係から自律的に立ち上がる信頼ネットワークというイメージとは、もはや別のものになっている様に感じる。 この観察を念頭に置きながら、本稿を読み進めていただければと思う。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > 本稿は、可能な限り事実情報に基づいて記載を心がけているが、回想的な記事であり記載内容は主観を超えない。私の思い込みも多く含まれているかも知れない。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 結論サマリ **変わったもの：** - **鍵構造**：単一鍵 → 主鍵・副鍵分離（C／S／E／A の役割分離） - **暗号アルゴリズム**：RSA 1024〜2048 → ECC（Ed25519／Curve25519）、将来は PQC へ - **公的識別子のコスト**：ドメイン取得・サーバ証明書取得が高ハードル → コモディティ化（Let's Encrypt の登場） - **鍵配布インフラ**：SKS keyserver の Web of Trust → keys.openpgp.org（Hagrid）／WKD - **メールアドレスの位置づけ**：公開情報 → 認証クレデンシャルの一部 - **信頼の供給源**：他者署名（key signing party 文化） → ドメイン管理者・メールサーバ運用者・対面確認の混合 **変わらないもの：** - **暗号学的本質**：公開鍵暗号の数学的基盤、フィンガープリント検証の必要性 - **本人性確認のコスト**：「この鍵が本当にその人のものか」を保証することの社会的・運用的負担 - **Phil Zimmermann の分散思想の核**：単一の権威（CA）に依存しないという志向は、形を変えて生き続けている **主鍵・副鍵分離の真の意義は、副鍵のローテーションを「不要にする」ことではなく、副鍵をローテーションしても主鍵に紐付いた信頼関係を失わずに済ませることにある。**この意義は、30年前の「組織PGP鍵 = 個人PGP鍵」という運用形態と構造的に等価であり、現代では同じ仕組みを個人内部のミニ PKI として実装している。 --- ## 第1章 30年前のPGP鍵運用 ### 1.1 当時の典型的な鍵構成 1990年代前半の PGP（PGP 2.x）における典型的な鍵構成は、以下のようなものだったと記憶している。 - **単一の鍵ペア**：一つの鍵が証明（Certify）・署名（Sign）・暗号化（Encrypt）のすべてを担う - **アルゴリズム**：RSA のみ（後期で 1024bit、初期は 512〜1024bit）、対称暗号は IDEA、ハッシュは MD5[^23] - **有効期限**：無期限とすることが多かった（失効証明書の管理が困難） 副鍵（subkey）の概念が OpenPGP 規格として明確化されたのは、PGP 5.x の登場とともに 1998 年の RFC 2440 においてである[^24]。それ以前の PGP 2.6.x（RFC 1991, 1996年）には副鍵の概念は無かった[^23]。OpenPGP 規格に副鍵が導入された後も、一般ユーザーレベルでは長らく単一鍵運用が主流だった様に思う。 ### 1.2 信頼の供給：Web of Trustとkey signing party **事実**：当時の PGP 鍵の本人性は、**他者からの署名の蓄積**によって保証されるという思想で運用されていた。 PGP の創始者 Phil Zimmermann が PGP 2.0 マニュアル（1992年9月リリース[^25]）で提唱した **Web of Trust（信頼の輪）** は、中央認証局（CA）に依存せず、利用者同士の相互証明によって公開鍵の本人性を検証する分散型モデルである[^14]。 > As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. (...) This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys. > （参考訳：時が経つにつれ、あなたは他者の鍵を蓄積し、その中の何人かを「信頼できる紹介者」として指定するようになるだろう。(...) これによって、すべての公開鍵に対する分散的・耐障害的な信頼の輪が**創発する**。）[^14] この思想を実装する場として、**key signing party（鍵署名会）** が活発に行われていた。Linux ディストリビューションの開発者会議、暗号愛好家の集まり、活動家のコミュニティなどで、参加者が顔を合わせ、本人確認書類を相互に確認した上で互いの公開鍵に署名し合うイベントである。署名された鍵は SKS keyserver ネットワークに公開され、誰でも検証できるようにされた。 **解釈**：個人の PGP 鍵は、その「他者からの署名のコレクション」そのものが社会的アイデンティティの証明だった。鍵を作り直すことは、このコレクションをゼロから再構築することを意味し、極めて重い行為だった。 ### 1.3 組織運用の事例：「社印」モデル 組織内で PGP を運用する場合、次のような階層構造が採られた（筆者自身が当時運用していた構成）。 1. **「組織を示す PGP 鍵」を作成する**。これは言わば「社印」にあたり、秘密鍵は厳重に保護される。 2. **組織員は各自で個人の PGP 鍵を作り、組織の鍵管理者に「組織を示す PGP 鍵」で署名してもらう**。 3. **対外的には、個人の公開鍵と組織の公開鍵をセットで渡す**。 この構成では、個人の秘密鍵が漏洩したり期限切れになったりした場合、新しい個人鍵を作り直し、再度組織の鍵で署名してもらえば、対外的な信頼関係をある程度維持できる。 **解釈**：これは事実上、**組織内に局所的な PKI（あるいは局所的な Web of Trust）を構築する運用**である。組織鍵が「ルート」として機能し、個人鍵が「エンドエンティティ」として位置付けられる。Phil Zimmermann が嫌ったはずの中央集権的な信頼モデルが、組織という閉じた単位の中では復活していたわけである。 **仮説**：この「組織鍵 = 主、個人鍵 = 従」という構造は、後述する現代の「主鍵 = 主、副鍵 = 従」という構造と**機能的に等価**である。30年前は組織という社会的単位でこれを実装していたものを、現代では個人内部のミニ PKI として実装している――というのが本稿の主たる視点である（第5章で詳述）。 ### 1.4 当時のインフラ前提 30年前の PGP 運用を理解する上で決定的に重要なのは、**当時のインフラが現在とは根本的に異なっていた**という事実である。 | 項目 | 1990年代の状況 | |---|---| | ドメイン取得 | 日本の `.co.jp`（1989年運用開始）は登記簿謄本ベースの審査が必要。`.gr.jp`（1997年12月運用開始）は代表者・副代表者の印鑑登録証明書原本の提出が必要[^26] | | サーバ証明書 | 商用 CA から年数万〜数十万円。本人確認書類（公的書類または領収証など）の郵送が必要 | | HTTPS 普及率 | 当時はごくわずかな大手サイトのみ HTTPS 化されていた（Let's Encrypt 公式の振り返りによれば、2015年時点でも Firefox 接続統計でグローバルに30%未満）[^22] | | 個人サーバ | 自宅 ISDN／専用線、固定 IP の確保は専門家でも一仕事 | | メールアドレス | USENET 投稿者・MLメンバーがメアドを公開するのは当たり前。名刺にも記載 | **事実**：個人がドメインや TLS 証明書という「公的識別子」を手軽に持つことは、技術的にも金銭的にも困難だった。 **解釈**：当時 Web of Trust が必要とされた背景には、Phil Zimmermann の思想的選好だけでなく、**個人が公的識別子を持てない時代の現実的な代替手段**としての側面があった。「ドメインも証明書もない個人」が暗号通信の本人性を保証する手段は、相互の社会的署名のネットワークしか存在しなかった。 **仮説**：もし当時、現在の Let's Encrypt と格安ドメインが存在していたら、Web of Trust はあそこまで重視されなかった可能性が高い。ドメイン管理者による事実上の保証（後述する WKD 的なメカニズム）が、当初から PGP の主たる信頼供給メカニズムになっていたかもしれない。 --- ## 第2章 30年で何が変わったか——五つの技術的・社会的変遷 ### 2.1 暗号アルゴリズムの世代交代 **事実**：30年の間に、PGP で使われる暗号アルゴリズムは複数回の世代交代を経た。 - **1990年代前半（PGP 2.x）**：RSA のみ、IDEA、MD5[^23] - **1990年代後半（PGP 5.x、1997年〜）**：DSA + ElGamal が追加、SHA-1 が利用可能に - **2000年代後半〜2010年代**：RSA 2048bit、後に RSA 4096bit が推奨に - **2010年代後半以降**：ECC（楕円曲線暗号）が GnuPG 2.1（2014年11月）でサポート、**2.3 以降がデフォルト**で ECC（Ed25519／Curve25519）鍵を生成[^13] - **2020年代**：耐量子計算機暗号（PQC）への移行が課題に。RFC 9580 では `pqc` キーワードによる量子耐性暗号化副鍵の生成が言及されている[^7] ECC は RSA 4096bit よりも鍵長が短く、署名・検証も高速で、現時点では同等以上のセキュリティを提供する。なお、ECC（楕円曲線暗号）の理論自体は 1985 年に提唱されているが、**Curve25519（2005-2006）や Ed25519（2011）といった現代の標準曲線は、30年前にはまだ存在しなかった**。GnuPG での ECC 対応は 2.1（2014年11月）以降である[^13]。 ### 2.2 公的識別子のコモディティ化 **事実**：30年で、ドメインと TLS 証明書のコストとハードルは劇的に低下した。 - **ドメイン取得**：gTLD は年数百〜数千円、本人確認は最小限。`.com` や `.net` なら数分で取得可能 - **TLS 証明書**：**Let's Encrypt が 2015年9月14日に最初の証明書を発行**[^20]、**2016年4月12日に一般公開**された[^21]。**ACME プロトコルによる自動化された無料の Domain Validation 証明書**が利用可能となり、現在 Let's Encrypt は世界最大の認証局として、2025年9月末に初めて1日 1000 万枚を超え、以降は頻繁に1日 1000 万枚規模の証明書を発行している[^22] - **HTTPS 普及率**：30年前のごくわずかから、**およそ5年で30%未満から80%へ上昇し、その後80%付近で安定**（Firefox 接続統計ベース）[^22]。Chrome では HTTP サイトに警告が表示される **解釈**：個人が「ドメイン名」と「TLS 証明書」という公的識別子を手軽に保有できるようになった。これは PGP の信頼供給メカニズムにとって決定的な変化である。なぜなら、ドメイン管理者であることが**事実上の本人性証明**になりうるからである（後述する WKD はこれを直接利用する）。 ### 2.3 メールアドレスの位置づけの変化 **事実**：30年前、メールアドレスは「公開してもよい識別子」として扱われていた。USENET、メーリングリスト、論文の連絡先、名刺など、公開が当たり前だった。 現在は状況が逆転している。メールアドレスは： - **Webサービスのログイン ID**として使われる（漏洩 = アカウント乗っ取りの起点） - **二要素認証のリカバリ手段**になっている - **パスワードリセットの最後の砦**である - **HIBP（Have I Been Pwned）に流出履歴が積み上がる対象**になっている。HIBP は 2013 年 12 月に Troy Hunt 氏が公開した無料サービスで、現在約 175 億件の漏洩アカウント情報を集約している（2026年5月時点）[^27] - **スパム・フィッシングの宛先**として価値を持つ **解釈**：メールアドレスは、技術的な変化ではなく**社会的に背負わされた役割の肥大化**によって、「公開してもよい識別子」から「ある程度秘匿すべき認証クレデンシャル」へと変質した。 **含意**：これは PGP の Web of Trust にも逆風となった。「誰が誰の鍵に署名したか」が公開される SKS keyserver 上では、署名グラフが**社会関係性のメタデータ**として漏洩する。 ### 2.4 鍵配布インフラの変容 **事実**：2019年6月、OpenPGP コミュニティの著名な貢献者である Robert J. Hansen と Daniel Kahn Gillmor の証明書（公開鍵）に対し、**証明書スパミング攻撃（certificate spamming／poisoning）**が実行された[^17]。 > In the last week of June 2019 unknown actors deployed a certificate spamming attack against two high-profile contributors in the OpenPGP community (...) This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. > （参考訳：2019年6月最終週、何者かが OpenPGP コミュニティの著名な貢献者2名に対して証明書スパミング攻撃を実行した。この攻撃は OpenPGP プロトコルそのものの欠陥を悪用し、両者の OpenPGP 証明書を「汚染」した。汚染された証明書を脆弱な OpenPGP 実装に取り込もうとすると、その実装は高い確率で原因特定の困難な形で破損する。）[^17] 攻撃の本質は、SKS keyserver ネットワークが「**書き込み専用**」であり、誰でも任意の鍵に対して任意の数の署名を追加でき、しかもそれらを削除する手段がないという設計欠陥にあった。攻撃者は Hansen の鍵に対し約 15 万件、Gillmor (dkg) の鍵に対し約 5.5 万件もの偽署名を付与し、GnuPG クライアントがこの巨大な証明書を取り込もうとして実質的にハングする状態を作り出した。Hansen は次のように悲観的に述べている。 > For me, GnuPG's traditional Web of Trust approach is dead. > （参考訳：私にとって、GnuPG の伝統的な Web of Trust アプローチは死んだ。）[^17] この事件を契機として、新しい鍵配布・検証の仕組みが整備された。 - **keys.openpgp.org（Hagrid）**：第三者署名（Web of Trust の本体）を**意図的にすべて取り除いて配布する**鍵サーバ。電子メール検証によって UID と鍵保有者の対応を確認する。汚染攻撃には強いが、Web of Trust そのものは機能しなくなる[^18]。Sequoia-PGP の `sq` および多くの Linux ディストリビューションの GnuPG では、これがデフォルト鍵サーバとなっている[^18] - **Web Key Directory（WKD）**：メールアドレスのドメインの HTTPS サーバ（`https://example.org/.well-known/openpgpkey/hu/<hash>`）に公開鍵を直接置く方式[^19]。**WKD lookup は GnuPG 2.1.12 以降に対応、2.1.23 以降でデフォルト有効**。WKS サーバ／クライアントツールは **2.1.14 以降**に同梱されている[^19]。`gpg --locate-keys [email protected]` で自動発見できる。組織のドメイン管理者が鍵の公開を制御できるため、企業利用に向いている。Gentoo、Debian、kernel.org、Mailfence などが採用している[^19] - **DANE / OPENPGPKEY DNS レコード**：DNSSEC で署名された DNS レコードに公開鍵を置く方式（普及度は限定的） **解釈**：30年前の Web of Trust は、社会的な相互署名のネットワークによって信頼を供給していた。現代の Hagrid／WKD は、**ドメイン管理者・メールサーバ運用者・TLS 証明書チェーンといった既存インフラ**に信頼供給を委ねている。 ### 2.5 鍵構造の標準化：主鍵・副鍵分離 **事実**：30年前から OpenPGP 仕様には副鍵の概念は存在したが、運用としては単一鍵が主流だった。現在、GnuPG 2.1 以降では、副鍵の発行・管理・スマートカードへの転送・主鍵のオフライン保管などの機能が大幅に整備され、主鍵・副鍵分離が**事実上の標準運用**となっている[^6]。 ベストプラクティスとして広く参照されている Riseup の OpenPGP Best Practices や Debian Wiki の Subkeys ページでは、**主鍵を Certify のみに絞り、Sign／Encrypt／Authenticate はすべて副鍵に分離する**運用が推奨されている[^2][^8]。 --- ## 第3章 OpenPGP鍵の現代的構造 ### 3.1 一つの「OpenPGP鍵」は複数の鍵の集合体 OpenPGP の最新規格である RFC 9580（2024年7月発行、RFC 4880 を廃止・置換）は、一つの「OpenPGP 鍵」を、**一つの主鍵と、それに紐付く 0 個以上の副鍵、および一つ以上の User ID パケット**から構成される複合的なデータ構造として定義している[^5]。 GnuPG 公式マニュアルでも次のように述べている。 > An OpenPGP key is made up of several keys: a primary key, which is used to digitally sign things, and optionally, subkeys that can be used to sign or encrypt things. > （参考訳：OpenPGP 鍵は、デジタル署名に用いる主鍵と、署名や暗号化に用いる副鍵（任意）という、複数の鍵から構成される。）[^1] ### 3.2 Capability（用途フラグ）と役割分離 OpenPGP の各鍵には、**Capability（用途）** を表すフラグが付与される。代表的なものは以下の四種である[^6][^7]。 | フラグ | 意味 | 典型的な配置 | |---|---|---| | **C**（Certify） | 他の鍵や User ID への証明（自己署名・他者署名） | 主鍵にのみ付与 | | **S**（Sign） | データへのデジタル署名（メール・ファイル・コミット等） | 副鍵 | | **E**（Encrypt） | 暗号化（受信メッセージの復号権限） | 副鍵 | | **A**（Authenticate） | 認証（SSH 等での身元証明） | 副鍵 | GnuPG のデフォルトでは、主鍵に「C＋S」（証明と署名）、自動生成される暗号化副鍵に「E」が付与される[^1]。ベストプラクティスとしては、**主鍵を「C」のみに絞り、署名・暗号化・認証はすべて副鍵に分離する**運用が推奨されている[^4][^8]。 ### 3.3 主鍵による副鍵の暗号学的な「結びつき」 副鍵は単に主鍵の「隣に置かれている」のではなく、**主鍵によって暗号学的に署名されている**。RFC 9580 の 5.2.1.8 節では「Subkey Binding Signature（Type ID 0x18）」を以下のように定義する。 > This signature is a statement by the top-level signing key, indicating that it owns the subkey. This signature is calculated directly on the primary key and subkey, and not on any User ID or other packets. > （参考訳：本署名は、最上位の署名鍵による「この副鍵は自分の所有である」という宣言である。User ID その他のパケットは含まず、主鍵と副鍵に対して直接計算される。）[^5] さらに、署名能力を持つ副鍵については、副鍵側からも主鍵への署名（Primary Key Binding Signature, Type ID 0x19）を埋め込むことが**MUST 要件**として規定されており、これを「**クロス署名（cross-certification, back signing）**」と呼ぶ[^5][^9]。これは、攻撃者が他人の公開副鍵を盗用して自分の主鍵に紐付けて公開する攻撃を防ぐための仕組みである[^9]。 --- ## 第4章 Web of Trust の来歴と現在地 ### 4.1 Phil Zimmermann の原典と PKI（X.509）との対比 第1章で触れたとおり、**Web of Trust（WoT）** は PGP の創始者 Phil Zimmermann が 1992年に提唱した分散型信頼モデルである。利用者同士の相互証明によって公開鍵の本人性を検証する[^14]。 特徴は、**集中型の信頼モデルである PKI（X.509 / SSL/TLS 証明書）との対比**で最もよく理解できる。 | 観点 | X.509 PKI（集中型） | Web of Trust（分散型） | |---|---|---| | 信頼の起点 | ルート CA（あらかじめブラウザ等に組み込まれた認証局） | 利用者自身（自分が署名した鍵を起点とする） | | 検証の仕組み | 階層的な証明書チェーン（Root CA → Intermediate CA → End Entity） | 任意の経路長を持つ署名グラフ | | 鍵への裏書き | CA が独占的に行う | 誰でも他人の鍵に署名できる | | 障害耐性 | CA が侵害されると信頼チェーン全体が崩壊 | 一人の利用者が侵害されても全体への影響は限定的 | | 名乗りの正当性検証 | CA の審査プロセスに依存 | 利用者同士の対面確認（key signing party 等） | | 用途の主流 | 公開 Web サイト、コード署名 | 個人間の暗号メール、ソフトウェアパッケージの署名検証 | ### 4.2 「鍵の正当性（validity）」と「保有者への信頼（ownertrust）」の二層構造 Web of Trust を運用する上で最も理解しにくく、しかし最も重要な概念が、**「鍵の正当性（validity）」と「鍵保有者への信頼（ownertrust）」を区別する**ことである。GnuPG 公式マニュアルはこの区別を明示している。 > Trust in the key's owner and the key's validity are indicated to the right when the key is displayed. (...) The four trust/validity levels are abbreviated: unknown (q), none (n), marginal (m), and full (f). > （参考訳：鍵を表示すると、鍵保有者への信頼と鍵の正当性が右側に示される。(...) 四つの信頼／正当性レベルは略号で示される：unknown（q）、none（n）、marginal（m）、full（f）。）[^15] 両者の意味は次のとおりである。 - **Validity（正当性）**：「この公開鍵は、本当にその UID（名前・メールアドレス）の人物のものか」という**鍵そのものへの確信度** - **Ownertrust（保有者への信頼）**：「この鍵保有者は、他者の鍵に署名する際にきちんと本人確認をしてくれる人物か」という**鍵保有者の人物としての信頼度**[^16] 両者を分離している意味は深い。たとえば Bob の鍵について「validity = full」（Bob の鍵は確かに Bob のものだと確信している）かつ「ownertrust = marginal」（だが Bob は他人の鍵に署名する時にあまり慎重ではないかもしれない）という設定が可能である。Web of Trust はこの2軸の組み合わせで動作する。 なお、ownertrust の値はあなたのローカルな信頼判断であり、**鍵にも公開情報にも書き込まれず、あなたの GnuPG ホームディレクトリ内（trustdb.gpg）にのみ保存される**[^16]。誰を信頼するかは個人的な判断であって、第三者と共有すべき情報ではないという思想に基づく。 ### 4.3 検証アルゴリズム GnuPG が公開鍵を「正当（valid）」と判定する条件は、デフォルトで次の二つを満たすことである[^15]。 > A key K is considered valid if it meets two conditions: > 1. It is signed by enough valid keys (...) > - it has been personally signed by you, OR > - it has been signed by one fully trusted key, OR > - it has been signed by three marginally trusted keys; and > 2. The path of signed keys leading from K back to your own key is five steps or shorter. > （参考訳：鍵 K が正当と見なされるのは、次の二条件を満たすときである。1) 十分な数の正当な鍵によって署名されている――(a) あなた自身が署名している、または (b) full 信頼を置いた鍵が一つ署名している、または (c) marginal 信頼を置いた鍵が三つ署名している。2) K からあなた自身の鍵へ至る署名経路が 5 ステップ以下である。）[^15] このパラメータは GnuPG の `gpg.conf` で `marginals-needed`（既定値 3）、`completes-needed`（既定値 1）、`max-cert-depth`（既定値 5）として調整可能である。 ### 4.4 Web of Trust の実用上の限界 Web of Trust は思想的には優美なモデルだが、現代では深刻な問題を抱えている。第2章で述べた **SKS keyserver 汚染攻撃（CVE-2019-13050）** がその代表である。加えて以下の社会的・運用的困難がある。 - **対面で鍵フィンガープリントを確認する文化（key signing party）が衰退**した - **ownertrust の設定を継続的に管理するコスト**が高く、多くの利用者は trustdb を実質的に放棄している - **メタデータの公開**：誰が誰の鍵に署名したかは公開情報であり、これは社会的関係性のグラフを暴露することになる **実務上の落とし所**：グローバルな WoT は事実上機能しなくなったが、**「重要な相手とは個別にフィンガープリントを直接確認し、自分の鍵リングで `--lsign` する」という基本動作は依然として有効**である。グローバルな信頼グラフを構築しようとする野心を捨て、**信頼すべき少数の相手だけに対して局所的に Web of Trust を運用する**方が現実的である。 --- ## 第5章 30年前の運用と現在のベストプラクティスの構造的等価性 ここまで述べてきた30年の変化を踏まえると、興味深い構造的な対応関係が浮かび上がる。**30年前に組織内で行われていた「組織PGP鍵 = 個人PGP鍵」の運用と、現代の「主鍵 = 副鍵」の運用は、機能的に等価である**。 ### 5.1 対応関係 | 層 | 30年前の組織運用 | 現代の主鍵・副鍵分離 | |---|---|---| | 信頼の頂点 | 組織の PGP 鍵（社印）＝厳重保管 | 主鍵 [C]＝オフライン保管 | | 日常運用の鍵 | 個人の PGP 鍵 | 副鍵 [S]／[E]／[A] | | 信頼の伝達手段 | 組織鍵による個人鍵への署名 | 主鍵による Subkey Binding Signature | | 鍵漏洩時の復旧 | 組織管理者に再署名してもらう | 主鍵で新副鍵を署名する | | 上位鍵の漏洩リスク | 組織全体のアイデンティティ崩壊 | 全鍵の信頼関係崩壊 | **事実**：両者は構造的に同じ「二層の信頼アーキテクチャ」を持つ。上位の鍵が下位の鍵に署名し、下位の鍵が日常運用を担う。 ### 5.2 局所的 PKI から個人内部のミニ PKI へ **解釈**：30年前の組織運用は、Phil Zimmermann が嫌ったはずの「中央集権的な信頼モデル」を、組織という閉じた社会的単位の中で復活させていた。**ある意味で、これは局所的な PKI（あるいは局所的な Trusted Introducer モデル）だった**。組織が「ミニ CA」として機能し、組織員の個人鍵が「エンドエンティティ証明書」として機能する。 現代の主鍵・副鍵分離は、この構造を**個人内部に縮約**したものと見ることができる。「組織鍵」だった存在は「主鍵」となり、「個人鍵」だった存在は「副鍵」となった。違いは、信頼の供給単位が組織から個人に移ったこと、そしてその実装が手作業から GnuPG の自動処理に移ったことである。 ### 5.3 構造は同じ、信頼の供給源だけが変わった **仮説**：「副鍵分離」というベストプラクティスは、技術的には新しいものではなく、30年前の組織運用が個人レベルで再実装されたものに過ぎない。新しいのは、その**外側にある信頼供給メカニズム**（ドメイン管理者、メールサーバ運用者、TLS 証明書チェーン）が30年前とは根本的に異なることである。 第1章で述べたとおり、30年前は個人が公的識別子を持てない時代だったため、信頼の供給を「組織」という社会的単位に依存していた。現代は個人がドメインや TLS 証明書を持てるため、組織を介在させずに直接的な信頼供給チャネル（WKD、Hagrid のメール検証）を確立できる。 これが、**「組織鍵を介した署名」から「自分の主鍵による自己署名」への移行**の社会的・技術的背景である。 --- ## 第6章 主鍵・副鍵分離の真の意義 第5章で述べた「30年前の組織運用との構造的等価性」を踏まえて、本章では現代の主鍵・副鍵分離が解決している問題を改めて整理する。これは、本稿の冒頭で筆者が抱いた違和感――「副鍵をローテーションするなら主鍵・副鍵を分ける意味がない」――への直接の回答でもある。 ### 6.1 「ローテーションの必要性」と「ローテーションのコスト」を分離する 副鍵が漏洩した場合、副鍵の公開鍵をローテーションする必要があることは事実である。しかし、「**副鍵をローテーションする必要があるか**」と「**副鍵をローテーションする際のコストがどの程度か**」は別の問題である。主鍵・副鍵を分ける目的は前者ではなく後者にある。 | 観点 | 単一鍵構成 | 主鍵・副鍵分離構成 | |---|---|---| | 鍵漏洩時のリスク | アイデンティティ全体が侵害される | 副鍵が侵害されても主鍵は安全 | | 新鍵を「同一人物のもの」と証明する手段 | なし（鍵移行声明で対外的に告知するしかない） | 主鍵による Subkey Binding Signature で暗号学的に保証 | | 信頼関係 | 全部リセット、再構築が必要 | そのまま継承される | | 鍵サーバ／WKD 経由の伝搬 | 受信者は新鍵をゼロから取得・検証する必要 | `gpg --refresh-keys` または WKD で自動的に同期される | | 通信相手側の作業 | 新しいフィンガープリントの確認・再 trust 設定 | 不要（主鍵フィンガープリントは不変） | 主鍵・副鍵を分けることの本質的な利得は、副鍵公開鍵をローテーションする際の**対外的なコスト（信頼関係の再構築・通信相手側の作業）をゼロに近づけること**にある。 ### 6.2 技術層と社会層の二層構造 副鍵分離のメリットは、**技術層**と**社会層**の二層構造で捉えると見通しがよくなる。 - **技術層**：副鍵が主鍵で署名されている（Subkey Binding Signature）。署名連鎖を辿れば確認可能で、GnuPG が自動的に検証する。 - **社会層**：その主鍵が「本人のもの」であるという認知。これは技術的には自動確認できず、対面でのフィンガープリント確認、Web of Trust の署名連鎖、WKD 経由のドメイン信頼、過去のやり取りの蓄積など、**コストの高い社会的プロセス**を経て確立される。 副鍵分離の本当の意義は、「**社会層の確認結果（『この主鍵は本人のもの』という認知）を、副鍵を交換しても再利用できる**」ことにある。 ``` [受信者側の作業] 社会層：主鍵フィンガープリントを一度だけ確認する（コスト高、ただし1回限り） ↓ この確認結果を再利用 技術層：副鍵が変わるたびに「主鍵→副鍵の署名」を自動検証（コストゼロ） ``` 社会層の確認は一度きりで済み、副鍵交換のたびに必要なのは技術層の自動検証だけになる。受信者側からすれば、「最初に主鍵フィンガープリントを確認した相手」は、その後どれだけ副鍵を入れ替えても**一貫して同じ通信相手として扱える**。 ### 6.3 単一鍵構成（鍵移行声明）との対比：権限の非対称性 ここでもう一段深い疑問が生じうる。「主鍵・副鍵を分けず、単一鍵構成でも、古い鍵を使って新しい鍵に署名すれば、同じ仕組みで本人性を保証できるのではないか？」 実際、これは OpenPGP コミュニティで「**鍵移行声明（key transition statement）**」として運用されている方法であり、Riseup の Key Transition ガイドにも標準的な手順が示されている[^10]。 しかしここに、**鍵漏洩時の権限非対称性**という決定的な落とし穴がある。 | 観点 | 単一鍵構成（鍵移行声明） | 主鍵・副鍵分離構成 | |---|---|---| | 漏洩した鍵 | 古い鍵そのもの | 副鍵のみ（主鍵は安全） | | 攻撃者ができること | 漏洩した古い鍵で「**自分が作った偽の新鍵**」に署名し、正当な後継鍵として配布できる | 副鍵には C（Certify）権限がないため、副鍵では新しい鍵に署名できない | | 防御側の状況 | 「攻撃者が偽新鍵を配布する前に、本人が失効証明書を急いで配布する」という競争状態 | 主鍵は安全なので、落ち着いて副鍵失効＋新副鍵発行ができる | | 受信者側から見える景色 | 本物の新鍵と偽の新鍵の両方が「古い鍵で署名された後継鍵」として届きうる | 主鍵で署名された新副鍵は本人発行のものだけ | 単一鍵構成では「**漏洩した鍵 = 新鍵を発行する権限も漏洩**」となるため、攻撃者と本人が同じ権限を持つ対称な状況に陥る。受信者から見れば、本物の新鍵と偽の新鍵が両方とも「古い鍵で署名された後継鍵」として届きうる――この状態を本人と攻撃者の競争で解決しようとすること自体が、信頼可能な手続きとは言いにくい。 一方、主鍵・副鍵分離では、副鍵漏洩時も**「新副鍵を発行できる権限（＝ C 権限を持つ主鍵）」は本人だけが保持し続ける**。攻撃者は漏洩した副鍵で過去メッセージの復号や同副鍵での署名偽造はできても、「これが正当な後継鍵である」と主張する手段を持たない。 これが、Capability（特に C 権限）を主鍵に集約し、副鍵から切り離すことの**最も本質的な意味**である。役割分離は単なる便宜ではなく、**「漏洩しても権限の階層構造が崩れない」というセキュリティ特性そのもの**を作り出している。 ### 6.4 副鍵分離の三つの利点（総合） 以上を整理すると、副鍵分離の利点は次の三つの組み合わせとして理解できる。 1. **社会層の確認は一度だけ**：「主鍵が本人のもの」を受信者が確認するのは、最初の一回で済む 2. **技術層は自動で完結**：副鍵交換のたびに、Subkey Binding Signature の検証が自動的に行われ、受信者の追加作業はゼロ 3. **権限の非対称性が維持される**：副鍵漏洩時も「新副鍵を発行する権限（C 権限）」は本人だけが持ち続ける これら三つが組み合わさって、「主鍵・副鍵を分けることで、副鍵漏洩への耐性が劇的に上がる」という結論になる。逆に言えば、主鍵・副鍵を分けない構成は、これら三つの利点をすべて失うのと引き換えに、わずかに簡素な鍵管理を選択していることになる。 --- ## 第7章 「自分で署名せざるを得なくなった」時代へ 第5章で述べた「30年前の組織運用との構造的等価性」と、第6章で述べた「副鍵分離の真の意義」を踏まえると、もう一つの大きな変化が見えてくる。**信頼供給の方法が、他者署名から自己署名（＋外部インフラ）へとシフトした**ことである。 ### 7.1 30年前：他者による署名が信頼の主供給源 30年前は、自分の公開鍵に他人（あるいは組織管理者）から署名してもらうことが、PGP 運用の中核だった。鍵に蓄積された他者署名のコレクションが、その鍵の社会的信頼度を決めていた。 ### 7.2 現代：信頼供給の多元化 現代では、「他者による署名」が衰退した代わりに、以下のメカニズムが信頼供給を担っている。 - **ドメイン管理者による事実上の保証（WKD）**：HTTPS でドメイン管理者がその鍵を配信していること自体が一種の保証 - **メールサーバ運用者による保証（keys.openpgp.org）**：そのメールアドレスの受信者であることを電子メール検証で確認 - **TLS 証明書の連鎖**：WKD のサーバが正しい TLS 証明書を持つことが信頼の前提 - **対面または別チャネルによる直接確認**：高い保証が必要な相手に対しては、依然として有効な手段 **事実**：これらはいずれも「個人間の署名」とは異なるメカニズムで本人性を保証している。 **解釈**：これは事実上、**X.509 PKI モデルへの部分的な回帰**である。Web of Trust が縮小した分を、HTTPS や DNS や CA 階層といった既存の集中型インフラが裏側で補完している。 **仮説**：30年前に Phil Zimmermann が嫌った「ゲートキーパー（CA）への依存」は、表面的には Web of Trust の名のもとに排除されたが、現代では**ドメイン管理者・メールサーバ運用者・CA というレイヤー違いのゲートキーパー群への依存**として復活している。違いは、特定の認証局に独占権を与えるのではなく、複数のレイヤーに分散していること。 ### 7.3 メタデータ公開リスクの再認識 第2章で述べたとおり、30年前は「鍵の本人性」が中心リスクで、それを社会的に解決することが合理的だった。今は「メタデータと社会関係性の暴露」が中心リスクで、それを技術的に最小化することが合理的になった。 **リスク像が変わった**ことが、信頼供給の方法を変えた根本的な要因である。「自分の鍵を誰かに署名してもらう」運用は、30年前は積極的に推奨された行為だったが、現代では**社会関係グラフの暴露というプライバシーリスクと表裏一体**になっている。 ### 7.4 時代変化の含意 両者は単に「**何を当たり前のリスクとみなすか**」の前提が違うだけかもしれない。 30年前の運用を経験した者から見て、今の運用が奇妙に映る点： - 「自分で自分の鍵に署名する」のは循環論法に見える - 信頼を社会的に確立せず、技術機構（Subkey Binding Signature）だけで完結させようとしている - key signing party のような「身体性のある信頼確立」が消えた 30年前を知らない人から見て、当時の運用が奇妙に映るであろう点： - 鍵に他人の署名を蓄積することを是とする発想（プライバシー意識の欠如に見える） - 鍵サーバに自分の社会関係グラフを公開する設計（メタデータ漏洩への無頓着に見える） - 対面で集まって鍵を交換する文化（時間コストに見合わないように見える） 筆者個人の評価としては、**現代の運用は30年前よりも妥当**だと考えている。30年前のドメイン取得・サーバ証明書取得の高ハードルが解消され、個人が公的識別子を持てるようになった現在では、社会的関係グラフを暴露せずに本人性を保証する手段が利用可能になった。「自分の鍵を自分で署名せざるを得なくなった」というよりは、「自分で署名できる時代になった」と表現する方が事実に近い。 --- ## 第8章 重要な留意点 ### 8.1 副鍵失効は「過去のメッセージ」を守らない 副鍵を失効させても、**既にその副鍵で暗号化された過去のメッセージは、漏洩した秘密鍵で復号可能なまま**である。これは OpenPGP が前方秘匿性（Forward Secrecy）を持たないことに起因する根本的な制約である[^4]。 > Note that a stolen encryption key is a different problem: even if we revoke the encryption subkey, this will only affect future encrypted messages. Previous messages will be readable by the attacker with the stolen subkey even if that subkey gets revoked, so the benefits of revoking encryption certificates are more limited. > （参考訳：暗号化鍵の盗難は別問題である。暗号化副鍵を失効させても、それは将来の暗号化メッセージにしか影響しない。過去のメッセージは、副鍵が失効されても盗まれた副鍵で攻撃者に読まれてしまうため、暗号化証明書を失効させる効果はより限定的である。）[^4] 副鍵分離は「漏洩時の被害を最小化する」仕組みであって、「過去の機密性を守る」仕組みではない。長期保存される機密通信については、別途追加の防御層（例：個別パスフレーズによるファイル暗号化）が必要である。なお、前方秘匿性が必要な用途では Signal のようなセッション鍵を毎回交換する仕組みを併用すべきである。 ### 8.2 失効証明書の管理 主鍵の秘密鍵そのものを失う（紛失・故障）と、主鍵を失効させることもできなくなる。GnuPG 2.1 以降は鍵生成時に自動で失効証明書（`openpgp-revocs.d` 配下）を生成するが[^7]、これを**安全な場所に別途バックアップしておく**ことが不可欠である。紙への印刷、別ストレージへのコピー等、複数の保管方法を併用することが推奨される[^8]。 ### 8.3 ECC が現代の標準、PQC への移行が将来課題 GnuPG では **2.1（2014年11月）から ECC（楕円曲線暗号）をサポート**し、**2.3 以降はデフォルトで ECC（Ed25519／Curve25519）鍵を生成する**[^13]。RSA 4096bit よりも鍵長が短く、署名・検証も高速で、現時点では同等以上のセキュリティを提供する。特殊な互換性要件（古い OpenPGP 実装との連携等）がない限り、ECC を選択するのが現代的なベストプラクティスである。 ただし、**耐量子計算機暗号（PQC）への移行**は今後の課題である。RFC 9580 では `pqc` キーワードによる量子耐性暗号化副鍵の生成が言及されており[^7]、将来の副鍵ローテーション時に PQC 鍵への移行が選択肢となる。 ### 8.4 鍵伝搬の自動化 副鍵を交換した後、対外的には主鍵の公開鍵情報を鍵サーバに `gpg --send-keys` で送信する、または自分のドメインの WKD 配置を更新する[^19]。受信者側は `gpg --refresh-keys` または `gpg --locate-keys` 等で最新の鍵情報を取得する。これにより、相手が能動的にあなたの新副鍵を取得しに行かなくても、自動的に最新の副鍵公開鍵が同期される。 --- ## 第9章 推奨運用モデル（個人利用） 本章では、ここまでの議論を踏まえた具体的な運用モデルを提示する。本モデルは「他人の PGP 鍵にも署名する場合があり、かつ自身も日常的にメール署名やコミット署名で PGP を使う」という想定運用に対するものであり、そうでない運用には別の最適解がある。 ### 9.1 設計の基本方針 本運用モデルは、以下の四つの方針に基づいて設計される。 **方針1：主鍵はオフライン保管とし、副鍵は YubiKey 等のハードウェアトークン(以下、ハードウェアトークン)に保管する** 副鍵は日常運用で頻繁にメモリ上に展開されるため、PC が侵害された際の秘密鍵流出リスクが構造的に存在する。ハードウェアトークンに副鍵秘密鍵を転送すれば、署名・復号は ハードウェアトークン内部で完結し、PC 側に秘密鍵が露出しない。これは日常運用の鍵こそハードウェアで守るべきという判断である[^28]。 主鍵は「他人の鍵への署名」と「副鍵の発行・失効」のためにのみ使用するため、使うとしても、年に数回使うくらいだろう。この用途に対しては、ハードウェアトークン化よりも air-gapped 環境での運用のほうが、ベンダー独立性とシンプルさの両面で優れると考える。 **方針2：主鍵秘密鍵の保護は、十分なエントロピーを持つパスフレーズに集約する** 主鍵秘密鍵は GnuPG のパスフレーズで暗号化されている。このパスフレーズが**エントロピーとして 128bit を超える強度**（Diceware で 12 単語以上）を持てば、現代の計算資源では総当たり攻撃は実質的に不可能である。ハードウェアトークンが「秘密鍵を物理的に取り出せない」のと同等の耐性を、暗号学的に実現できる。 この方針により、暗号化レイヤーの多重化（USB の暗号化 + GnuPG の暗号化）に伴う「最弱リンク問題」――両レイヤーのうち弱い方のパスフレーズで全体の防御強度が決まってしまう問題――を回避できる。 **方針3：「その時点で存在する鍵は、それぞれ一つ」とし、バックアップは取らない** 主鍵は air-gapped 領域に一つ、副鍵はハードウェアトークンに一つ。複製を作らない設計とすることで、「正本がいくつあるか」「最新版はどれか」という複製管理問題が発生しない。漏洩経路も「定位置からの奪取」に限定され、分析が単純化される。 **方針4：バックアップではなく、定期検証で守る** 「失われた時に取り戻す」（バックアップ）のではなく、「失われていないことを定期的に確認する」（検証）方式を採る。劣化や障害は突然起こるのではなく、定期検証で早期に察知できる。早期察知できれば、「失効」ではなく「正常な更新」として対応できる。 ### 9.2 鍵構成 ``` 主鍵 [C] ECC ed25519 ← オフライン保管（暗号化USBに格納） ├── 副鍵 [S] ECC ed25519 ← ハードウェアトークンに転送（メール署名・コミット署名） ├── 副鍵 [E] ECC cv25519 ← ハードウェアトークンに転送（メール暗号化） └── 副鍵 [A] ECC ed25519 ← ハードウェアトークンに転送（SSH 認証） ``` ### 9.3 鍵生成と展開のフロー 1. air-gapped 環境（後述）で `gpg --full-generate-key --expert` により主鍵（Capability: C のみ、Ed25519）を生成。パスフレーズは Diceware 12 単語以上のエントロピーを持つものとする 2. 同環境で `addkey` により S／E／A の副鍵（それぞれ Ed25519／Curve25519）を追加 3. `gpg --edit-key <fpr>` から `keytocard` で各副鍵をハードウェアトークンの対応スロットに転送（Sign スロット、Encryption スロット、Authentication スロット） 4. 主鍵公開鍵（副鍵公開部分も含む）を `gpg --send-keys` で **keys.openpgp.org に送信**する。`gpg --send-keys` は主鍵と全副鍵の公開部分を一つの集合として送信するため、副鍵公開鍵を個別に登録する必要はない。可能なら自ドメインの **WKD にも配置** 5. air-gapped 環境を撤収。主鍵秘密鍵は air-gapped 環境内の暗号化USBに残し、運用機には持ち出さない 運用機からは、ハードウェアトークン上の副鍵を使って日常の署名・暗号化・認証を行う。 ### 9.4 主鍵保管メディアの運用：暗号化消去アプローチ 主鍵を保管する USB メモリは、**暗号化USBを使用する**が、その目的は通常想定されるものとは異なる。 **目的の転換**： | 観点 | 通常の暗号化USB | 本運用での暗号化USB | |---|---|---| | 目的 | USB 内の情報を**保護**するため | USB 廃棄時に**確実な消去**を実現するため | | パスフレーズの位置づけ | 主鍵を守る防御層 | 廃棄時に破棄する「鍵」 | | パスフレーズの強度 | 高エントロピー必須 | 緩やかでよい（保護目的ではないため） | | 主鍵の防御 | USB 暗号化 + GnuPG 暗号化（多重化） | GnuPG 暗号化のみ（一層集約） | **Crypto-erasure（暗号化消去）の原理**：データを暗号化して保管しておき、廃棄時に**暗号鍵を破棄する**ことで、データそのものは残っていても**復号不可能な状態にする**。NIST SP 800-88（Guidelines for Media Sanitization）でも認められた正式な消去手法である[^29]。 **この運用の本質**：USB の暗号化パスフレーズは「情報保護」目的ではない。USB に保管する主鍵秘密鍵は、別途 GnuPG パスフレーズ（128bit エントロピー）で暗号化されているため、USB の暗号化が破られても主鍵秘密鍵は GnuPG パスフレーズで守られる。USB の暗号化は**廃棄時の確実な消去**のためにのみ存在する。 **メディアローテーションの運用ルール**： - 主鍵は暗号化USBに格納し、air-gapped 環境内でのみ展開する - **少なくとも半年に1回**、暗号化USBから主鍵が読み込めるかを検証する。具体的には、`gpg --list-secret-keys` で認識を確認し、テスト署名でパスフレーズが機能することも確認する - **5年経過したら**、新しい暗号化USBに主鍵を移動する。フラッシュメモリの電荷保持期間（家庭環境での未使用保管における一般的な目安として 5〜10 年程度）を考慮した周期である - 移動完了後、移動元USBの暗号化パスフレーズを「でたらめなものに変更」する。これにより旧USB上の主鍵は復号不可能となる - パスフレーズ変更後の旧USBは、通常の電子機器廃棄ルートで廃棄する **移行手順の詳細**： 1. 新USBを準備、暗号化を設定 2. air-gapped 環境を立ち上げ、旧USBから主鍵を読み込む 3. 主鍵を新USBにコピー 4. 新USBで読み取り検証（GnuPG パスフレーズ入力含む） 5. 新USBの検証が完了したら、旧USBのパスフレーズを変更 6. 旧USBを廃棄 新USBの検証が完了するまで旧USBを破棄しないことで、新USBに何らかの問題があった場合のフォールバックを残す。検証完了後はすぐに旧USBを初期化することで、「その時点で存在する主鍵は一つ」の原則を維持する。 ### 9.5 鍵配布戦略 | 状況 | 推奨される配布手段 | |---|---| | 自分のドメインを持っている | **WKD を主とする**。鍵サーバは補助的に keys.openpgp.org に登録 | | 自分のドメインを持たない | **keys.openpgp.org に登録**し、鍵フィンガープリントを SNS プロフィールやブログに掲載 | | 高い保証が必要な相手との通信 | フィンガープリントを **対面または別チャネル**（電話・既存の暗号通信）で直接確認し、署名を交換 | ### 9.6 想定される事象とその対応 **(a) ハードウェアトークンの破損・紛失** 副鍵が使えなくなった場合の対応： 1. air-gapped 環境を立ち上げ、主鍵を読み込む 2. `gpg --edit-key <主鍵fpr>` から旧副鍵を `revkey` で失効 3. `addkey` で新副鍵を生成（S, E, A それぞれ） 4. 新副鍵を新YubiKeyに転送（`keytocard`） 5. 主鍵公開鍵を `gpg --send-keys` で再アップロード、WKD も更新 6. 通信相手は `gpg --refresh-keys` で自動的に新副鍵を取得 主鍵が安全であれば、Web of Trust 上の信頼関係を保ったまま副鍵を入れ替えられる。これは副鍵分離の本来の利点がそのまま機能する場面である。 **(b) 主鍵USBの障害（読み取り不能）** 定期検証で主鍵USBが読み取れない／劣化していると判明した場合の対応： - 5年到達前であれば、新USBへの移行作業を前倒しで実施（9.4 節の手順） - 既に読み取り不能な状態であれば、主鍵を含む鍵全体の再構築が必要 「主鍵を失う」リスクは「その時点で存在する主鍵は一つ」という方針に内在するが、現代の鍵配布インフラでは、主鍵を失うことの影響は30年前ほど大きくない。第2章で述べたとおり、グローバルな Web of Trust は実質的に縮小しており、WKD や keys.openpgp.org への再登録と、通信相手への新フィンガープリント通知で、対外的な復旧は完了する。「他人の鍵への署名」を年に数回しか行わない想定運用では、再構築の影響は限定的である。 **(c) パスフレーズの「ど忘れ」** 主鍵パスフレーズは年に数回しか入力しないため、ど忘れリスクが構造的に高い。半年ごとの定期検証では、**実際にパスフレーズを入力して動作確認する**ことで、ど忘れを早期発見できる。パスフレーズ自体の保管方法は、各人のマスターパスフレーズ管理方針に従う（本稿の対象外とする）。 --- ## おわりに——変わったもの、変わらないもの 30年ぶりに PGP 鍵を作ろうとして抱いた違和感は、最終的に「30年間の技術的・社会的変遷を見落としていた」という認識に至った。 **変わったもの**は、鍵そのものの構造（単一鍵から主鍵・副鍵分離へ）だけではなく、その背景にあるインフラと社会的前提だった。ドメインと TLS 証明書のコモディティ化、メールアドレスの認証クレデンシャル化、SKS keyserver 汚染攻撃を経た鍵配布インフラの再構築、key signing party 文化の衰退――これらが組み合わさって、現代の主鍵・副鍵分離という運用形態が必然となった。 **変わらないもの**は、暗号学の本質と、本人性確認のコストだった。Phil Zimmermann が分散思想を掲げた30年前と同じく、「この鍵が本当にその人のものか」を保証することは依然として社会的・運用的に重い課題である。形を変えながらも、信頼の供給という根本問題は解消されていない。 筆者個人にとって興味深かったのは、**30年前に組織内で実装していた「組織PGP鍵 = 個人PGP鍵」の構造が、現代の主鍵・副鍵分離と機能的に等価**だったことである。当時は組織という社会的単位で実装していた二層の信頼アーキテクチャを、現代は個人内部のミニ PKI として実装している。違いは、信頼の供給単位が組織から個人に移ったこと、そしてその実装が手作業から GnuPG の自動処理に移ったことである。 この30年で PGP は確かに進化したが、それ以上に **PGP を取り巻く世界が変化した**。新しい鍵を作るのは、その変化した世界に自分の暗号運用を再適合させる作業である。 --- ## 本稿の位置づけ 本稿は、現代の OpenPGP/GnuPG コミュニティで標準的に推奨される構成として、主鍵 Ed25519 + 副鍵 Ed25519/Cv25519 のモデルを案内した。これは GnuPG 2.3 以降のデフォルト選択でもあり、暗号学的にも望ましい設計（NIST 曲線への懸念回避、定数時間実装、設計の透明性）を持つ。 ただし、運用環境によっては別の選択が必要になることがある。たとえば、副鍵を保管するハードウェアトークンが Curve25519/Ed25519 に対応していない場合や、OpenPGP カードを X.509/PKCS#11 用途と併用する場合（Linux カーネル署名、クライアント証明書認証等）には、NIST P-384 等の曲線を選ぶ必要がある。 筆者自身は、PKCS#11 用途との併用と、使用するスマートカードの曲線対応の都合から、副鍵を NIST P-384 で構成しているが、これは個別の事情に基づく選択である。**一般的な読者には、本稿で述べた標準構成（Ed25519/Cv25519）を推奨する**。 設計思想――主鍵を air-gapped 領域でのみ扱い、副鍵をハードウェアトークンに格納し、複数の信頼供給チャネルを併用し、バックアップではなく定期検証で守る――は、曲線選択に関わらず共通する。本稿が論じてきたのは、このような構造そのものであり、特定の曲線や特定のハードウェアトークンに固有の話ではない。 --- ## 脚注 [^1]: The GNU Privacy Handbook, "Key Management" https://www.gnupg.org/gph/en/manual/c235.html （2026-05-02 閲覧） [^2]: Debian Wiki, "Subkeys" https://wiki.debian.org/Subkeys （2026-05-02 閲覧） [^3]: Kicksecure Wiki, "Air Gapped OpenPGP Key" https://www.kicksecure.com/wiki/Air_Gapped_OpenPGP_Key （2026-05-02 閲覧） [^4]: anarcat, "Strategies for offline PGP key storage" (LWN.net 掲載版) https://lwn.net/Articles/734767/ （2026-05-02 閲覧） [^5]: IETF RFC 9580, "OpenPGP" (2024-07), Section 5.2.1.8 Subkey Binding Signature, Section 5.2.1.9 Primary Key Binding Signature https://www.rfc-editor.org/rfc/rfc9580.html （2026-05-02 閲覧） [^6]: GnuPG Documentation, "OpenPGP Key Management" https://gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html （2026-05-02 閲覧） [^7]: 同上（`change-usage` コマンドおよび `--quick-add-key` の usage 引数仕様部分、`pqc` キーワード関連の記述） [^8]: Riseup, "OpenPGP Best Practices" https://riseup.net/en/security/message-security/openpgp/best-practices （2026-05-02 閲覧） [^9]: GnuPG, "Signing Subkey Cross-Certification" (FAQ) https://www.gnupg.org/faq/subkey-cross-certify.html （2026-05-02 閲覧） [^10]: Riseup, "Key Transition" https://riseup.net/en/security/message-security/openpgp/key-transition （2026-05-02 閲覧） [^11]: Mike Ross, "How to create a GPG master key and subkeys" https://mikeross.xyz/create-gpg-key-pair-with-subkeys/ （2026-05-02 閲覧） [^12]: Debian / Riseup 共同ドキュメント, "Using the OpenPGP card with subkeys" https://we.riseup.net/debian/using-the-openpgp-card-with-subkeys （2026-05-02 閲覧） [^13]: GnuPG Wiki, "ECC"（"GnuPG supports ECC since version 2.1 and creates ECC keypairs by default since version 2.3." と明記） https://wiki.gnupg.org/ECC （2026-05-02 閲覧） [^14]: Wikipedia, "Web of trust"（Phil Zimmermann による PGP 2.0 マニュアル原典の引用を含む） https://en.wikipedia.org/wiki/Web_of_trust （2026-05-02 閲覧） [^15]: The GNU Privacy Handbook, "Validating other keys on your public keyring" https://www.gnupg.org/gph/en/manual/x334.html （2026-05-02 閲覧） [^16]: GPGTools Support, "What is Ownertrust? Trust-levels explained" https://gpgtools.tenderapp.com/kb/faq/what-is-ownertrust-trust-levels-explained （2026-05-02 閲覧） [^17]: Robert J. Hansen, "SKS Keyserver Network Under Attack" (CVE-2019-13050) https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f および Red Hat Customer Portal 解説 https://access.redhat.com/articles/4264021 （2026-05-02 閲覧） [^18]: keys.openpgp.org, "Usage" https://keys.openpgp.org/about/usage/ （2026-05-02 閲覧） [^19]: GnuPG Wiki, "WKD (Web Key Directory)"（"WKD lookup is implemented in GnuPG since v2.1.12. It is enabled by default since 2.1.23. (...) WKS server and client tools are part of GnuPG since v2.1.14" と明記） https://wiki.gnupg.org/WKD （2026-05-02 閲覧） [^20]: Let's Encrypt, "Updated Let's Encrypt Launch Schedule" (2015-08-07)（最初の証明書発行を 2015-09-07 週として再設定。実際の最初の公的に信頼された証明書は 2015-09-14 発行） https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html （2026-05-02 閲覧） [^21]: Wikipedia, "Let's Encrypt"（一般公開日 2016-04-12 等の沿革） https://en.wikipedia.org/wiki/Let%27s_Encrypt （2026-05-02 閲覧） [^22]: Let's Encrypt, "10 Years of Let's Encrypt Certificates" (2025-12-09)（HTTPS 普及率推移、発行枚数統計を含む） https://letsencrypt.org/2025/12/09/10-years （2026-05-02 閲覧） [^23]: IETF RFC 4880, "OpenPGP Message Format" (2007-11), Section 1.1 Terms（"PGP 2.6.x (...) used only RSA, MD5, and IDEA for its cryptographic transforms. An informational RFC, RFC 1991, was written describing this version of PGP."） https://www.rfc-editor.org/rfc/rfc4880.html （2026-05-02 閲覧） [^24]: IETF RFC 2440, "OpenPGP Message Format" (1998-11) https://www.rfc-editor.org/rfc/rfc2440 および OpenPGP for application developers, "A high-level view"（"In July 1997, a process to produce an open standard under the then new name OpenPGP was started, resulting in RFC 2440 'OpenPGP Message Format', published in November 1998."） https://openpgp.dev/book/openpgp.html （2026-05-02 閲覧） [^25]: Phil Zimmermann, "PGP Marks 10th Anniversary" (2001-06-05)（"Fifteen months later, in September 1992, we released PGP 2.0 (...) PGP 2.0 had the now-famous PGP trust model, essentially in its present form."） Linux Today 掲載版 https://www.linuxtoday.com/security/phil-zimmerman-pgp-marks-10th-anniversary/ （2026-05-02 閲覧） [^26]: JPNIC, "JPドメイン名の歴史"（属性型 JP ドメイン名 GR の運用開始は 1997年12月） https://www.nic.ad.jp/ja/dom/rekishi.html および エックスサーバー, "co.jp/or.jp/ac.jp/ed.jp/ne.jp/gr.jpなどの属性JPドメインを取得する際に、書類の提出は必要ですか？"（gr.jp は代表者・副代表者の印鑑登録証明書原本の提出が必要） https://www.xserver.ne.jp/support/faq/domain_take_jp_process.php （2026-05-02 閲覧） [^27]: Have I Been Pwned, "Who, What & Why" および Wikipedia, "Have I Been Pwned?"（2013年12月4日 Troy Hunt 氏が公開、Adobe Systems 漏洩を契機として開始） https://haveibeenpwned.com/About および https://en.wikipedia.org/wiki/Have_I_Been_Pwned （2026-05-02 閲覧） [^28]: Yubico, "OpenPGP - Yubico Developers"（YubiKey 5 シリーズの OpenPGP Card 仕様対応、Ed25519／Curve25519 サポート、署名・暗号化・認証スロットの仕様） https://developers.yubico.com/PGP/ （2026-05-02 閲覧） [^29]: NIST Special Publication 800-88 Revision 2, "Guidelines for Media Sanitization" (2025-09-26 発行、Rev. 1 を置換) https://csrc.nist.gov/pubs/sp/800/88/r2/final および NIST SP 800-88 Rev. 2 PDF https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf 。Cryptographic Erase（CE、暗号化消去）は Purge 区分の主要な手法として規定されている（"3.2 Cryptographic Erase" 節）。 （2026-05-02 閲覧）