【メモ】W3C暗号ガイドライン要点
背景と目的
W3CのSecurity Interest Group（SIG）は2026年1月29日、「Security Guidelines for Cryptographic Algorithms in the Web Platform」と題するドラフトノート（グループノート草案）を公開しました。Webプラットフォームにおける暗号技術の適切な利用方法を、実践的に整理するガイドです。主に「どの状況でどの方式を使うべきか」「安全なパラメータ設定」「避けるべき誤った実装例（落とし穴）」を整理し、Web技術における暗号利用を一貫性・安全性のあるものとすることを狙います。1
本ガイドラインの主な対象読者は、(1) Web標準の策定者、(2) Webアプリケーション開発者です。各社各様になりがちな暗号の実装に対し、業界全体で一貫した安全策を促し、相互運用性・保守性・検証可能性（レビューしやすさ）の高い暗号運用を推進する意図があります。なお本ドキュメントはW3C勧告（Recommendation）ではなく、コミュニティからのフィードバックを前提としたドラフトの位置づけです。1
位置付け（まとめ表）
| 観点 | 内容 |
|---|---|
| 文書種別 | W3C Draft Note（Group Note草案）であり勧告ではない（拘束力はないが、実装指針として影響し得る）1 |
| 目的 | Webプラットフォームにおける暗号利用の「推奨」「安全なパラメータ」「よくある落とし穴」を統一的に示す1 |
| 対象 | Web標準策定者 / Webアプリ開発者1 |
| 期待効果 | 相互運用性、保守性、検証容易性の向上（我流暗号の抑止含む） |
現在のWebプラットフォームにおける暗号利用の課題
Web分野では暗号アルゴリズムやプロトコルの選択・設定が年々複雑化しています。アルゴリズム種類、モード、鍵長の選択肢に加え、標準の進化や廃止スケジュールが絡むため、開発者が「最適で互換性のある安全な選択」を行うことは容易ではありません。誤った選定や安全でないパラメータの組合せは、相互運用性の問題だけでなく深刻な脆弱性に直結します。
特に「暗号化すれば安全」と誤信して認証や完全性（改ざん検知）を怠る、あるいはプロトコルを不適切に実装する、といった“暗号の誤用”は、過去から現在まで多数のインシデント要因になり得ます。W3Cノートも、暗号利用の落とし穴（例：認証なし暗号、鍵や乱数の扱い、パラメータ誤設定）を体系化して注意喚起しています。1
また、旧式アルゴリズムの遺存（温存）も課題です。計算能力向上や攻撃手法の発見により、かつて安全とされた方式が脆弱化します。例えば、3DES（TDEA）はNISTの移行指針において「暗号化用途は2023年末以降ディスアロー（禁止）」（一部はレガシー処理のみ）と明確に整理されています。2
同様に、RSAやECCの“強度不足設定”は移行・棚卸の対象になり得ます（例：RSA 2048bit未満は署名生成で不許可、検証のみレガシー扱いなど）。2
さらに、Web実装間で暗号機能の扱いが不統一な点も問題です。サイト・ブラウザ・ライブラリがばらばらのアプローチを取ると、互換性や信頼性に差が出てエコシステム全体の安全性低下につながります。W3Cガイドライン策定の背景には「場所によって強度がまちまち」「古い方式が思わぬ所で使われ続ける」といった状況是正の狙いがあります。1
課題を“事故パターン”に分解（整理表）
| 課題パターン | 典型例 | 何が起きるか |
|---|---|---|
| アルゴリズム選定ミス | 古い方式（例：旧式パディング、旧TLS）を新規用途で継続 | 既知攻撃の対象になりやすい／将来のサポート落ち |
| パラメータ不備 | 鍵長不足、弱い曲線、タグ長不足 | 実装は“暗号化”していても強度不足で破られる |
| 機密性のみで満足 | 暗号化したが認証・完全性を付けない | 改ざん・なりすましに弱い（Encrypt-onlyの誤用）1 |
| 実装依存のばらつき | ブラウザ/ライブラリ間で推奨が揃わない | 相互運用性/保守性/検証性の低下 |
ガイドラインの要点
W3Cドラフトノートで示された要点を、(1) 非推奨、(2) 推奨と移行指針、(3) リスク管理（運用・体制）に分けてまとめます。
非推奨とされるアルゴリズム・方式
非推奨一覧（実務向け早見表）
| 分類 | 非推奨（または新規用途で避けたい） | 主な理由 | 代替・移行の方向性 |
|---|---|---|---|
| 対称鍵（鍵長） | 128bit未満の鍵（一般論として） | 強度不足（最低ラインを割る） | AES-128以上（可能ならAES-256）2 |
| 3DES（TDEA） | 3DES暗号化（新規） | NIST移行指針で暗号化用途は2023年末以降ディスアロー（禁止）2 | AES（用途に応じGCM/CTR等） |
| RSA鍵長 | RSA 2048bit未満での署名生成 | NIST移行指針で署名生成は不許可（検証はレガシーのみ）2 | RSA 2048以上（長期は更に上）／ECCへ |
| RSA暗号化（パディング） | RSAES-PKCS#1 v1.5（新規暗号化） | 旧式パディングのリスク、NIST移行指針で2023年末以降ディスアロー（鍵配送等）2 | RSAES-OAEP（PKCS#1 v2.2）3 |
| RSA署名 | RSASSA-PKCS#1 v1.5（段階的に縮退） | PKCS#1でもPSSが推奨され、移行が望ましい3 | RSASSA-PSS3 |
| 旧TLS | TLS 1.0 / 1.1 | IETFで明確に非推奨（Deprecation）4 | TLS 1.2/1.3（原則は1.3） |
| TLS鍵交換 | 静的RSA鍵交換・静的DH 等 | 前方秘匿性や設計上の古さ。実装/運用上のリスク増 | ECDHE中心（TLS1.3では必須） |
| 旧ハッシュ（衝突耐性） | MD5、SHA-1（衝突耐性が必要な用途） | W3CノートでもBLAKE2の比較対象として旧式扱い（衝突耐性観点の注意が前提）1。NISTではSHA-1は署名生成は原則不許可、署名検証はレガシー利用扱い2 | SHA-256以上（SHA-2/3）2 |
| 推奨されない曲線 | secp256k1（一般Web用途） | NIST推奨曲線群から外れる（採用は慎重に）5 | NIST曲線（P-256/384/521）やX25519等 |
| 匿名/弱スイート | NULL/EXPORT/RC4等 | 既知の弱点・意図的弱体化 | 無効化が前提 |
補足（期限表現の注意）
「SHA-1は2030年末までに全面廃止」という表現は文脈により解釈が分かれ得ます。少なくともNIST SP 800-131A Rev.2では、SHA-1は“署名生成は原則不許可（例外はプロトコル別ガイダンス）”、署名検証は“レガシー利用”として整理されていますが、同文書内で「2030年末」等の期限を明示しているわけではありません。2
推奨されるアルゴリズムと移行の指針
推奨方式（用途別の設計ガイド：まとめ表）
| 用途 | 推奨（第一候補） | 代表的パラメータ/運用 | 注意点（落とし穴） |
|---|---|---|---|
| 通信の暗号（AEAD） | AES-GCM | 可能ならAES-256、IV/nonce運用を厳密に | 認証付き暗号（AEAD）を優先し、暗号化のみで満足しない1 |
| AESが不利な環境 | ChaCha20-Poly1305 | IETF標準のAEAD（RFC 8439）6 | 実装・最適化状況（端末/ライブラリ）差を把握 |
| Encrypt-then-MAC | （必要時）AES-CTR + HMAC 等 | HKDF/HMACの標準利用 | “暗号化＋認証”の順序と設計を誤らない1 |
| 鍵ラッピング | AES-KW / AES-KWP | NIST標準（SP 800-38F）7 | 独自鍵包は避ける（相互運用性・検証性を落とす） |
| ストレージ暗号 | XTS-AES | IEEE 1619（ディスク暗号向け）8 | XTSは“改ざん検知を提供しない”ため上位で完全性検証が必要 |
| 鍵長（対称） | AES-128以上（可能なら256） | 256は余裕が大きい（量子時代の見積りにも有利）2 | “最小基準”で止めない（長期保護は余裕を取る） |
| 鍵交換 | ECDH（主にECDHE） | P-256/384/521、X25519等1 | 相手公開鍵の妥当性検証（無効曲線/小サブグループ等）を必須化1 |
| 署名 | ECDSA / EdDSA / RSA-PSS | ECDSAは安全な乱数k、EdDSAは実装実績多1 | 乱数の品質、鍵管理、証明書検証を軽視しない |
| MAC | HMAC-SHA-256+ / KMAC 等 | タグ長は最低128bit以上 | 短すぎるタグは偽造確率が上がる（設計で確保） |
| KDF | HKDF | RFC 5869（TLS 1.3等で広範採用）9 | 共有秘密をそのまま鍵にしない（分布偏り対策） |
| パスワード由来鍵 | Argon2id（第一候補） | RFC 910610 | “高速ハッシュ（SHA-256等）”をパスワードハッシュに流用しない |
| レガシー互換PBKDF | PBKDF2 | RFC 801811 | 反復回数を十分に、可能ならArgon2へ計画的移行 |
鍵長と強度（移行判断のための整理表）
| 分類 | 目安（本文で言及される一般的整理） | 出典で裏取りできる最低ライン |
|---|---|---|
| 対称鍵 | 最低128bit、可能なら256bit | NISTはAES 128/192/256を“Acceptable”として整理2 |
| RSA | 最低2048bit（長期は更に上） | NISTはRSA 2048未満の署名生成を“Disallowed”2 |
| ECC | P-256/P-384/P-521、X25519等 | NIST推奨曲線の整理（SP 800-186）5、X25519はRFC 7748で定義12 |
| PQC（鍵交換/署名） | ML-KEM / ML-DSA / SLH-DSA 等 | NISTはFIPS 203/204/205を公表（初期セット）13 |
リスク管理と暗号運用上の観点
Crypto Agility（暗号の機動性）
ガイドラインが強調する軸の一つが、環境変化に即応できる暗号の機動性（Crypto Agility）です。新たな脆弱性や計算技術の発展で「安全な暗号」が将来も安全であり続ける保証はありません。設計段階から差し替え可能にすることが重要です（例：アルゴリズムのハードコード回避、抽象化レイヤー、複数アルゴリズム並行サポート）。運用としても、暗号ポリシーやTLS設定を定期的にレビューし、不要な古いスイートを無効化する体制が求められます。1
暗号技術のライフサイクル管理（Cryptoperiod）
暗号要素には耐用期間（Cryptoperiod）の考慮が必要です。証明書の有効期限、鍵ローテーション、アルゴリズム自体の推奨期間などを前提に、移行計画を逆算します。NISTの移行指針（SP 800-131A Rev.2）では、例えば3DES暗号化のディスアロー期限や、PKCS#1 v1.5パディングのディスアロー期限などが明確に示されています。2
また、米国ではNSM-10に基づくPQC移行の方針が示され、OMB Memorandum M-23-02は「量子リスクを2035年までに可能な限り低減する」目標、年次インベントリ、記録して後で解読されるリスク（record-now-decrypt-later）への言及を含みます。14 さらに、政府向けのPQCレポートでも、同様の“収集いま・解読あとで”攻撃を想定した準備の必要性が述べられています。15
量子コンピュータ時代への備え（ハイブリッド移行を含む）
将来、暗号解析に十分な量子計算機（CRQC）が現実化すると、RSAやECCの安全性が根底から崩れる可能性があります。移行の過渡期には「ハイブリッド鍵交換」（従来型＋PQC）という段階的戦略が議論されています。IETFでもTLS 1.3におけるハイブリッド鍵交換の設計に関するドラフトが継続しており、PQC移行の“橋渡し”としての位置づけが明確です。16
ただしハイブリッドは実装複雑化を招くため、最終目標は純粋PQCへの置換であり、過渡期措置としての位置付け・適用範囲の見極めが重要です。
標準化動向のモニタリング（W3C / IETF / NIST / CA/B 等）
W3Cは暗号アルゴリズムそのものを標準化する主体ではありませんが、Web Cryptography APIなど既存標準におけるアルゴリズム要件や、ブラウザ実装のデフォルト（ライブラリ設定）が変わることで“事実上の指針”として影響します。1
TLS周りはIETFの動向が直結します。TLS 1.0/1.1の非推奨化は既にRFCで明確です。4
PQCについては、NISTが初期のPQC標準（FIPS 203/204/205）を公表しており、実装・調達要件へ波及する前提情報として継続監視が必要です。13
安全な実装と運用（アルゴリズム採用だけでは不十分）
推奨アルゴリズムを採用しても、実装が脆弱なら意味がありません。安全な乱数生成、鍵保護（秘匿鍵の平文保存回避、メモリ保持最小化）、公開鍵の信頼性検証（証明書検証、必要に応じピンニング）などは暗号システムの根幹です。W3Cノートも、暗号を“ブラックボックス”扱いせず、適切な検証と注意点の体系化を狙っています。1
標準化動向と今後の見通し（タイムライン整理）
タイムライン（社内向けに“いつの話か”を見える化）
| 年 | 動き | 何が変わるか（実務インパクト） |
|---|---|---|
| 2022 | OMB M-23-02（NSM-10準拠） | 年次インベントリ、2035までの量子リスク低減目標、record-now-decrypt-laterを明記14 |
| 2024 | NISTがPQC初期標準（FIPS 203/204/205）を公表 | ML-KEM（鍵確立）、ML-DSA/SLH-DSA（署名）の“標準”が揃い、実装・製品対応が加速13 |
| 2024 | 政府向けPQCレポートで移行の現実課題を整理 | インベントリ、優先順位付け、記録→将来解読の脅威を再確認15 |
| 2025-2026 | IETFでTLS 1.3ハイブリッド鍵交換の設計議論が継続 | 「従来＋PQC」移行パターンが実装へ降りてくる可能性16 |
| 2026 | W3C Draft Note公開（本件） | Web実装での暗号選定・落とし穴の“共通認識”が整理され、実装指針として影響1 |
| 2035 | 目標年（米国政府方針） | “量子リスクを可能な限り低減”の到達点として計画・調達要件に波及14 |
今後Web開発者やセキュリティ担当者に求められる対応
最後に、本ガイドラインと関連動向を踏まえ、社内のセキュリティ専門家・Web開発チームが取るべきアクションを整理します。
1) 既存システムの暗号設定棚卸とアップデート計画
- 自社WebサービスのTLSプロトコルとCipherSuite、ライブラリ対応、保存時暗号、パスワードハッシュ手法を棚卸し。
- W3CノートとNIST移行指針を踏まえ、非推奨要素を段階的に排除（例：3DES、PKCS#1 v1.5、RSA鍵長不足など）。12
- 古いブラウザ互換のために旧TLSを残している等の“技術的負債”は、利用者周知・代替の用意とセットで計画的に停止（TLS1.0/1.1は非推奨）。4
2) 暗号設定の強化（新規・改修の標準化）
- 通信は原則TLS 1.3、必要時TLS 1.2フォールバック（それ以外は無効化）。
- TLS 1.2利用時も強いスイート（AEAD中心）へ寄せる。
- 保存時はAES等の標準方式で暗号化し、我流のXOR等を排除。
- パスワードは平文・MD5/SHA-1は厳禁。推奨はArgon2id、互換上PBKDF2を使う場合も強い設定へ。1011
3) 開発プロセスへの組み込み（チェックリスト化）
- 設計・レビューで「HTTPSのみ」「CSPRNG使用」「禁止アルゴリズム（MD5/SHA-1/RC4等）不使用」「鍵長基準」などをチェック項目化。
- WebCryptoやライブラリ利用時の社内ガイドを作り、推奨アルゴリズム・落とし穴をドキュメント化（W3Cノートの内容を反映）。1
4) 暗号モジュールの抽象化とアジリティ確保
- アルゴリズム名やパラメータを設定で切替可能にし、将来の差し替えコストを下げる。
- 将来PQCへの置換を見据え、依存ライブラリ・インタフェースを固定化しない（Crypto Agility）。
- 長期機密データを扱う領域は“収集いま・解読あとで”攻撃を前提に、PQC試験・移行シナリオを先行検討。14
5) アップデートと継続的な教育
- 「なぜ旧RSAパディングが危険か」「なぜAEADか」「量子が何を壊すか」を、開発者が判断できる粒度で社内展開。
- 勉強会・配布資料・レビュー観点に落とし込み、暗号を“ブラックボックス”にしない。1
実務アクション（チェックリスト表）
| 領域 | すぐやる（〜3か月） | 計画でやる（〜12か月） | 継続（年次） |
|---|---|---|---|
| 棚卸 | TLS/保存/認証/鍵管理の現状一覧化 | 依存ライブラリと暗号APIの統一 | 年次で暗号ポリシー再評価 |
| 設定強化 | TLS 1.0/1.1無効化（可能な範囲で）4 | TLS 1.3原則化、TLS 1.2強スイートのみ | “例外設定”の棚卸・削減 |
| パスワード | 平文/MD5/SHA-1排除 | Argon2id（推奨）へ移行10 | パラメータ（メモリ/反復）見直し |
| 鍵/証明書 | RSA鍵長不足の検出・是正 | PKCS#1 v1.5からOAEP/PSSへ移行23 | 証明書更新・失効運用の点検 |
| PQC準備 | 影響領域の特定（長期機密/PKI等） | 試験導入（ハイブリッド含む検討）16 | 標準・製品対応状況の監視13 |
まとめ
W3Cのドラフトノートは、Webプラットフォームでの暗号利用を「推奨方式」「安全なパラメータ」「落とし穴」という形で整理し、暗号の専門家でなくとも“安全な選択”に寄せられるようにする実務ガイドです。1
一方で、実運用ではNIST移行指針（ディスアロー期限を含む）や、TLSの非推奨化、PQC標準化といった外部の時間軸が“強制力を持って”近づいてきます。2413
本件は「今すぐ設定の棚卸とレガシー排除に着手しつつ、PQC移行（必要なら過渡期のハイブリッド）をロードマップ化する」話です。暗号は常に進化する前提で、継続的アップデート項目としてプロダクトライフサイクルに組み込みましょう。