# PGP副鍵の有効期間——ベストプラクティス調査 ## 更新履歴 | 日付 | 内容 | | ---------- | ---- | | 2026-05-09 | 初版作成 | | 2026-05-09 | 訂正：GnuPG の v5 鍵生成に関する記述（結論サマリ第8段落および第4.1.1節）を修正。実検証および脚注 [^18][^19] の原典再確認に基づく事実訂正。詳細は文末の「訂正履歴」を参照 | | 2026-05-09 | 追加検証：GnuPG 2.5.19（PQC 対応ビルド）で PQC ハイブリッド鍵生成の実検証を実施。「主鍵 v4 + PQC 副鍵 v5」というハイブリッド構造であることを確認。詳細は文末の「訂正履歴」内の追加検証セクションおよび第4.1.1節を参照 | | 2026-05-09 | 再訂正：GnuPG 2.5 系を「development branch」と記述していたが、GnuPG プロジェクトの公式 Download ページでは GnuPG 2.5 系が "stable"、GnuPG 2.4 系が "oldstable" と分類されており、誤りであった。該当箇所（訂正履歴セクション内および第4.1.1節）を「PQC 対応の現行 stable」等の表現に訂正。脚注 [^25] を追加 | | 2026-05-10 | §1.1「副鍵に有効期限を設けるべき理由」を新設。副鍵特有の事情（侵害可能性、Web of Trust 維持、Forward Secrecy の不在の時間的補完）／主鍵と共通する一般的理由／反論側の見解（B. Walzer 論考）の三観点から論考を整理。draft-brown-pgp-pfs が Expired となった経緯（IESG による standards track 差し戻し）と現在の IETF OpenPGP WG charter での Forward Secrecy 再活性化にも言及。§1.1.3(2) に GnuPG が副鍵単独の失効証明書を自動生成しないという OpenPGP 設計上の非対称性を補足。§1.1.3「本節の結論」に筆者の運用観点として三つの実務的理由（ハードウェアトークンの予防保全、副鍵流出時の失効訓練、PGP 鍵運用技術力の継続確認）を追記し、技術力継続確認の項目に主鍵取り出しが User ID/Photo ID 等の付加データ見直し機会としても機能することを補足。脚注 [^26]〜[^33] を追加 | --- ## はじめに PGP副鍵（subkey）の有効期間をどう設定するかは、主鍵・副鍵分離運用を採用した時点で必ず直面する設計判断である。短すぎれば管理負担が増え、長すぎればローテーションの利点が失われる。本稿は、OpenPGP コミュニティ・主要なディストリビューション・著名な実践者がどのような期間を推奨しているか、その理由とトレードオフを整理し、実務上の判断材料を提供することを目的とする。 なお本稿は概要レベルでの調査であり、公開資料・公式ドキュメント・著名な実践者の見解を整理することを主眼としている。各見解の出典は脚注に示すが、個別実装の細部までは追わない。 また、本稿で述べる技術的挙動（鍵指紋が Public Key Packet のみから計算されること、Renewal で副鍵の鍵指紋が不変であること、SSH 認証時に PGP 有効期限が検査されないこと等）について、筆者自身による実機での実験・検証は十分には行っていない。これらの挙動は OpenPGP 仕様（RFC 9580）および公式ドキュメント・主要実装の解説に基づく整理であるが、ツールのバージョンや実装の差異によって挙動が異なる可能性がある。読者が自身の運用に適用する際は、自身の環境・ツールバージョンで挙動を確認することを推奨する。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 結論サマリ **主流の推奨は「2年以下」**：Riseup OpenPGP Best Practices[^1]、drduh/YubiKey-Guide[^2]、GPGTools の延長機能のデフォルト[^3] のいずれも、2年を中心とした期間を推奨している。 **より短期を推奨する見解（≒1年以下）**：Simon Josefsson は100日というかなり短い期間を実践し、その3つの理由（失効通知の素早い伝播、暗号設定変更の素早い反映、長期間の鍵管理への自信のなさ）を挙げる[^4]。Ingo Klöcker（KDE）も commit 署名用に1年を実験的に採用している[^5]。 **長期を許容する見解（3〜5年）**：Gentoo の GLEP 63 では、当初（2013年）は「最大5年」が規定されていた[^6]。2018年7月の更新議論で「2年期限を必須に変更」する提案が出され、現行版では主鍵・副鍵ともに「900日（約2.5年）」が最大とされている[^24]。ディストリビューション運用としての規定上限は時代とともに短縮傾向にある。 **無期限は推奨されない**：失効証明書の伝播経路として、有効期限切れによる再取得の慣性化は重要な役割を果たす。鍵を更新する機会がないと、利用者がキーサーバから refresh する動機が失われ、たとえ失効証明書を発行しても周知されない[^4]。 **2026年現在の追加論点**：量子耐性暗号（PQC）への移行が現実の課題となりつつある。2025年6月、IETF の OpenPGP PQC ドラフト（draft-ietf-openpgp-pqc）は v12 版で informational から standards-track に移行した[^7]。Sequoia PGP は2025年11月に PQC 対応のプレビュー版（sequoia-sq 1.4.0-pqc.1）を公開[^8]、Red Hat も RHEL 10 で PQC 対応を段階的に展開している[^9]。RFC化は Sequoia によれば2026年前半が予測されている[^8]。今後数年内に副鍵を PQC 対応のものに置き換える機会が訪れる可能性が高く、副鍵の有効期間はこの移行リズムとも整合させる価値がある。 **ただし注意点**：OpenPGP 標準には現在、IETF 公式の RFC 9580 / draft-ietf-openpgp-pqc 系統と、Werner Koch（GnuPG メンテナ）が主導する LibrePGP 系統の二つの流れがある。両者は鍵フォーマット（GnuPG 系の v5・RFC 9580 系の v6）や PQC 実装で非互換が生じている。ただし、GnuPG 2.4.x 系の通常鍵生成（Ed25519 等）におけるデフォルト鍵フォーマットは v4 のまま維持されており、v5 鍵が生成されるのは PQC 鍵生成等の特定の条件下である（第4.1.1節を参照）。副鍵ローテーションの計画では、自身が使うツールチェーン（GnuPG か Sequoia 系か）を踏まえて検討する必要がある[^18][^19]。 **実務上の落としどころ**：用途・脅威モデル・運用負担のバランスから、**2年が最も広く支持されているデフォルト**である。短期化（1年）は「鍵管理の慣性を保ち、暗号設定変更を反映しやすくする」という運用上の利点を狙う場合に選択される。3〜5年といった長期の選択も許容範囲内ではあるが、主流からはやや長めとなり、後述する論点（暗号アルゴリズム選好の更新頻度、失効証明書の伝播経路、運用慣性の維持）とのトレードオフを意識する必要がある。 **参考：PGP 主鍵の有効期限について**：本稿は PGP 副鍵の有効期間を主題としているが、主鍵（Certify Key、Primary Key）の有効期限についても二つの流派があるため、副鍵の設計と一体で検討する価値がある。 - **主鍵を無期限とする派**（drduh/YubiKey-Guide など）：主鍵は自分自身の有効期限を自分で延長できるため、有効期限を設定しても攻撃者に対する強制的な失効効果としては機能しない。drduh は「pointless（無意味）」と表現する[^2]。したがって有効期限を設定する積極的な意味はないとする - **主鍵にも有効期限を設定する派**（Riseup、Simon Josefsson、Alex Cabal など）：主鍵秘密鍵と失効証明書を**同時に喪失**した場合、本人ですら鍵を「死なせる」ことができなくなる。無期限の鍵がインターネット上に永遠に残ってしまう事態を防ぐ保険として、自動的に「死ぬ」仕組みを組み込むべきとする[^1][^4] 両者の対立は本質的なものではなく、**失効証明書の管理体制**を前提条件とした判断の違いと整理できる。失効証明書を主鍵秘密鍵とは別の安全な場所に確実に保管できる前提なら無期限派、人間は失効証明書を失うこともあるという現実を前提とするなら有期限派、と読み替えると両者は両立する。 なお、主鍵の有効期限と副鍵の有効期限は OpenPGP 仕様上、独立に設定可能である（両者とも自己署名のサブパケットとして格納される）。ただし運用上は、主鍵を取り出すタイミング（=副鍵の Renewal/Rotation のタイミング）と主鍵自身の Renewal タイミングを揃えると、オフライン作業の回数を減らせる利点がある。 --- ## 第1章 OpenPGP仕様における有効期限の位置づけ OpenPGP 規格（RFC 9580、旧 RFC 4880）では、鍵の有効期限は **Key Expiration Time サブパケット** として自己署名（self-signature）に格納される[^10]。重要な点は以下である。 - 有効期限は鍵生成時刻からの相対秒数で表現され、自己署名の中に置かれる - 有効期限の値が0、または当該サブパケットが存在しない場合は「期限なし」として扱われる - 有効期限は **後から変更可能**（自己署名を作り直すことで延長・短縮ができる） - 鍵の有効期限が切れても、その鍵で**過去に**作られた署名や暗号化メッセージの検証・復号は可能[^11] この仕様上の特徴から、有効期限は「セキュリティの本質的な制限」というより「**運用上の同期メカニズム**」として機能する。具体的には、次の三つの効果が期待される。 1. **失効証明書の伝播経路**：有効期限が切れる前に利用者がキーサーバから鍵を refresh する動機が生じ、その際に失効証明書も同時に取得される 2. **暗号アルゴリズム選好の更新経路**：有効期限の更新と同時に、自己署名内の暗号アルゴリズム選好（preferred hash/cipher algorithms）も更新される[^4] 3. **鍵管理慣性の維持**：定期的に主鍵を取り出して操作することで、運用手順を忘れず、ハードウェアの動作確認も兼ねられる ### 1.1 副鍵に有効期限を設けるべき理由 第1章前段では、OpenPGP 仕様において有効期限が「Key Expiration Time サブパケットとして自己署名に格納される」「期限切れの鍵で過去に作られた署名や暗号化メッセージは依然として検証・復号可能」といった仕様上の挙動を整理した。本節では、その挙動を踏まえて「**副鍵に有効期限を設けるべき理由**」を、副鍵特有の論点・主鍵と共通する論点・反論側の論点の三方向から整理する。 主鍵の有効期限については、結論サマリで述べたとおり「設定する派」と「設定しない派」がある。一方、副鍵については主流の見解として「有効期限を設定する」が共有されているが、その理由を体系的に整理した文献は意外に少ない。本節は、副鍵の有効期間を判断する際の出発点となる「なぜ設けるのか」を、改めて整理することを目的とする。 #### 1.1.1 副鍵特有の事情からの理由 主鍵では得られない、副鍵に固有の論点として以下の三つが挙げられる。 **(a) 副鍵は主鍵より侵害される蓋然性が高い** 主鍵・副鍵分離運用の前提として、主鍵はオフライン保管され、副鍵は日常運用で持ち歩かれる（YubiKey 等のハードウェアトークンに格納される）。その結果、副鍵は主鍵よりも侵害される機会が多い。 IETF の draft-dkg-openpgp-revocation（Daniel Kahn Gillmor および Andrew Gallagher 著）は、副鍵が主鍵から独立して侵害されうる事実を明記している。 > A Subkey packet may be revoked because its private key material has been compromised. It is possible for a Subkey to be compromised without the Primary Key being affected, for example if the private Subkey and Primary Key material are stored on separate devices.[^26] > （参考訳：副鍵パケットは、その秘密鍵材料が侵害されたという理由で失効されうる。例えば副鍵秘密鍵材料と主鍵秘密鍵材料がそれぞれ別のデバイス上に保管されている場合のように、主鍵が無事のまま副鍵が侵害されることはあり得る） 副鍵に有効期限を設けることは、こうした「副鍵単独の侵害」が起きた可能性を**時間的に区切る**役割を担う。仮に侵害に気付かずとも、有効期限を機に副鍵を入れ替えることで、被害が無限に拡大するのを防ぐ意味がある（解釈）。 **(b) 副鍵の Renewal/Rotation は Web of Trust を維持したまま行える** 主鍵を入れ替える場合、それまで他者から得てきた認証署名（Web of Trust の構成要素）を全て失う。一方、副鍵を入れ替える場合は、認証署名は主鍵にひもづいているため失われない。Gentoo Wiki の GLEP 63 ベースの鍵生成手順は、この点を次のように明示している。 > As certifications by other users are tied to the primary key, as components structured below the User ID and User Attribute, this allows for key-rotation without losing existing certificates of the key, e.g. in the event of a key compromise due to loss of a device.[^27] > （参考訳：他者による認証は主鍵にひもづく――User ID および User Attribute の下位コンポーネントとして構造化される――ため、デバイス紛失等による鍵侵害があった場合でも、既存の認証を失うことなく鍵のローテーションが可能となる） つまり**「副鍵だけは比較的低コストで入れ替えられる」**という副鍵特有の性質が、副鍵に有効期限を設ける運用の前提条件になっている（解釈）。主鍵には適用しがたい論理が、副鍵には自然に適用できる。 **(c) Forward Secrecy の不在を時間的に補う** OpenPGP には Forward Secrecy（前方秘匿性）がない（[[30年ぶりのPGP鍵——主鍵・副鍵分離はなぜベストプラクティスになったか]]参照）。仮に暗号化副鍵が将来漏洩した場合、それまでに暗号化された全メッセージが復号可能となる。この性質を時間的に区切るのが、副鍵の定期ローテーションの根拠である。 この発想は新しいものではない。2001 年に IETF Internet-Draft として提出された Brown et al. の「Forward Secrecy Extensions for OpenPGP」（draft-brown-pgp-pfs-03）は、すでに「副鍵に短い有効期限を設定し、期限切れと同時に秘密鍵を確実に消去する」という方式を提案していた[^28]。 > If expired keys are securely deleted, attackers will never be able to retrieve them to decrypt captured ciphertext. Therefore when a public encryption key expires, an OpenPGP client MUST securely wipe the corresponding private key.[^28] > （参考訳：期限切れの鍵が確実に消去されれば、攻撃者がそれを取得して捕獲済みの暗号文を復号することはできない。したがって、公開暗号化鍵が期限切れになったとき、OpenPGP クライアントは対応する秘密鍵を確実に消去しなければならない） なお、このドラフトは IETF の正式採用には至らずに Expired となっている[^28]。当時の OpenPGP WG は Informational RFC としての公開を推奨したものの、IESG（Internet Engineering Steering Group）が「standards track で扱うべきか WG が改めて評価せよ」と差し戻したことで WG 内の合意形成が進まず、2002 年 4 月に最終版 -03 が期限切れとなった、という経緯である[^31]（事実）。一方、Sequoia PGP の Justus Winter は 2018 年に同手法を再評価し、副鍵に短い有効期限を設定することが OpenPGP において Forward Secrecy を近似する実用的手法であることを示している[^29]。なお現在の IETF OpenPGP WG は、2023 年の rechartering 以降の charter で Forward Secrecy を in-scope トピックとして再び明示しており、25 年越しに標準化議論が動き始めている[^32]（事実）。drduh/YubiKey-Guide が「PGP には Forward Secrecy がないため副鍵をローテーションする」と述べる際の論理的背景は、この系譜にある（§2.2 を参照）。 #### 1.1.2 一般的な鍵管理上の理由（主鍵と共通） 第1章前段で示した三つの効果（失効証明書の伝播経路／暗号アルゴリズム選好の更新／鍵管理慣性の維持）は、主鍵だけでなく副鍵にも当てはまる。 特に副鍵の文脈では、有効期限切れに伴う Renewal や Rotation のたびに、利用者は主鍵を取り出す必要がある（オフライン保管された主鍵で新しい自己署名を作成するため）。これにより、主鍵を取り出す手順を忘れず、ハードウェアの動作確認も兼ねられる、という鍵管理慣性の維持効果は、主鍵側よりむしろ副鍵側の方が強く現れる（解釈）。 #### 1.1.3 過度な期待への戒め——反論と限界 副鍵の有効期限について、本稿が依拠する見解とは反対に「**有効期限は不要、または有害である**」とする見解も存在する。代表的論考として、B. Walzer による「PGP Key Expiry is a Usability Nightmare」（The Call of the Open Sidewalk、2026年3月最終更新）が挙げられる[^30]。同論考は、副鍵分離スキーム（master identity scheme）であっても有効期限は意味を持たない、と主張する。その論点は次の通りである。 **(1) 攻撃者は有効期限を変更できる** > Key expiry is mostly about when the user loses their secret key information. In particular, it doesn't help in the case where an attacker gets access to the secret key information. Such an attacker can extend the expiration date to whatever extent they desire. (...) The only real cure in this case is key revocation.[^30] > （参考訳：鍵の有効期限は主に利用者が秘密鍵情報を失う場合に関するものである。特に、攻撃者が秘密鍵情報にアクセスした場合には何の助けにもならない。そのような攻撃者は有効期限を望むだけ延長できる。(...) この場合の真の対処は鍵の失効だけである） これは事実として正しい。**有効期限はセキュリティの本質的制限ではなく**、副鍵秘密鍵を保有する者は本人であれ攻撃者であれ、有効期限を任意に延長できる。 **(2) 副鍵の dead-man switch 効果は主鍵より弱い** 結論サマリで触れたように、主鍵の有効期限は「主鍵秘密鍵と失効証明書を同時に喪失した場合の保険」として機能する。一方、副鍵の場合、主鍵が生きていれば副鍵は再発行できるため、副鍵の有効期限が「保険」として機能する場面は限られる。Walzer はこの点について、副鍵分離スキームが想定通り機能している限り副鍵の有効期限が独自の価値を発揮する場面はほぼない、と指摘している[^30]（要約）。 なお、GnuPG 2.1 以降が `~/.gnupg/openpgp-revocs.d/` に自動生成する失効証明書は **主鍵を失効させるための証明書**（Key Revocation Signature, type 0x20）であり、副鍵単独の失効証明書は自動生成されない[^33]。これは「副鍵の失効は主鍵が生きていればその場で Subkey Revocation Signature（type 0x28）を発行できるため、事前エスクローは不要」という OpenPGP の設計思想を反映している（事実）[^26]。この設計上の非対称性は、副鍵の有効期限を「保険」として位置づけることの限界を裏付ける（解釈）：副鍵側には事前の失効証明書という運用がないため、主鍵が使えない状況に陥った場合、副鍵失効署名も発行できない。すなわち、副鍵の有効期限が「保険」として独立に機能する場面は、主鍵側よりさらに限定的である。 **(3) ユーザビリティ上の負担** Walzer は実例として、自身の友人との XMPP 上での PGP 通信実験で、2年期限のデフォルトに従って鍵を生成した結果、2年後に通信が突然破綻した経験を挙げ、利用者に対する「時限爆弾」と表現する[^30]。 > It also occurred to me that key expiry might not just be a disaster but a crisis. Encrypted material is often important material. Suddenly losing the ability to use the system that securely transfers such material could be a serious problem.[^30] > （参考訳：鍵の有効期限は単なる災難ではなく危機ともなりうる、ということに気付いた。暗号化された素材はしばしば重要なものである。そのような素材を安全に転送するシステムを使う能力を突然失うことは、深刻な問題となりうる） **(4) 暗号アルゴリズム陳腐化対応との独立性** Walzer は、暗号アルゴリズム選好の更新は有効期限切れを待たずにいつでも行える、と指摘する[^30]。「期限切れを契機にアルゴリズム選好を見直す」という運用上の便益は認めつつも、それは有効期限を**設ける**理由にはならない、というのが論点である。 **反論の評価（解釈）** (1) は事実として正しい。有効期限は「セキュリティの本質的な制限」ではなく、「運用上の同期メカニズム」と位置づけるべきである。本稿第1章前段の整理はこの認識と一致する。 (2)(3) は副鍵分離スキームの**運用が想定通り機能している場合**には妥当である。一方、運用が乱れた場合（主鍵を取り出せない、失効証明書が見つからない等）には、有効期限が「最後のセーフティネット」として機能する余地は残る（仮説）。 (4) は副鍵の有効期限を「アルゴリズム陳腐化対応の主たる動機」と位置づけることへの戒めとして有用である。実装側がアクティブにアルゴリズム選好の更新を提案できる限り、有効期限はあくまで「いくつかある運用契機の一つ」に過ぎない。 **本節の結論**：本稿は副鍵に有効期限を設けることを支持する立場をとるが、その意義は「**副鍵単独の侵害可能性を時間的に区切る**」「**主鍵を維持したまま副鍵を入れ替えるリズムを作る**」「**Forward Secrecy の不在を時間的に補う**」という運用上の効果に限定して理解されるべきである。有効期限を絶対的な防御機構として過信するのは誤りであり、Walzer の指摘するユーザビリティ上の負担も実在する論点として認識する必要がある。 加えて、本稿筆者は §1.1.2 で「鍵管理慣性の維持」として整理した観点を、より具体的に次の三つに展開できると考える。これらの実務的観点からも、副鍵に有効期限を設けることを支持する立場をとる。 1. **ハードウェアトークンの予防保全**：副鍵を YubiKey や OpenPGP Smart Card 等のハードウェアトークンに格納している運用では、有効期限切れに伴う Renewal/Rotation は、トークン自体の動作確認・故障の早期検知の機会となる。10 年以上ハードウェアを触らない運用は現実的ではなく、年次〜数年次の予防保全リズムは、有効期限と自然に紐付く。 2. **副鍵流出時の失効訓練**：副鍵が侵害されたと判明した非常時に、慌てず正確に失効・再発行を行えるかは、**平時の訓練量**に依存する。有効期限切れに伴う Renewal/Rotation は、この失効・再発行手順を平時の運用イベントとして組み込む機会となる。 3. **PGP 鍵運用技術力の継続確認**：PGP 鍵運用に必要な手順（オフライン主鍵の取り出し、自己署名の更新、キーサーバへの伝播、スマートカードの操作等）は、長期間使わないと忘れる類のものである。有効期限切れは、こうした技術力を「使い続けることで維持する」強制機構として働く。Riseup が「keep your OpenPGP skills fresh」と表現する効果と同質である[^1]。また、主鍵を取り出すタイミングは、User ID（メールアドレス、所属表記等）や Photo ID（User Attribute）等の付加データを見直す機会としても活用できる（解釈）。 --- ## 第2章 主要なベストプラクティス見解 ### 2.1 Riseup（活動家・人権擁護コミュニティ向け） Riseup の OpenPGP Best Practices は、サイバーセキュリティの強化を必要とする活動家・ジャーナリストコミュニティで広く参照されてきたガイドである（**初出は 2013〜2014 年頃と推定。現在のページには「このガイドは deprecated（古いものとなっている）。GnuPG が妥当な動作をするようになったのでデフォルト設定を使えばよい」という旨の注記が追加されている**[^1]）。 > Use an expiration date less than two years.[^1] > （参考訳：有効期限は2年未満を使うこと） 理由として、鍵を喪失したりパスワードを忘れた場合に、無期限の鍵がインターネット上に永遠に残り続ける問題を挙げている[^1]。また、有効期限の更新を定期的に行うことは、利用者自身の OpenPGP スキルを維持する機会としても価値がある、と述べている[^1]。 ### 2.2 drduh/YubiKey-Guide（YubiKey 利用者向けの定番ガイド） YubiKey で OpenPGP を運用する実践者の間で広く参照されている drduh/YubiKey-Guide[^2] は、より具体的に「2年」を推奨している（**GitHub 上で継続的に更新されているガイドであり、本稿執筆時点（2026年5月）の最新内容を参照**）。 > This guide recommends a two year expiration for Subkeys to balance security and usability, however longer durations are possible to reduce maintenance frequency.[^2] > （参考訳：本ガイドは、セキュリティと利便性のバランスから副鍵の有効期限として2年を推奨する。ただし、メンテナンス頻度を減らすため、より長い期間も可能である） 注目すべきは、同ガイドが**主鍵（Certify Key）には有効期限を設定しない**ことを推奨している点である。その理由は「主鍵は自分自身で自分の有効期限を延長できるので、有効期限を設定しても無意味」というものだ[^2]。これは前章で触れた「有効期限は運用上の同期メカニズム」という性質を踏まえた合理的な判断である。 また、同ガイドは **PGP に forward secrecy（前方秘匿性）が無い**ことを副鍵ローテーションの根拠として挙げている。仮に副鍵が将来漏洩した場合、それまでに暗号化された全メッセージが復号可能となるため、定期的に副鍵を入れ替えて被害範囲を時間的に区切るという考え方である[^12]。 ### 2.3 Simon Josefsson（短期派の代表的論者） Simon Josefsson は GnuPG の長年の貢献者であり、2014年のブログ記事「The Case for Short OpenPGP Key Validity Periods」で、自身の鍵を **100日** という極めて短い有効期限で運用していると公表した[^4]。彼の主張は次の3点に整理される。 1. **長期間の鍵管理に対する自信のなさ**：50年も秘密鍵や失効証明書を確実に保管できる自信がない。万一どちらも失えば、二つの「有効に見える」鍵がキーサーバ上に共存することになり、利用者の混乱を招く 2. **失効証明書の早期伝播**：50年期限の鍵は誰も再取得しないため、失効証明書を発行しても周知されない。短期間の有効期限は CRL/OCSP のような効果を持つ 3. **暗号アルゴリズム選好の更新**：暗号アルゴリズムは登場と陳腐化を繰り返すため、長期間の鍵では古い選好で暗号化され続けるリスクがある ただし Simon 自身も、Debian キーリングが鍵更新を反映するまでの遅延（数週間）により、Debian Developer としての作業から一時的に締め出された経験があると認めている[^4]。短期化のコストは無視できない。 ### 2.4 Ingo Klöcker（KDE 開発者、Kleopatra メンテナ） **2022 年 10 月**、GnuPG-users メーリングリストで Git commit 署名用の鍵について述べた Ingo Klöcker は、質問者が提示した「Certify-only の主鍵を offline 保管する」構成への返信として、自身は次のような実験を行っていると報告している。 - **署名副鍵の有効期限を1年とする**[^5] 具体的には次のように述べている。 > "I'm going to experiment with 1-year-validity of the signing subkeys of my commit signing key. Since I use this key exclusively for commit signing, I can simply replace it with a completely different key if I change my mind." > （参考訳：commit 署名用鍵の署名副鍵の有効期限を1年とする実験をしようと思う。この鍵は commit 署名専用に使っているので、考えを変えたら全く別の鍵に置き換えることもできる） 注目すべきは「考えを変えたら鍵を完全に置き換える」という柔軟な姿勢である。これは前述の Renewal（有効期限の延長）と Rotation（鍵の置き換え）の使い分けを意識した実験的アプローチと言える。 ### 2.5 GPGTools（macOS 向け実装） GPGTools の鍵管理 GUI（GPG Keychain）では、**鍵の初期作成時のデフォルト有効期限は4年**である一方、有効期限が近づいた利用者に対しては **「ワンクリックで2年延長」** する選択肢を提示する[^3]（**継続的に運用されている macOS 向けサポートサイトの記述**）。初期作成時と延長時で異なる期間がデフォルトになっていることは興味深く、ユーザーの管理熟達度に応じて期間が変化する設計とも読める。少なくとも延長時に「2年」が UI 上のデフォルトとなっていることは、エンドユーザー向け実装が「2年」を運用上の自然な周期と見なしていることの現れである。 ### 2.6 Alex Cabal（個人ガイドの著名例） 「Creating the perfect GPG keypair」という個人ブログ記事は GPG コミュニティで広く参照されており（**初出は 2013 年頃と推定**）、こう述べる。 > Generally you should set your key to expire within a year or less.[^13] > （参考訳：通常、鍵の有効期限は1年以下にすべきである） その理由も「鍵を喪失したり漏洩した場合に、無期限の悪い鍵が永遠に残ることを防ぐため」というもので、Riseup や Simon Josefsson と共通の論理である。 ### 2.7 一覧表 主要な見解を整理すると次のようになる。 | 出典 | 発言時期 | 主鍵 | 副鍵 | 備考 | |---|---|---|---|---| | Riseup[^1] | 2013〜2014年頃（現在は deprecated 注記あり） | 2年未満 | 2年未満 | 主鍵と副鍵を区別せず統一 | | drduh/YubiKey-Guide[^2] | 継続更新 | 期限なし | 2年 | 主鍵に期限を設定しない方針 | | Simon Josefsson[^4] | 2014年8月 | 短期（100日） | 短期（100日） | 主鍵と副鍵を統一 | | Ingo Klöcker[^5] | 2022年10月 | （直接の言明なし） | 1年 | commit署名用の実験 | | GPGTools[^3] | 継続更新 | 初期作成は4年デフォルト/延長は2年 | 初期作成は4年デフォルト/延長は2年 | UI上のデフォルト | | Alex Cabal[^13] | 2013年頃 | 1年以下 | 1年以下 | | | Gentoo[^6][^24] | 2013年制定／2018年7月更新議論／現行GLEP 63 | 当初5年→2年提案→現行900日 | 当初5年→2年提案→現行900日 | 規定上限は短縮傾向 | **情報鮮度に関する補足**：上記の発言時期には 2013 年から 2022 年まで約 10 年の幅がある。この期間中に、OpenPGP を取り巻く環境（SKS keyserver の事実上の崩壊と Hagrid 等への移行、SHA-1 から SHA-256 系への移行、楕円曲線暗号の普及、ハードウェアトークンの一般化、近年では量子耐性暗号への移行議論）は大きく変化している。古い時期の発言ほど、当時の前提条件に依存している可能性があり、現在の環境にそのまま適用できるかは別途検討が必要である。「継続更新」と記したガイド類（Riseup、drduh、GPGTools）は、こうした環境変化を反映している可能性が比較的高い。 --- ## 第3章 副鍵の有効期間を決める観点 ### 3.1 用途による違い——副鍵を分けて期限を変える設計 OpenPGP 仕様では、副鍵ごとに異なる有効期限を設定できる。[[30年ぶりのPGP鍵——主鍵・副鍵分離はなぜベストプラクティスになったか]]で扱った副鍵の役割分離（Sign / Encrypt / Authenticate）を踏まえると、用途ごとに異なる期限を考える余地がある。 - **署名副鍵（S）**：失効しても過去の署名は検証可能[^11]。短めに設定して暗号アルゴリズム更新を促進する効果が大きい - **暗号化副鍵（E）**：失効しても過去のメッセージの復号は可能だが、新規の暗号化には使えない。受信者は最新の有効な暗号化副鍵を取得する必要がある。Forward Secrecy が無いことから、定期的なローテーションが意味を持つ[^12] - **認証副鍵（A）**：SSH 等の認証に使う場合、SSH の仕組みと PGP の有効期限の関係には注意が必要である。SSH プロトコル自体には鍵の有効期限という概念はなく（OpenSSH 証明書を別途使う場合を除く）、サーバ側の `authorized_keys` は単なる公開鍵文字列の集合である。したがって、PGP 認証副鍵を gpg-agent 経由で SSH に使う場合、サーバ側は PGP の有効期限を検証しない[^21]。クライアント側でも、gpg-agent が keygrip ベースで鍵を扱う性質上、有効期限が切れても SSH 認証が自動的に拒絶されるという挙動が公式ドキュメントに明示されているわけではない。**したがって「PGP 副鍵の有効期限が SSH 認証の自動的な強制終了として機能する」と期待するのは過大評価である**。むしろ実務上の効果は「有効期限切れを契機として、authorized_keys を更新する運用上の動機が生まれる（forcing function）」という間接的なものである[^21]。Forward Secrecy が無いことから、**副鍵の漏洩時に被害を時間的に区切る**意図でローテーションすること自体には意味があるが、その「時間区切り」は authorized_keys の管理を伴わなければ実効性を持たない ただし、複数の有効期限を管理することは認知負荷が高い。**統一的に同じ期限を設定する**実務派が多数を占めるのは、この管理コストを避けるためである。Sequoia-PGP のドキュメントは次のように述べる。 > It can make sense to set different expiration dates for subkeys with different purposes. (...) In summary, one can say that storing the revocation file somewhere safe that's separate from the key is more important than setting an expiration date.[^14] > （参考訳：用途の異なる副鍵に異なる有効期限を設定することは合理性を持ち得る。(...) ただし結論として、有効期限の設定よりも、失効証明書を鍵とは別の安全な場所に保管することのほうが重要であると言える） ### 3.2 主鍵と副鍵の有効期限の関係 この調査で見えてきた重要な分岐点は、**主鍵に有効期限を設定するか否か**である。 - **主鍵にも有効期限を設定する派**（Riseup、Simon Josefsson、Alex Cabal）：主鍵を失った場合の保険として、自動的に「死ぬ」仕組みを組み込む - **主鍵を期限なしとする派**（drduh/YubiKey-Guide など）：主鍵は自身で自身を延長できるため、有効期限を設定しても本質的な意味がないとする どちらの系統を選ぶかは、後述する失効証明書の保管設計と一体で考えるべき問題である。主鍵を無期限とする選択は、失効証明書の管理が確実に行われていることを前提とする。逆に主鍵にも有効期限を設定する選択は、失効証明書を喪失した場合の保険として機能する。 ### 3.3 キーサーバ更新の慣性化 第1章で述べたように、有効期限は **失効証明書の伝播経路** として機能する。このメカニズムが効くためには、有効期限切れが利用者にとって「気づきやすい」事象でなければならない。 - 5年期限の鍵：5年に一度しか refresh のトリガーが訪れない。その間に失効証明書を発行しても周知が遅れる - 2年期限の鍵：2年に一度トリガーが訪れる。一般的なソフトウェア・暗号アルゴリズムの陳腐化サイクルともおおむね整合 - 1年期限の鍵：年次の運用イベントとして扱える。ただし管理負担が増える ただし、現代では **WKD（Web Key Directory）** や **keys.openpgp.org**（Hagrid）といった**中央集権的な配布インフラ**が普及している（[[30年ぶりのPGP鍵——主鍵・副鍵分離はなぜベストプラクティスになったか]]参照）。これらは原理的には常時最新を提供できるため、SKS keyserver 時代のような「期限切れによる refresh 強制」の重要性はやや薄れている。とはいえ、すべての利用者がこれらのインフラを使っているわけではないため、有効期限による自然な更新サイクルは依然として価値を持つ。 ### 3.4 Renewal（更新）と Rotation（置換）の使い分け drduh/YubiKey-Guide は、有効期限切れへの対応を二つに区別する[^12]。 - **Renewal（更新）**：既存副鍵の有効期限だけを延長する。副鍵そのもの（鍵パケット）は変わらない - **Rotation（置換）**：既存副鍵を失効させ、新しい副鍵を生成する #### 3.4.1 OpenPGP 仕様における有効期限の格納場所——Renewal で何が変わるか 両者の挙動を正しく理解するには、OpenPGP 仕様における鍵指紋（fingerprint）の計算方法と有効期限の格納場所を押さえる必要がある。 **鍵指紋は Public Key Packet または Public Subkey Packet の内容のみから計算される**[^22]。具体的には次の要素のみが入力となる。 - 公開鍵パケットのバージョン（v4 / v6 等） - 鍵生成時刻（creation timestamp） - 公開鍵アルゴリズム識別子 - 公開鍵そのもの（RSA modulus、楕円曲線点など） - ECDH の場合は KDF パラメータ **重要な点**：**有効期限は鍵パケットの中ではなく、自己署名（Subkey Binding Signature 等）の Key Expiration Time サブパケットに格納される**[^10][^23]。つまり有効期限は「鍵に付随するメタデータ」であり、「鍵そのものの一部」ではない。 OpenPGP for application developers の公式ドキュメントは、この設計思想を次のように述べる。 > "the components of an OpenPGP certificate remain static after their creation. The use of signatures to store metadata allows for subsequent modifications without altering the original component."[^23] > （参考訳：OpenPGP 証明書のコンポーネントは作成後は静的なままである。メタデータを署名として保管する仕組みにより、元のコンポーネントを変更することなく後からの修正が可能になる） この設計の帰結として、Renewal の操作は次のように整理できる。 1. 既存の Subkey Binding Signature（副鍵を主鍵に紐付ける自己署名）を、**新しい Key Expiration Time サブパケットを持つ新しい自己署名で置き換える**（OpenPGP の用語では supersede） 2. **副鍵の Public Subkey Packet 自体は一切変更されない**——したがって**副鍵の鍵指紋は不変** 3. **副鍵の Keygrip も不変**（Keygrip は秘密鍵の数学的構造から計算される識別子で、有効期限とは無関係） #### 3.4.2 Renewal と Rotation の比較表 | 観点 | Renewal | Rotation | |---|---|---| | 副鍵の鍵指紋（fingerprint） | **不変** | 変わる | | 副鍵の Keygrip | **不変** | 変わる | | 暗号鍵そのもの（鍵材料） | **変わらない** | 入れ替わる | | 過去の暗号化メッセージへの影響 | なし（同じ鍵で復号可能） | 復号には旧副鍵を保持しておく必要がある | | Forward Secrecy 効果 | なし | 一定の効果あり | | キーサーバへの再登録 | **必要**（新しい自己署名を伝播させるため） | 必要 | | 受信者側の鍵 refresh | 必要 | 必要 | | `~/.ssh/authorized_keys` の更新（SSH 認証用途） | **不要**（公開鍵文字列が同一のため） | 必要 | | GitHub 等での GPG 鍵再登録 | 通常**不要**（fingerprint ベースで識別されるため） | 必要 | | 運用負担 | 軽い | 重い（YubiKey の再書き込み、authorized_keys 更新等） | #### 3.4.3 注意点：キーサーバ伝播の必要性 副鍵の鍵指紋が変わらない場合でも、**キーサーバへの再登録は必要**である。理由は、新しい自己署名（=新しい有効期限を含む Subkey Binding Signature）が利用者の手元に届かなければ、利用者のキーリングでは古い自己署名が依然として「最新」として扱われ、副鍵が期限切れと認識され続けるためである。 drduh/YubiKey-Guide も「Transfer the public key to the destination host and import it」または「publish to a public key server」を Renewal 後の必須手順として挙げている[^2]。 #### 3.4.4 実務的な落としどころ 副鍵を毎回 Rotation すると Forward Secrecy 的効果は得られるが、運用負担が大きく、暗号化副鍵の場合は古い副鍵の保管が必要になる。多くのガイドが推奨するのは「**2〜3年程度の Renewal を基本としつつ、4〜6年程度に一度 Rotation する**」混合戦略である[^12]。 なお、SSH 認証用途で副鍵を使う場合は、Renewal を選ぶことで **`authorized_keys` の更新作業が不要**となる。これは多数のサーバに公開鍵を配布している運用では大きな差になる。一方、副鍵秘密鍵の漏洩が疑われる場合や、Forward Secrecy 的な被害局限を意図する場合は Rotation を選ぶ必要がある。 --- ## 第4章 量子耐性暗号への移行を見据えて——2026年現在の文脈 ### 4.1 OpenPGP の PQC 対応の現状 2026年5月時点で、OpenPGP の PQC 対応は標準化と実装が同時並行で進む段階にある。 - **2024年7月**：RFC 9580（OpenPGP の現行最新版、v6 鍵を導入）公開[^15] - **2025年6月**：draft-ietf-openpgp-pqc が v12 版で informational から standards-track に移行[^7] - **2025年5〜11月**：Red Hat が RHEL 10.0 を一般提供（2025年5月）。TLS 等の PQC 対応をテクノロジープレビューとして導入。RHEL 10.1 では TLS の hybrid ML-KEM/ML-DSA が一般提供に昇格。RPM 署名の PQC 対応はテクノロジープレビュー扱いだが、Red Hat 自身は ipmitool パッケージ等の RPM を PQC 署名運用に投入し、Linux ディストリビューションとしては初の PQC 署名済み RPM をリリースした[^9][^20] - **2025年11月**：Sequoia PGP が PQC 対応のプレビュー版（sequoia-sq 1.4.0-pqc.1）を公開[^8]。Sequoia 開発者は「正式リリースは標準（RFC）発行後」と述べており、相互運用性の問題が残ることを警告している[^8] - **2026年1月**：draft-ietf-openpgp-pqc は v17 版に到達し、editorial な改訂が続いている[^7] - **2026年前半（予測）**：Sequoia PGP の見立てによれば、PQC 規格の RFC 化はこの時期[^8] PQC 規格は、**ML-KEM（Kyber）+ X25519** などのハイブリッド方式を中心に据えており、量子コンピュータがまだ実用化されていない移行期において、PQC 単独ではなく従来の楕円曲線暗号と組み合わせる安全策を採っている[^7]。 ### 4.1.1 OpenPGP / LibrePGP の標準分裂と PQC への影響 副鍵を PQC 対応に切り替える際に避けて通れない論点として、OpenPGP 標準の分裂がある。 - **IETF OpenPGP（RFC 9580 / draft-ietf-openpgp-pqc）**：v6 鍵フォーマットを採用。Sequoia PGP、Proton AG、OpenPGP.js、その他多くの実装が支持 - **LibrePGP**：GnuPG のメンテナである Werner Koch が、IETF の crypto-refresh アプローチに対し、長期安定性と既存実装との互換性を重視する立場から分岐させた独自規格。v5 鍵フォーマットを採用。GnuPG 2.4.0 以降は LibrePGP 仕様に準拠した v5 アーティファクト（署名・暗号化メッセージ等のパケット出力を含む広い概念）の生成を始めた[^18]が、通常の鍵生成（Ed25519 等）におけるデフォルト鍵フォーマットは v4 のまま維持されている（GnuPG 2.4.9 上流純正での実検証で確認）。v5 鍵が生成されるのは GnuPG 2.5.x 系（PQC 対応の現行 stable[^25]）で PQC アルゴリズムを使った鍵生成を行った場合等の特定の条件下である[^19]。GnuPG 2.5 では PQC 対応が独自に実装されている[^19] この分裂により、片方の実装で生成された鍵が他方で正しく扱われない事態が生じている。Sequoia で生成した v6 鍵を GnuPG が「不明なバージョン」として拒否する、あるいはその逆、といった非互換事例が報告されている[^19]。 なお、LibrePGP 路線の PQC 鍵生成では、「**v4 主鍵 + v5 PQC 副鍵**」というハイブリッド構造が採用されていることが、本稿訂正履歴の追加検証（GnuPG 2.5.19 + Kyber 768 (bp256) で実検証）により確認された。主鍵は従来の v4 鍵フォーマットのまま維持され、PQC 専用の副鍵のみが v5 となる。これにより、既存の Web of Trust や鍵基盤との互換性を保ちつつ、PQC 機能を追加できる設計になっている。詳細は文末の「訂正履歴」内の追加検証セクションを参照されたい。 副鍵ローテーション計画への含意としては、次の点に留意する必要がある。 - 既存の副鍵を PQC 対応に置き換える際、自身のツールチェーンと通信相手のツールチェーンが整合しているかを確認する - 移行期は「従来鍵」「PQC v6 鍵」「PQC v5 鍵」が併存する可能性がある - LibrePGP 路線では既存の v4 主鍵を維持したまま PQC 副鍵を追加できるため、Web of Trust の継続性が保たれる利点がある（一方、Sequoia 等の RFC 9580 路線では v6 鍵への切替が前提となる傾向がある） - 副鍵の有効期間を意図的に短めに設定し、ツールチェーン側の状況を見ながら段階的に移行する戦略にも合理性がある ### 4.2 副鍵の有効期間と PQC 移行の関係 ドラフト規格 draft-ietf-openpgp-pqc が示す移行戦略は二つある[^16]。 1. **二つの独立した証明書を持つ**：PQC 対応実装向けと従来実装向けに、それぞれ別の主鍵を発行する 2. **同一証明書に PQC 副鍵を追加**：既存の主鍵に PQC 副鍵を追加し、対応実装には PQC 副鍵を使わせる **論点**：副鍵の有効期間を考える際、上記の移行を「いつ・どのように行うか」を視野に入れる価値がある。 - 5年期限の副鍵：現時点で生成し、その期限が切れるのは2031年。これは PQC が実用展開される時期と重なる可能性が高い。期限切れのタイミングで PQC 対応の副鍵に置き換えるという戦略が成立する - 2年期限の副鍵：2028年に期限切れ。PQC 規格は確実に RFC 化されているはずだが、利用ツールの普及度次第では時期尚早かもしれない - 1年期限の副鍵：2027年に期限切れ。PQC 移行の準備段階として、毎年の更新時に PQC 対応状況を見直す機会が生じる ただし、用途が commit 署名や個人通信の範囲に限られる場合、PQC 移行を急ぐ理由は乏しい。「Harvest Now, Decrypt Later」（暗号化されたデータを今のうちに保存しておき、将来量子コンピュータで復号する）攻撃が懸念されるのは、長期間の機密性が必要なデータを扱う場合に限られる[^17]。逆に、長期保存される機密通信を扱う用途では、副鍵の有効期間を短めに設定して PQC 移行のタイミングを早めに迎えられるようにする戦略にも合理性がある。 --- ## 第5章 検討の整理 ここまでの調査結果を踏まえて、副鍵の有効期間を決める判断軸を整理する。 ### 5.1 期間別の特徴 | 期間 | 主な支持層 | 主な利点 | 主な欠点 | |---|---|---|---| | 1年以下 | Simon Josefsson、Alex Cabal、Ingo Klöcker | 失効通知の素早い伝播、暗号設定の頻繁な更新、運用慣性の維持 | 管理負担が大きい、Debianキーリング等での反映遅延の影響を受けやすい | | **2年（主流）** | **Riseup、drduh/YubiKey-Guide、GPGTools** | **セキュリティと利便性のバランス、コミュニティの慣行に整合** | **3.4節で述べた Renewal/Rotation の使い分けが必要** | | 3〜5年 | Gentoo の議論等 | 管理負担が小さい | 失効通知の伝播が遅れる、暗号アルゴリズム陳腐化への対応が遅れる | | 無期限 | （現代では非推奨） | 管理が不要 | 失効通知の伝播経路を失う、鍵喪失時のリスク | ### 5.2 長期期限（3〜5年）を選ぶ場合の評価 主流の推奨（2年）より長い期限（3〜5年）を選ぶ判断は、以下の観点で許容範囲内である。 - **drduh/YubiKey-Guide も「longer durations are possible to reduce maintenance frequency」と認めている**[^2] - **PQC 移行のタイミング（2030年前後）と整合する可能性がある**：5年期限の鍵を 2026 年に生成すれば、その期限切れは 2031 年となり、PQC 対応副鍵への置き換えタイミングと自然に重なる - **commit 署名や日常通信が主目的の個人運用では、過度な短期化の必要性は薄い** ただし、長期期限を選ぶ場合は次の論点に注意する必要がある。 1. **暗号アルゴリズム選好の更新頻度**：長期間、自己署名内のアルゴリズム選好が更新されないことになる。SHA-1 から SHA-256/SHA-512 への移行のような変化があった場合、対応が遅れる可能性がある 2. **失効証明書の伝播経路**：長期間 refresh されない鍵は、利用者のキーリングで「最新版」とみなされ続ける。失効証明書を発行する事態が生じた場合の周知に時間がかかる 3. **運用慣性の維持**：長期間に一度しか主鍵を取り出さない運用は、手順を忘れがちになる。年次ないし数年に一度の Renewal は、運用訓練の機会としても価値がある ### 5.3 判断のための問い 副鍵の有効期間を再考する際の問いとして、以下が有用である。 - **失効証明書を発行する事態が生じた場合、どの程度の速さで周知される必要があるか？** - 速やかな周知が必要 → 短期（1〜2年） - 緊急性は低い → 長期も許容 - **暗号アルゴリズム選好を能動的に更新する意向があるか？** - 積極的に追従したい → 短期 - デフォルトで十分 → 長期も許容 - **主鍵を取り出す作業を年次のルーチンにできるか？** - できる（むしろ訓練として価値がある） → 1年も検討余地 - 負担が大きい → 2〜3年が現実的 - **PQC 移行のタイミングを期限切れと連動させたいか？** - 連動させたい → 2030年前後に期限が来るよう逆算 - 別途独立に判断する → 期限の長さは PQC とは切り離して決める --- ## 訂正履歴 **2026-05-09 訂正** 本稿の以下の記述に事実関係の誤りがあったため訂正する。 ### 訂正対象 1：結論サマリ「ただし注意点」段落 **【誤】** > 両者は v5/v6 鍵フォーマットや PQC 実装で非互換が生じている。 **【正】** > 両者は鍵フォーマット（GnuPG 系の v5・RFC 9580 系の v6）や PQC 実装で非互換が生じている。ただし、GnuPG 2.4.x 系の通常鍵生成（Ed25519 等）におけるデフォルト鍵フォーマットは v4 のまま維持されており、v5 鍵が生成されるのは PQC 鍵生成等の特定の条件下である（後述）。 ### 訂正対象 2：第4.1.1節「LibrePGP」の記述 **【誤】** > **LibrePGP**：GnuPG のメンテナである Werner Koch が、IETF の crypto-refresh アプローチに対し、長期安定性と既存実装との互換性を重視する立場から分岐させた独自規格。v5 鍵フォーマットを採用。**GnuPG 2.4 以降は v5 鍵を生成。**GnuPG 2.5 では PQC 対応が独自に実装されている[^18][^19] **【正】** > **LibrePGP**：GnuPG のメンテナである Werner Koch が、IETF の crypto-refresh アプローチに対し、長期安定性と既存実装との互換性を重視する立場から分岐させた独自規格。v5 鍵フォーマットを採用。**GnuPG 2.4.0 以降は LibrePGP 仕様に準拠した v5 アーティファクト（署名・暗号化メッセージ等のパケット出力を含む広い概念）の生成を始めた[^18]が、通常の鍵生成（Ed25519 等）におけるデフォルト鍵フォーマットは v4 のまま維持されている**（GnuPG 2.4.9 上流純正での実検証で確認）。v5 鍵が生成されるのは GnuPG 2.5.x 系（PQC 対応の現行 stable[^25]）で PQC アルゴリズムを使った鍵生成を行った場合等の特定の条件下である[^19]。GnuPG 2.5 では PQC 対応が独自に実装されている[^19] ### 訂正の経緯 - 脚注 [^18] の Sequoia PGP Blog 原典は "**A few weeks later, Werner published GnuPG 2.4.0, which started producing v5 artifacts.**" と記載しており、「v5 **artifacts**（アーティファクト）」と「v5 **keys**（鍵）」を区別している。OpenPGP の「アーティファクト」は鍵だけでなく署名・暗号化メッセージ等のパケット出力全般を指す広い概念である。本稿初版で「v5 鍵」と要約した際に、この区別を曖昧にしていた。 - 脚注 [^19] の Jason Self 氏の記事は "Alice... generates a new **post-quantum key**. GnuPG, following the LibrePGP spec, creates a Version 5 (v5) key." と書かれており、これは **PQC 鍵生成時の挙動**である。しかも記事中で著者は「I... was able to pull in the modern GnuPG (**v2.5.13** at present) with full support for PQC algorithms.」と述べており、v5 鍵を観察した環境は GnuPG **2.5.13**（GnuPG 2.5 系、PQC 対応）であった。本稿初版では「GnuPG 2.4 以降」「v5 鍵を生成」と記述してこの文脈を脱落させていた。 - 上記の原典再確認に加え、上流純正 GnuPG 2.4.9（FreePG パッチなし、ソースから自前ビルド）を環境分離して実検証した結果、デフォルト compliance mode は `gnupg`（LibrePGP 路線）であるにもかかわらず、通常鍵生成（Ed25519 + Cv25519）では v4 鍵が生成されることが確認された。 なお、本訂正は「GnuPG が v5 鍵を**全く**生成しない」と主張するものではない（PQC 鍵生成等の特定条件下では v5 鍵が生成される）。本稿初版が「2.4 以降の通常鍵生成で v5 鍵がデフォルト」と読める記述だった点を、より正確な事実関係に改めるものである。 ### 追加検証（2026-05-09）：GnuPG 2.5.19 での PQC 鍵生成 訂正の妥当性をさらに検証するため、GnuPG 2.5.19（GnuPG プロジェクトの公式 Download ページで "stable" と分類される現行版、PQC 対応）を上流ソースから自前ビルドし、環境分離して PQC ハイブリッド鍵生成を実検証した。検証手順は以下のとおりである。 - `gpg --full-generate-key --expert` の対話メニューで「(16) ECC と Kyber」を選択 - 「Kyber 768 (bp256)」（Brainpool P-256 で署名 + Kyber 768 で鍵共有のハイブリッド構成）を選択 - 有効期限は無期限、User ID は `Test User <[email protected]>`、パスフレーズは空 生成された鍵の構造を `gpg --export | gpg --list-packets` で確認した結果、極めて興味深い構造が観察された。 ``` :public key packet: version 4, algo 19, created 1778331942, expires 0 :public sub key packet: version 5, algo 8, created 1778331942, expires 0, pkbytes 1265 ``` - **主鍵**：version **4**、algo 19（ECDSA、Brainpool P-256） - **PQC 副鍵**：version **5**、algo 8、pkbytes 1265（Kyber 768 公開鍵） - **副鍵バインディング署名**：version 4 この構造から、以下の重要な事実が観察できた。 **事実 1：主鍵は v4 のまま、PQC 副鍵のみが v5** LibrePGP の PQC 対応では、鍵全体を v5 に切り替えるのではなく、「**従来の v4 主鍵（既存の Web of Trust と互換）に、PQC 専用の v5 副鍵を追加する**」というハイブリッド構造が採用されている。これは LibrePGP の設計思想「長期安定性と既存実装との互換性を重視」を、生成される鍵の構造レベルで体現している。 **事実 2：副鍵バインディング署名は v4** v5 副鍵を v4 主鍵に紐付ける署名そのものは v4 で行われている。これにより、v5 副鍵を含む鍵全体が、v4 鍵フォーマットを理解する OpenPGP 実装からも「主鍵として」認識可能となる。 **事実 3：Kyber 公開鍵のサイズ** Kyber 768 公開鍵は 1265 バイトと、従来の暗号アルゴリズム（Ed25519: 32 バイト、RSA 4096: 約 512 バイト）と比較して大きい。v5 鍵フォーマットを必要とした技術的理由の一つとして、v4 鍵フォーマットの鍵長フィールドでは収まらない可能性がある（推定）。 **事実 4：algo 8 の意味** 従来の OpenPGP（RFC 4880、RFC 9580）では algo 8 は予約番号または別用途に割り当てられているはずだが、LibrePGP の PQC 実装では Kyber 768 を意味するようである。これは LibrePGP 独自の algo 番号割当である可能性が高く（仮説）、RFC 9580 系の PQC 草案で予定される algo 番号とは異なる可能性がある。両陣営の互換性問題が、この algo 番号レベルでも顕在化することが示唆される。 **Jason Self 氏の記事との照合** 脚注 [^19] の Jason Self 氏の記事は「GnuPG, following the LibrePGP spec, creates a Version 5 (v5) **key**」と記述しているが、本検証で観察された構造はより精緻には「**主鍵は v4、PQC 副鍵のみが v5** のハイブリッド」である。「v5 key」という表現は、PQC 副鍵単体を指したと読むのが正確である。 **検証環境**： - 上流純正 GnuPG 2.5.19（gnupg-2.5.19.tar.bz2 を speedo でビルド、`$HOME/local/gnupg-2.5.19` にインストール） - libgcrypt 1.12.2（PQC アルゴリズム対応版） - Pubkey サポート：RSA, **Kyber**, ELG, DSA, ECDH, ECDSA, EDDSA - compliance mode のデフォルト：`gnupg`（LibrePGP 路線） - システム環境（Kubuntu 26.04 LTS）の pinentry を `$GNUPGHOME/gpg-agent.conf` 経由で借用 - 検証日：2026-05-09 なお、同 2.5.19 環境で **通常鍵生成（PQC を選ばない、デフォルトの ECC 鍵生成）**を行った場合は、v4 主鍵 + v4 副鍵が生成された。これは GnuPG 2.4.9 上流純正での観察と同一であり、v5 鍵生成は PQC 鍵を明示的に選択した場合に限定される、という訂正本文の記述を強く裏付ける。 --- ## 脚注 [^1]: Riseup, "OpenPGP Best Practices" https://riseup.net/en/security/message-security/openpgp/best-practices （2026-05-07 閲覧） [^2]: drduh, "YubiKey-Guide" GitHub README https://github.com/drduh/YubiKey-Guide （2026-05-07 閲覧） [^3]: GPGTools, "Extend Key or Subkey / GPG Keychain FAQ" https://gpgtools.tenderapp.com/kb/gpg-keychain-faq/extend-key-or-subkey （2026-05-07 閲覧） [^4]: Simon Josefsson, "The Case for Short OpenPGP Key Validity Periods" (2014-08-26) https://blog.josefsson.org/2014/08/26/the-case-for-short-openpgp-key-validity-periods/ （2026-05-07 閲覧） [^5]: Ingo Klöcker, "Re: Subkeys renewing/expiring strategy" gnupg-users mailing list (2022-10-11) https://lists.gnupg.org/pipermail/gnupg-users/2022-October/066261.html （2026-05-07 閲覧） [^6]: Michał Górny, "[gentoo-dev] [PATCH v3 00/12] GLEP 63 update" mail-archive.com (2018-07-05) https://www.mail-archive.com/[email protected]/msg82957.html （2026-05-09 閲覧）。GLEP 63 の更新提案として「Make 2-yearly expiration term mandatory」（2年期限を必須に変更）等のパッチが含まれる。なお初期の GLEP 63（2013年）では最大5年を規定しており、2018年7月の議論で2年への短縮が提案され、その後現行版では900日となっている [^7]: IETF, "draft-ietf-openpgp-pqc-17 - Post-Quantum Cryptography in OpenPGP" https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/ （2026-05-07 閲覧） [^8]: Neal H. Walfield, "Post Quantum Cryptography in Sequoia PGP" (2025-11-15) https://sequoia-pgp.org/blog/2025/11/15/202511-post-quantum-cryptography/ （2026-05-07 閲覧） [^9]: Red Hat Developer, "Signing RPM packages using quantum-resistant cryptography" (2026-02-27) https://developers.redhat.com/articles/2025/10/07/signing-rpm-packages-using-quantum-resistant-cryptography （2026-05-07 閲覧） [^10]: IETF, RFC 9580 "OpenPGP" (2024-07) https://www.rfc-editor.org/rfc/rfc9580.html （2026-05-07 閲覧） [^11]: GnuPG, "OpenPGP Key Management" Manual https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html （2026-05-07 閲覧） [^12]: drduh/YubiKey-Guide, "Key Renewal and Rotation" DeepWiki https://deepwiki.com/drduh/YubiKey-Guide/4.2-key-renewal-and-rotation （2026-05-07 閲覧） [^13]: Alex Cabal, "Creating the perfect GPG keypair" https://alexcabal.com/creating-the-perfect-gpg-keypair （2026-05-07 閲覧） [^14]: Sequoia-PGP, "Key expiration" book https://book.sequoia-pgp.org/key_expiration.html （2026-05-07 閲覧） [^15]: IETF, RFC 9580 "OpenPGP" (2024-07) https://www.rfc-editor.org/rfc/rfc9580.html （2026-05-07 閲覧） [^16]: IETF, "draft-ietf-openpgp-pqc - Post-Quantum Cryptography in OpenPGP" Migration Considerations 章 https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/ （2026-05-07 閲覧） [^17]: PQCC, "Post-Quantum Cryptography (PQC) Migration Roadmap" (2025-05) https://pqcc.org/wp-content/uploads/2025/05/PQC-Migration-Roadmap-PQCC-2.pdf （2026-05-07 閲覧） [^18]: Sequoia PGP Blog, "Out and About"（OpenPGP / LibrePGP 分裂についての記述あり） (2024-09-04) https://sequoia-pgp.org/blog/2024/09/04/202409-out-and-about/ （2026-05-07 閲覧） [^19]: Jason Self, "The OpenPGP Schism" (2025-11-23) https://jxself.org/openpgp.shtml （2026-05-07 閲覧） [^20]: Red Hat, "What's new in post-quantum cryptography in RHEL 10.1" (2026-02-04) https://www.redhat.com/en/blog/whats-new-post-quantum-cryptography-rhel-101 （2026-05-07 閲覧） [^21]: Ops Mechanic, "Your SSH Keys Are Naked and It's Your Fault" DEV Community (2026-01-25) https://dev.to/ops_mechanic/your-ssh-keys-are-naked-and-its-your-fault-32kp （2026-05-07 閲覧）。本記事は GPG 認証副鍵を SSH に使う運用において、「SSH デーモンは GPG キーサーバを参照しないため、有効期限や失効はサーバ側で自動的に強制されず、authorized_keys を手作業で更新する必要がある」と明言している [^22]: GetZenQuery, "GPG Key Fingerprint Generator" https://www.getzenquery.com/tools/gpg-key-fingerprint-generator/ （2026-05-07 閲覧）。v4 鍵の指紋計算手順（Public Key Packet を 0x99 プレフィックス付きで SHA-1 ハッシュ）を解説。GnuPG のソースコード（g10/keyid.c）の実装と一致 [^23]: OpenPGP for application developers, "Certificates" https://openpgp.dev/book/certificates.html （2026-05-07 閲覧）。"This fingerprint is derived from the public key material, the creation timestamp, and, when relevant, the ECDH parameters." と明記。また、「コンポーネント自体は静的、メタデータは署名で表現される」設計思想を解説 [^24]: Gentoo Linux Enhancement Proposals, "GLEP 63: Gentoo OpenPGP Authority Keys (modified)" https://www.gentoo.org/glep/glep-0063.html （2026-05-07 閲覧）。現行版では主鍵・副鍵ともに「same maximum time of 900 days for both the primary key and subkeys」と規定されている [^25]: GnuPG 公式 Download ページ. https://www.gnupg.org/download/index.html （2026-05-09 閲覧）。同ページのリリース表では GnuPG 2.5.19（2026-04-24 公開）を「(stable)」、GnuPG 2.4.9（2025-12-30 公開）を「(oldstable)」と分類している。End-of-life の表でも「2.5, 2.6」が現行および次期 stable として示されている [^26]: Daniel Kahn Gillmor and Andrew Gallagher, "Revocation in OpenPGP" Internet-Draft draft-dkg-openpgp-revocation https://datatracker.ietf.org/doc/draft-dkg-openpgp-revocation/ （2026-05-10 閲覧）。-00 および -01 は Gillmor 単独、-02（2025年3月19日公開）から Gallagher が共著として追加されている [^27]: Gentoo Wiki, "Project:Infrastructure/Generating GLEP 63 based OpenPGP keys" https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys （2026-05-10 閲覧） [^28]: Brown, I., Back, A., and B. Laurie, "Forward Secrecy Extensions for OpenPGP" Internet-Draft draft-brown-pgp-pfs-03 (2001-10) https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 （2026-05-10 閲覧）。同ドラフトは Expired Internet-Draft であり、IETF 標準化プロセス上の正式な地位は持たない [^29]: Justus Winter, "Moving forward: Forward Secrecy in OpenPGP" DeltaX Freiburg, 2018-07-21 https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf （2026-05-10 閲覧） [^30]: B. Walzer, "PGP Key Expiry is a Usability Nightmare" The Call of the Open Sidewalk (2026-03-10 最終更新) https://articles.59.ca/doku.php?id=pgpfan:expire （2026-05-10 閲覧） [^31]: Steve Coya, "Re: Forward Secrecy Extensions for OpenPGP" ietf-openpgp mailing list (2000-11-02) https://mailarchive.ietf.org/arch/msg/openpgp/oNgu3e16Eq53HmQ6K4yNBrNvyIc/ （2026-05-10 閲覧）。同スレッド内で Ben Laurie 自身による「the IESG rejected that, because they want the WG to review and ascertain whether this document should be on the standards track」との発言が引用されている [^32]: IETF OpenPGP Working Group Charter https://datatracker.ietf.org/doc/charter-ietf-openpgp/ （2026-05-10 閲覧）。In-scope Topics の Security improvements 配下に「Forward secrecy: enable encrypted OpenPGP communication that cannot be decrypted when long-term keys are compromised.」が掲載されている。なお rechartering は 2023 年に IESG 承認されている [^33]: GnuPG, "OpenPGP Key Management" Manual https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html （2026-05-10 閲覧）。「In addition to the key a revocation certificate is created and stored in the openpgp-revocs.d directory below the GnuPG home directory.」と記述されており、自動生成されるのは主鍵生成時の失効証明書である。副鍵単独の失効証明書は自動生成されない（参考：Michał Górny, "gen-revoke: extending revocation certificates to subkeys" Gentoo Blog (2019-02-20) https://blogs.gentoo.org/mgorny/2019/02/20/gen-revoke-extending-revocation-certificates-to-subkeys/ （2026-05-10 閲覧）。同記事は、副鍵単独の失効証明書を補うツール `gen-revoke` を開発した経緯を述べており、デフォルトでこの機能が存在しないことを裏付けている）