要約

  • draft-wilder-scitt-physical-site-engage-receipt revision 03は2026年9月9日に記録され、文書日付は10日である。レシートごとのattestation modeを必須化し、発行者が公開する外部事実を解決できない場合はundeterminedと通知する。現時点では個人投稿のInternet-Draftで、SCITT WG文書でもIETF標準でもない。
  • 新版は、サイト所有者と透明性サービスの関係を既存のどの情報も表していないと認めた。サービスが発行者の外にあることと、サイト所有者から独立していることは別の検証事項である。

保険会社が、工場で行われた保守作業のレシートを受け取ったとする。レシートには発行者の署名があり、TEEが封印した証拠が参照され、透明性サービスへの収録証明も添付されている。暗号検証に成功すれば、提示された記録については強い証拠になる。

しかし、その透明性サービスの運営者が工場所有者なら、証拠の意味は変わる。所有者は発行者の署名を偽造できなくても、自らのサービスに何を受け入れ、何を見せるかに影響できる。見えている一件の収録は証明できるが、見えるべき全件が収録されたとは言えない。

revision 03は、この問題をPhysical-Site Engagement Receipt、PSERの限界として書き込んだ。問題を隠さない設計姿勢は評価できる。だが、限界の記載は、限界を埋めるプロトコルではない。

版の更新と制度上の位置を分ける

Datatrackerではactive individual Internet-Draftであり、RFC streamもintended RFC statusも設定されていない。本文表紙はStandards Trackを希望しているが、それは著者の目標であって、WG採用、IETF合意、RFC化や実装を意味しない。履歴は9月9日22時26分PDTの登録を示し、文書は10日付である。

revision 02には、形式を定義していない「Issuer's manifest」を検証者が読むという四つの要求があった。公式diffによれば、03はその一語に集まっていた別々の義務を分解した。profile IDはwilder.pser/0.4からwilder.pser/0.5へ変わった。

新しい必須フィールドattestation.bindingModeは、TEE witness keyが直接署名したか、TEEの委任を受けた発行者が署名したかをレシート内で示す。DIRECT_WITNESSなのにattestation.witnessKeyとissが異なれば拒否する。レシートを見れば決まる事実を外部文書から推測する必要がなくなった。

外部に残るのは、委任署名のcredentialと、発行者と透明性サービスのaffiliationである。issから発見できる、発行者管理下の安定した識別子で取得する。署名鍵が変われば、以前のキャッシュ結果は再利用できない。

取得不能、欠落、判読不能はundeterminedになる。確認できなかった事実を「確認して不存在だった」と扱ってはならず、発行者に有利な値を自動選択してもならない。ただし、それだけを理由にVerifierがレシート全体を拒否するわけでもない。利用者のpolicyが、その不確実性を受け入れるか決める。検証結果と最終判断を一つにしないための規則である。

三つの関係のうち、最後だけ運搬路がない

発行者とサイト所有者の関係は、レシートのissuerAffiliationに入る。値はaffiliated、independent、not disclosedの三つである。これは発行者による署名付き主張であって、企業支配関係の第三者調査そのものではない。それでも、どのレシートについて、いつ、誰が述べたかは残る。

発行者と透明性サービスの関係は、発行者が外部公開する事実である。発行者自身またはaffiliateがサービスを運営するなら、その収録を発行者外部の証拠として扱えない。関係が解決され、unaffiliatedと分かれば、その限定された外部性を主張できる。

サイト所有者と透明性サービスの関係は、03のレシートにも外部事実にも存在しない。新設のSection 7.9は、前二つから推論できないと説明する。発行者が所有者とサービスの双方から独立していても、所有者がサービスを運営する構成は成立する。

ここで透明性サービスは発行者には外部だが、観察対象側には外部ではない。新版は、サイト所有者が自身のサイトに関するentryを抑止または留保できると述べる。実際の隠蔽を報告しているのではない。提示されたデータだけでは排除できない能力を示している。

inclusion proofはcomplete historyではない

RFC 9942のCOSE Receiptは、verifiable data structureの性質に関する署名付きproofである。inclusion proofの検証成功は、entryがその構造に含まれることを確認する。RFC 9943は、IssuerのSigned Statement、Transparency Serviceによるregistration、Relying Partyによる評価を別の役割として置く。

この仕組みは改変や不整合の発見に強い。一方、ログ運営者がすべての利害関係者から制度的に独立していることまでは示さない。PSERも、あるレシートの登録成功から、発行者が発行した全レシートを登録したとは分からないと明記する。外部anchorを以前から保持していなければ、ローカルhash chainは末尾全体の留保を検出できない。

SLA credit、保険査定、規制監査では、この範囲差が判断を変える。真正な署名だけを求めるpolicy、発行者外の登録を求めるpolicy、サイト所有者からも独立した証拠を求めるpolicyは別物である。「transparent」という一語でまとめれば、誰が何を要求したかが消える。

03が導入したundeterminedは第三の関係にも維持すべきだ。調べていないなら、independentにもaffiliatedにも変換しない。後から所有関係を確認できても、過去のレシートを書き換えず、新しい観察としてdecision recordに結ぶ。二つのサービスを使う場合も、同じ所有者の管理下なら独立した二者にはならない。

逆に、affiliationの判明が常に拒否を意味するわけではない。用途によっては開示された関係を許容できる。必要なのは普遍的禁止ではなく、どの関係を、どの規則で評価したかの可視化である。

三辺のcustody recordを決定に付ける

最小の追加物は、レシートと一緒に評価する三辺custody recordである。レシートIDとprofile versionに、発行者、サイト所有者、透明性サービスを結び、三つのpairごとに関係状態、出典、解決時刻、未解決理由を保存する。さらに、利用者が選んだ独立性要件を明記する。

サービスID、inclusion checkpointと観察時刻、任意の第二サービスや独立monitor、undeterminedの状態、下流判断と理由、訂正・supersession linkも必要になる。サイト情報を公開できない場合は保護してよい。公開面には、どの辺が確認済み、未解決、またはpolicy上不要だったかを限定表示すればよい。

この記録は、SCITTに安全性、法令適合性、保険金支払を決めさせるものではない。署名は誰がstatementを出したかを示す。attestationは生成環境について限定的な証拠を出す。Receiptは一件が構造に含まれたことを示す。custody recordは、そのサービスが実際に適用された独立性policyを満たしたかを記録する。

この区分はThe Policy Mirrorが問うcontrol surfaceと、Running-Code Primacyが求める実行証拠に沿う。Reality, Not Advocacyの原則に従えば、提案が自ら明かした限界を報じ、まだ存在しない成果を補ってはならない。三辺記録はDaniel Kadeの提案であり、IETFの要求ではない。

PSER-03は「発行者の外」と「サイトの外」を分けた。次の課題は、その違いを機械で確認できる状態にすることである。そこまでは、正しいinclusion proofを、それ以上の独立性証明として扱うべきではない。

情報源