トピック
デジタルアイデンティティと資格情報
「トピックの観点から見たデジタルアイデンティティと資格情報トピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
IETF
証明が通ったあと、ラベルの責任は誰に残るのか
鍵透明性は、ディレクトリの応答が履歴と整合することを証明できる。しかし、変更権限、検索の根拠、後日の監視責任までは決めない。IETF の最新レビューは、暗号学の成功表示の背後に残る役割の空白を突いた。
ケースファイル
イントロスペクション応答をアクセストークンとして受け入れた瞬間、署名は境界を守れなくなる――RFC 9701
JWT は広く使われる器であり、同じ発行者、同じ署名鍵、似た `iss` と `aud` を持つことがある。だからこそ RFC 9701 の `typ` と入れ子構造は装飾ではない。何についての証明かを失えば、真正な応答が別の権限へ化ける。
IETF
証明書は小さくなった。信頼判断は小さくならない
証明書は小さくなった。信頼判断は小さくならないの調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。IETFの調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
IETF
証明書は番号を認めた。それでも通話の扱いは決まらない
電話番号の権限は、証明書の有効期間中にも動く。STIR 向け OCSP 拡張は、その変化を一つの番号について確かめる。しかし、得られるのは狭い状態証拠であり、発信者の人物像や通話内容の安全性ではない。
ケースファイル
RSA では必要な `NULL` が、ECDSA では違反になる――RFC 9688 の非対称な証拠
同じ SHA3 family を扱う二つの署名経路に、同じ正規化規則を適用してはいけない。RFC 9688 は RSA-with-SHA3 に `NULL` を要求し、ECDSA-with-SHA3 には parameters の不在を要求する。algorithm 名だけを残す inventory は、この差を最初に失う。
IETF
標準との衝突はなかった。それでも工場鍵に安全評価は付いていない
メーカー組み込み鍵とトラストアンカーを整理する IRTF 文書について、IESG は公開を妨げる標準上の衝突はないと判断した。これは公開手続の結論である。五つの製造方式の優劣や、出荷された機器の秘密鍵が守られたことまで保証しない。
IETF
一人が JWE を復号できても、受信者ポリシーは完了していない
複数受信者向けの JWE は、一つの受信者経路が成功すれば平文を返せる。HPKE の新しい JWE プロファイルが定義するのは、その暗号処理である。誰の成功が必須だったのか、すべてのアルゴリズムが許可されていたのかという運用判断は、別に残る。
IETF
SATPの署名済みアサーションは、台帳の状態証明そのものではない
メッセージ形式が整い、署名者が分かり、前のメッセージとの結合も検証できる。それでも `{}` に入り得る主張が、二つの資産ネットワークの状態を同じ方法で証明するわけではない。SATP の価値は、この差を消すことではなく、ゲートウェイ間の会話を共通化することにある。
ケースファイル
「更新済み」でも、アラームが除去された証拠にはならない
RFC 9671 はメールに含まれる予定情報を Sieve から処理できるようにする。しかし `updated` が示すのは粗い処理結果であり、不要な通知を防ぐためのアラーム除去や、最終的に見える予定の状態まで証明するものではない。
ケースファイル
ShareNotification は届いた。それでも新しい権限を使えた証拠にはならない
RFC 9670 は共有変更を通知できる共通モデルを JMAP に与える。しかし通知オブジェクトが存在すること、利用者が変化に気づくこと、許可された操作が実際に成功することは、別々の出来事である。
番号資源社会
「Setting up 2FA with Passkey」の正体: RIPE NCC Access アカウントを守るパスキー2FAの実際
BTW のネットワーク名簿には「Setting up 2FA with Passkey」という台湾(TW)地域の「機関」が登録されている。しかし手掛かりをたどると、これは機関名ではなく、欧州の番号資源登録機関 RIPE NCC が公開する二段階認証(2FA)サポート文書内の節見出しだ。その見出しの下にあるのは、LIR ポータルや RPKI など RIPE NCC サービスへの single sign-on(SSO)である RIPE NCC Access アカウントを守る、WebAuthn/FIDO2…
IETF
証明書は取れた。それでも配信は始まっていない
RFC 9538 は、下流 CDN が上流の長期秘密鍵を預からずに、自らの鍵で証明書を取得する道筋を整える。だが DNS の向き先、全エッジへの反映、SNI の選択、返却コンテンツ、利用者の成功までは証明しない。
ケースファイル
RFC 9646：HTTP 400はCSRを要求できるが、装置の本人性は承認できない
障害レビューは最初の `400 Bad Request` を失敗として数えた。しかし装置は、サーバーが鍵アルゴリズムと CSR 形式を選ぶ段階まで正しく進んでいた。RFC 9646では赤いステータスが次の処理を指示することがある。それでも、その応答は認証局の発行判断でも、証明書の導入完了でもない。
ケースファイル
RFC 9645：設定表では証明できない TLS 認証経路
監査画面には、証明書、Raw Public Key、TLS 1.2 の PSK、TLS 1.3 の External PSK がすべて正しく設定されている。しかし一つの接続が実際に通った経路は一つであり、再開セッションなら証拠の形そのものが変わる。「誰が誰を認証したのか」という問いに設定一覧を返しても、実行結果を示したことにはならない。
ケースファイル
RFC 9644と、SSHアルゴリズム選択を証明する運用記録
保守時間帯の承認票には、許可されたアルゴリズム一覧と設定反映の成功が記録されている。それでも、その時間帯に重要な処理を担った SSH セッションが何を選び、どのホストを認証し、どんな結果を返したかは分からない。RFC 9644は設定の共通語彙を整える。運用側の課題は、その語彙を実際の交換と結び付け、証明可能な結論に変えることだ。
ケースファイル
設定は復元された。鍵の権限は戻っていない：RFC 9642
RFC 9642 は、中央または inline の鍵、証明書、暗号化値、組み込み鍵を共通の YANG モデルで表す。復元先に同じノードが並んでも、KEK の依存関係、装置固有の主鍵、利用側の参照、実行時の鍵操作まで確認しなければ、復旧を証明したことにはならない。
ケースファイル
期限通知は出た。それでも更新は完了していない：RFC 9641
RFC 9641 の証明書期限通知は、信頼材料の更新を始める重要な信号である。しかし通知の発生は、配送、確認、代替証明書の承認、参照の切替、実行中プロセスへの反映、次の検証成功を証明しない。信頼ストアの状態と受入結果は、別々の現実として結び直す必要がある。
ケースファイル
検証できる証明書でも、危険を引き受ける主体は別にいる
W3C が公開した検証可能な資格情報の脅威モデル草案は、署名の成否だけでは見えない運用上の判断を描く。問題を列挙したことと、発行者や検証者が対策を実行したことは同じではない。
ケースファイル
リレーは読めず、ゲートウェイは識別できない。それでも運用者は結び付けられた：RFC 9614
リレーの説明は正しかった。利用者は見えるが、要求の中身は読めない。ゲートウェイの説明も正しかった。要求は読めるが、利用者の直接の接続先情報は見えない。しかし両方のログに同じ運用主体がアクセスでき、時刻とサイズが対応した瞬間、二つの正しさは一人の行動履歴になった。RFC 9614 が問うのは、各部品の説明ではなく、システム全体で「誰」と「何」が再結合できるかである。
IETF
安全な交換に失敗した。そのフォールバックが推測をさらした
RFC 9588 は Kerberos のパスワードをオフライン検証から守る。しかし失敗後に暗号化タイムスタンプへ戻れば、守ったはずの入力が再び攻撃材料になる。