# PGP副鍵の有効期間——ベストプラクティス調査
## 更新履歴
| 日付 | 内容 |
| ---------- | ---- |
| 2026-05-09 | 初版作成 |
---
## はじめに
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 系統の二つの流れがある。両者は v5/v6 鍵フォーマットや PQC 実装で非互換が生じている。副鍵ローテーションの計画では、自身が使うツールチェーン（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. **鍵管理慣性の維持**：定期的に主鍵を取り出して操作することで、運用手順を忘れず、ハードウェアの動作確認も兼ねられる
---
## 第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 以降は v5 鍵を生成。GnuPG 2.5 では PQC 対応が独自に実装されている[^18][^19]
この分裂により、片方の実装で生成された鍵が他方で正しく扱われない事態が生じている。Sequoia で生成した v6 鍵を GnuPG が「不明なバージョン」として拒否する、あるいはその逆、といった非互換事例が報告されている[^19]。
副鍵ローテーション計画への含意としては、次の点に留意する必要がある。
- 既存の副鍵を PQC 対応に置き換える際、自身のツールチェーンと通信相手のツールチェーンが整合しているかを確認する
- 移行期は「従来鍵」「PQC v6 鍵」「PQC v5 鍵」が併存する可能性がある
- 副鍵の有効期間を意図的に短めに設定し、ツールチェーン側の状況を見ながら段階的に移行する戦略にも合理性がある
### 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 とは切り離して決める
---
## 脚注
[^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」と規定されている