主要領域
セキュリティ
主要領域 の観点では、「セキュリティ」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ケースファイル
申請は署名済み。それでも別の秘密鍵は申告にすぎない：RFC 9883
有効な署名は、ある申告を誰が行ったかを示せる。しかし、申告された別の秘密鍵の所持まで技術的に証明するとは限らない。RFC 9883 はこの差を例外として隠さず、証明の代わりに証明書ポリシーが引き受ける判断として定義した。
ケースファイル
RFC 9882でSHA-512は記入された。それでも署名を左右しない場合がある
暗号メッセージの欄が正しく埋まっていることと、その欄が計算に使われたことは同じではない。RFC 9882は、この違いを例外ではなく相互運用の規則にした。ある CMS 経路では SHA-512 の記載が必須なのに、検証側はその内容を無視しなければならない。
ケースファイル
RFC 9879はMACを刷新した。それでも旧来の読み手は残る
インポート画面に「成功」と出ても、何が成功したかは一つではない。PKCS #12の構文を読めたのか、暗号化された鍵を開けたのか、新しい PBMAC1 で完全性を確かめたのか。RFC 9879は最後の仕組みを更新したが、古い読み手が別の成功だけを返す余地までは消していない。
ケースファイル
二つの形式が入っていても、まだ一つの鍵とは限らない：RFC 9935
ML-KEM の秘密鍵パッケージは、64 バイトのシードと展開済みの復号鍵を同時に保持できる。相互運用には便利だが、受領側がシードから鍵を再生成して照合するまでは、「二つの値を読めた」という事実しか残らない。
ケースファイル
OID は鍵パッケージを示した。使用を許可したのではない：RFC 9939
CMS の OID は読め、PKCS #8 の構造も解析できた。そこで確定するのは、届いた値の型についての局所的な事実である。鍵を誰が保有するか、復号できたか、どの用途を許せるかは別の記録である。
ケースファイル
リソースは認可サーバーを示した。しかし API を使う権利は与えなかった：RFC 9728 の発見境界
保護されたリソースは、クライアントが次にどこを調べるべきかを正しく示せる。それでも、そのクライアントに API 操作を許可したことにはならない。RFC 9728 のメタデータは発見のための座標であり、トークンでも、リソースサーバーの受入判断でも、実行結果の証拠でもない。
ケースファイル
認可の会話はまだ保留中だった。それは API を使う権利ではない：GNAP の継続境界
クライアントは認可の会話を継続できても、要求した API を呼び出せるとは限らない。RFC 9635 はこの二つを明確に分ける。継続用の資格情報は認可サーバー上で一つのグラント要求を進めるだけであり、リソースへの権利は、その後に別の条件で生じる。
IETF
Sean Turnerと、証明書発行を許可しなかった秘密鍵の証明
証明書要求の署名を検証できても、認証局が発行すべき証明書はまだ決まらない。鍵を使えること、申請者が名乗る主体であること、その名前を申請できること、発行方針を満たすことは別々の判断である。
IETF
Panos Kampanakis と三つのセキュリティ証跡を持つ SSH セッション
SSH の接続画面には最後に一つの「成功」が表示される。しかし、その成功に至るまでには、共有秘密の生成、サーバーの識別、利用者の認証という別々の判断がある。ML-KEM を使ったという事実は、そのうち最初の判断を強くする。
IETF
Bas Westerbaan：ハイブリッドTLS鍵合意は証明書まで耐量子化しなかった
標準文書は、仕組みが何をするかを狭く書く。製品のラベルは、その狭さを消しやすい。RFC 10024が規定するのは TLS 1.3のハイブリッド鍵合意であり、証明書認証を含むサービス全体の「耐量子化」ではない。
IETF
Daniel Fett：MFAが確認したのは利用者であり、QRコードの文脈ではない
本物の認可画面で、本物の利用者が、本物の多要素認証を完了する。それでも攻撃者の端末に権限が渡り得る。壊れているのは認証要素ではなく、要求を始めた端末と利用者の判断を結ぶ部分である。
ケースファイル
証明書が相手を検証しても、外部PSKには保管責任者が残る：RFC 9973とTLSの権限境界
運用画面の「TLS 接続成功」は便利な短縮表現である。しかし、工場で書き込まれ、出荷システムを通り、端末、サポート用保管庫、復旧用バックアップに複製され得る秘密について、誰が使えるのかまで短縮してはいけない。証明書が正しい公開鍵で署名できたことと、外部 PSK の保管経路が適正であることは、同じ緑色の表示にはならない別の事実である。
ケースファイル
Cookie は要求に付いてきた。だが決定を証明したわけではない：RFC 10025 と環境的な権限
ある運用変更の記録に、正しいセッション Cookie、HTTPS、成功した応答が並ぶことがある。それでも、その変更を今この時点で誰が意図したのか、サーバーがなおそのセッションを受け入れるのか、その操作に権限があるのか、外部の結果まで生じたのかは分からない。RFC 10025 が定めるのはブラウザ状態の扱いであって、決裁の代行ではない。
ケースファイル
暗号文は鍵に届いた。しかし送信者を名乗らなかった：RFC 9180 と HPKE Base モードにない権限
HPKE の復号が成功しても、その明文を誰が送ったのか、その依頼が今も有効か、その内容を実行してよいかは自動では分からない。RFC 9180 が保証するのは限定された暗号学的遷移であり、身元・封筒・時点・権限・結果は採用するアプリケーションが引き受ける領域である。
ケースファイル
Keyframeの値は物理命令ではない――RFC 9993と触覚レンダリングの権限
振幅、位置、周波数、温度は、触覚効果を表すための有用なパラメータである。しかし、パケットにその値があることは、受信側のアクチュエータがその値を実行してよいことを意味しない。RFC 9993はその値を RTP で運ぶ方法を定める。身体、装置、周囲の安全判断を送信者へ渡す規格ではない。
ケースファイル
認証失敗がメーリングリストを明かすとき――RFC 9991とDMARC報告の開示権限
正当なメーリングリスト投稿が転送中の変更で DMARC に失敗したとする。詳細な報告は設定修正に役立つ一方、投稿者のドメインや外部委託先に、これまで見えなかった会員アドレスと配送先を渡し得る。RFC 9991は失敗を報告する共通手順を作った。誰が通信内容を開示できるかまで、DNS の要求に委ねてはいない。
IETF
Russ Housleyと、証明書には記せても一意にはできないMACアドレス
証明書は6個または8個のオクテットを正確に固定できる。だが、その値を現在使っているインターフェースや、通信を許可した現場の判断まで固定できるわけではない。
IETF
Aaron Pareckiと、トークン窃取を止めてもクライアント乗っ取りは止めないBFF
OAuth トークンをブラウザの JavaScript から隔離すれば、持ち出して別の場所で使う攻撃は大きく減る。しかし、正規オリジン内で動く悪意あるコードは、利用中のセッションを通じて BFF に処理を依頼できる。RFC 10017は、この「守れたもの」と「まだ呼び出せるもの」を同じ成功表示にまとめない。
IETF
Hannes Tschofenigと、token署名者ではなかったauthority ID
component を署名した key と、その測定結果を運ぶ EAT を署名した key は、同じ token の中に現れても別の責任を持つ。RFC 10013はその違いを注釈ではなく拒否条件にした。profile が分からないまま authority を推測してはならない。
ケースファイル
証拠を包めても、装置までは結べない：RFC 9999と複合アテステーションの権限分界
CPU、SmartNIC、GPU が別々に署名した報告を、一つの整ったコンテナで運べるようになる。だが、三つの署名が正しくても、それらが同じ装置、同じ時点、同じ評価対象を表すとは限らない。RFC 9999の CMW は配送上の摩擦を減らす標準であり、誰が装置の物語を束ね、誰が評価し、誰が接続を許すかを代行する標準ではない。