要約

  • 2026年9月5日に告知されたdraft-sato-soos-pt-03は、個人提出の有効なInternet-Draftである。IETFの承認や正式な地位、RFCストリーム、担当Area Director、テレチャット日はない。
  • 02版はProgressiveTrustSummaryをHEMの文脈に含めたが、署名との合成順序を定めていなかった。03版は、GECが署名する前に、すべてのHEM Escalation Requestの内部フィールドとしてサマリーを入れるよう求める。
  • 新しい文面では、外側の要求の署名エンベロープから外れて届いたサマリーを、受信側の画面が権威ある情報として扱うことを禁じている。
  • pt_summary_hashは引き続き正規JSONのSHA-256だが、抽出後の再確認に使う補助情報である。判断時の真正性を支えるのは要求全体のkernel_signatureである。
  • 実装は要求ID、署名前像、署名者と鍵、検証結果、サマリーの位置、抽出後ハッシュ、中継時の変換を一つのレシートに残すべきだ。これはDaniel Kadeの提案であり、IETFの要件ではない。

数字が正しくても、組み合わせが正しいとは限らない

9月5日の告知はProgressive Trustを、複数セッションにわたるエージェントの行動から将来の権限に関する勧告を作る仕組みとして説明している。Datatrackerでは、Tom Satoの03版は有効な個人Internet-Draftであり、IETFの承認も正式な地位もない。RFCストリームや担当Area Director、テレチャットも設定されていない。ヘッダーのStandards Trackは著者が目指す状態にすぎない。

PTが扱うのは、自己評価の較正、助けを求める判断、実効性、判断の精度、拒否後の適応という五つの軸だ。ProgressiveTrustSummaryは各スコア、傾向、セッション数、合成表示、保留中の勧告とpt_summary_hashを人向けにまとめる。

問題は、サマリーそのものの内部整合性だけではない。0.88という値は、適切なエージェント、計算時刻、hem_id、発火理由、選択肢と一緒になって初めて意味を持つ。分析サービスがサマリーをキャッシュし、別の要求が開かれた時に返せば、どの値も壊れていないのに判断の組み合わせだけが壊れる。多言語表示用の抽出や非同期取得でも同じ事故は起こり得る。

03版が直したのはこの接合部である。信頼指標を増やしたのではなく、どのオブジェクトについて署名者のコミットメントを検証すべきかを定めた。

02版の「文脈」は署名前像を確定しなかった

02版の固定文書は、各エスカレーションで人に渡すHEMContextにサマリーを入れるようGECに求めていた。HEM呼び出し時に計算することと、ハッシュを持つことも記されていた。しかし、主要求に署名した後、別のAPIからサマリーを足す実装も文面上は排除されていなかった。

公式の差分では変更が明瞭だ。03版はサマリーを各HEM Escalation Request内のフィールドとし、HEM 18.8節に従う署名より前に要求へ合成するよう命じた。さらに、要求の署名エンベロープ外で配達されたサマリーを、受信者のインターフェースは権威あるものと見なしてはならないとした。

草案はこの修正をWIMSE Security Reviewの主要指摘への対応だと説明する。通常の公開情報検索では、そのレビューを独立に読める別文書は見つからなかった。したがって記事が確認できるのは草案自身の帰属表現と、02版から03版への差分までである。レビュー内容を推測で補ってはいけない。

「文脈に表示する」と「署名前に含める」は見た目が近くても、検証可能性が違う。後者なら、署名者は要求ID、トリガー、判断材料とサマリーを一度に引き受ける。どれか一つを差し替えれば要求全体の検証に失敗する。

ハッシュは同一性、外側の署名は結び付きを確かめる

pt_summary_hashは正規JSONに対するSHA-256と定義されている。03版はその役目を狭く、実用的に書き直した。要求からサマリーを取り出した後、監査者が同じ表現を見ているかを再確認するための便宜であり、人に届いた時の真正性を成立させるものではない。

RFC 8785は、JSONのハッシュや署名を繰り返し可能にするには決定的な正規表現が必要だという一般原則を示す。だがダイジェスト単独では、誰が対象を選び、どの要求に含め、誰に示したかは分からない。認証されていないサマリーを差し替えられる者は、差し替え後の新しいハッシュも計算できる。

HEMの07版は外側のオブジェクトを定義する。GECはHEM Escalation Request全体をEd25519で署名し、kernel_signatureは自分以外の全フィールドの正規直列化を対象にする。HEM-07はprogressive_trust_summaryも要求の必須フィールドとしている。これにより検証者は、サマリーと要求を別々に見るのではなく、「この署名者が、この要求に、このサマリーを結び付けた」という一体の主張を検査できる。

もちろん、有効な署名はスコアの真実性まで証明しない。元イベントの欠落、計算の誤り、鍵の侵害、人の判断ミスは別に残る。署名が示すのは、草案の前提内での来歴と改変検知である。03版はそこを誇張していない。

表示より検証を先に置く

実装順序は単純である。まずhem_id、トリガー、選択肢、サマリーを含む外側の要求と署名鍵を検証する。通過後にサマリーを抽出し、必要なら監査用ハッシュを再計算し、スコアや説明を表示する。先に緑色のカードを描画してから裏で署名を調べる設計は、遅延中の見た目を権威に変えてしまう。

中継者も同じ境界に従う。HEM-07は署名検証能力を持つ配送仲介者に対し、失敗した要求を転送しないよう求める。仲介者は運搬や表示を担えても、信頼らしい部品を組み直して新しい権威源になることはできない。直列化を変えるなら、署名前像または再現可能な検証記録を保存する必要がある。

最終判断は人に残る。PTのサマリーは参考情報であり、低い値でも承認でき、高い値でも終了できる。署名対象に含めることは、スコアへ決定権を渡す行為ではない。人が何を根拠として見たのかを追跡可能にする行為である。

保存すべきなのは二つの物ではなく関係である

運用では結合検証レシートを一つ残すべきだ。これは私の提案であり、PTやHEMの規定そのものではない。hem_id、要求版、署名されたバイト列または正規前像、kernel_signature、署名者、鍵ID、検証時刻と結果を記録する。さらに、要求内のサマリーのパス、計算時刻、抽出後に再計算したハッシュ、中継や画面で行われた変換を結ぶ。

テストは誤った組み合わせから始める。正しいサマリーを別のhem_idに付けた場合は失敗しなければならない。値を変えて古いハッシュを残した場合も、値とハッシュを一緒に変えたが外側の署名がない場合も失敗する。署名済み要求から抽出した後に説明文だけを置き換えた画面は、表示同値性の検査で検出されるべきだ。鍵が不明なら「未解決」とし、過去の良好な表示を再利用してはならない。

Heng LuのRunning-Code Primacyは、文書の存在ではなくローカルで検証できる挙動を重視する読み方を与える。Minimum Initial Specificationの観点では、共通部分は薄くてよい。一つの要求、一つの外側署名、一つの再現可能な検証経路で十分だ。これらは分析上の物差しであり、PT採用の証拠ではない。

修正文は存在するが、稼働実績はまだない

PTとHEMのDatatrackerからは、独立実装、相互運用試験、本番導入、悪意ある中継、攻撃事例、IETF採用のいずれも確認できない。どちらも変更・失効し得る個人草案である。

したがって確認できるニュースは限定的だ。PT-03は、人が見る信頼サマリーをどの署名オブジェクトが運ぶのかを明確にし、ハッシュを抽出後監査の役割へ戻した。次の証拠は、信頼という言葉を増やすことではなく、複数の独立実装が同じ取り違えを拒否し、同じ関係を再生できることである。

情報源

  1. IETF告知：draft-sato-soos-pt-03
  2. IETF Datatracker：Progressive Trust
  3. IETFアーカイブ：PT-03
  4. IETFアーカイブ：PT-02
  5. IETF Author Tools：PT-02とPT-03の差分
  6. IETFアーカイブ：HEM-07
  7. IETF Datatracker：Human Escalation Mechanism
  8. RFC 8785：JSON Canonicalization Scheme
  9. Heng Lu：Running-Code Primacy
  10. Heng Lu：Minimum Initial Specification
  11. Heng Lu：Reality, Not Advocacy