Summary

  • Vaara Receipt revision 12は同じboundaryに属するseqとrunningCountを署名対象へ結び付け、後続記録が残っていれば途中で抜かれた番号を特定できる。
  • しかし0..kの連続prefixは、完結した履歴にも、後続suffixを丸ごと削った履歴にも見える。terminal sealが総数Nを固定しても、sealごと隠されれば矛盾は残らない。
  • draftは最終countへのRFC 3161 anchorでその残余を閉じる。署名、coverage、内部完全性、終端、外部保管、実行結果は別々の証拠である。

途中の穴と、見えない続き

途中の削除は比較的扱いやすい。seqが0、1、2、4と並び、4番のrunningCountが5なら、3番がないことは手元の集合だけで分かる。発行者へ問い合わせなくても、後続記録が過去の件数を拘束する。

末尾は違う。実際には0番から39番まで発行されたのに、監査側が0番から31番だけを受け取ったとする。31番のrunningCountは32であり、手元にも32件ある。その時点の記録としては正しい。32番以降と閉鎖記録が存在した事実を、31番は持っていない。

draft-sirkkavaara-vaara-receipt-12の面白さは、暗号署名を万能な完全性表示にしない点にある。観測範囲、各記録の整合、途中欠落、境界の閉鎖、外部の時刻証拠を順に重ねる。

boundaryがなければ母集団もない

任意のcoverage blockは、どのchokepointを通るcallを観測したか、どのtool manifestやcommand surfaceが対象かを示す。別経路で到達したcallは範囲外である。

この宣言がなければ、拒否記録がないことから「拒否されなかった」とも「行動しなかった」とも言えない。coverageがあっても主張できるのは、その境界の内側で何が観測されたかだけだ。経路外の行動を、境界内の連番が吸収することはない。

completeness blockはboundaryId、0から増えるseq、そしてrunningCount = seq + 1を持つ。これにより、後の受領記録を持つ者は、それ以前に何件あったはずかを再計算できる。完全性は画面の緑色ではなく、特定boundary内の関係になる。

sealにも保管者がいる

境界を閉じるsealing recordは{sealed: true, total: N}を宣言する。これが残っていれば、末尾を短くした集合はNに届かず失敗する。optionalなmaxClassは、欠落した行動が取り得た最大classを示し、worst caseを限定する。

しかしsealも消せる記録である。suffixを隠せる主体がsealも隠せば、古いprefixだけが残り、それは依然として内部整合する。held setの内側だけでこの状況を見破ることはできない。

そこでdraftは最終running countをRFC 3161で時刻証明する。時刻Tまでにcount Nを表すsigned payloadが存在したという証拠を別の保管面に置けば、後からcount kだけを提示する者に差分の説明を求められる。

ただし、self-hosted TSAが自動的に独立するわけではない。同じ管理権限がaction、receipt、seal、TSA tokenを支配するなら、形式は四つでも抑止点は一つである。時刻authorityの鍵、policy、保管場所、失効確認と利害関係まで設計対象になる。

SCITT receiptは別の役割を持つ

draftはSCITT Transparency Serviceへの登録も扱う。SCITT側のreceiptはSigned Statementが登録されたことをservice policyの下で証明し、Vaara receiptの横に置かれる。timestampAnchorsの一種ではない。

時刻anchorはdigestと時刻主張を結ぶ。SCITT registrationはstatementと登録行為を結ぶ。runningCountは後続記録から途中の欠落を示す。sealは終了総数を宣言する。RFC 9162でもinclusionとconsistencyは別のproofであり、「透明logにある」という一語では監査要件を定義できない。

再計算できることと、事実であること

RFC 8785のJCSは同じJSONを同じbyte列へ正規化し、別実装がhashとsignatureを再計算できるようにする。公開conformance vectorとissuer codeをimportしないcheckerは、実装上の有力なrunning-code evidenceである。

だが、hash一致は保持したevidenceが署名時の対象と同じだと示すだけで、その内容の真実性や網羅性を示さない。signature verificationも、あるkeyがbyte列を署名したことは示すが、そのkeyが現在有効かは示さない。draftはrevocation mechanismもfreshness requirementも定義しないため、deployment側がkey resolutionと許容stalenessを決める必要がある。

decision receiptとexecution receiptの区別も同じである。allowは許可判断であって実行ではない。後者はbackLinkで前者へ結び付き、executedまたはrefusedとresult commitmentを署名できる。それでも外部systemの状態変化を誰が観測したかは、別のreceiptである。

Lu Hengのreality layerに従えば、canonical bytes、完全な集合、閉じた境界、外部見証、行動、結果を一つに潰してはならない。Minimum Initial Specificationは共通envelopeを薄く保てるが、その後のcustodyとdecisionはlocal ownerが引き受ける。Running-Code Primacyはvectorを重視しつつ、それをdeployment truthへ昇格させない。

Sources and limits

これらのsourceが示すのはactiveな個人Internet-Draftと関連公開仕様である。IETF consensus、Vaara ReceiptのRFC化、WG adoption、独立監査、広範なdeployment、完全coverage、独立した時刻authority、またはaction resultを証明しない。本稿はrevision 12の途中欠落、tail seal、外部count anchorという境界だけを扱う。