要約

  • draft-gilda-wimse-agent-audit-record-01 はIETFの個人Internet-Draftであり、WIMSE作業部会が採択した標準でもRFCでもない。
  • 第01版は、許可されても実行されなかった要求を not-exercised、範囲内の書き込みを要求に結び付けられない場合を indeterminate と区別する。

「許可したのに変更がない」という記録は、必ずしも制御の故障を意味しない。代理に書き込みを認めても、呼び出しが失敗することや、そもそも実行しないことはあり得る。ところがSankalp Gildaの監査記録案の第00版は、許可と無変更の組合せに disagree を割り当てていた。拒否した要求が実際に変更を生んだ場合と同じ分類である。第01版はこの混同を解いた。

より重要なのは、変更が「あった」という事実と、それが「この要求による」という判断を分けた点だ。改訂案では各書き込みに、観測者が帰属させた要求のダイジェストを持たせる。判断できなければ値は文字どおり unattributed とする。effect.observed は観測期間全体ではなく、その監査記録が指す要求について計算する。別の要求に帰属する書き込みは、この要求の実行証拠にはならない。

要求に結び付く書き込みがあれば効果は occurred。そのような書き込みがなく、指定したパス範囲内にも帰属不能な書き込みがなければ none。帰属不能な書き込みが範囲内にあれば unknown となる。判定表は、許可と none を not-exercised、いずれの決定と unknown も indeterminate、拒否とその要求に帰属する occurred を disagree とする。未知を「効果なし」と置き換える余地を狭めたわけだ。

同じ版には、照合用ダイジェストの修正もある。呼び出し引数をダイジェストに結び付けられない場合、argumentsDigest は null や空文字で残さず、メンバー自体を省き、要求ダイジェストの計算対象からも外す。そうしなければ、同じ呼び出しを二つの実装が異なる形でハッシュし、記録を結合できない。新たな適合性ベクトルは、他の要求による書き込みや未帰属の書き込み、未行使の許可も試す。

DSSEで署名したin-toto形式そのものは第00版から提案されていた。今回のニュースは署名の発明ではなく、署名された記録が言ってよいことの範囲変更である。Datatrackerは9月27日の更新を個人草案、IESG状態 I-D Exists と記載し、RFCとしての公開やIETFの支持を示していない。署名と内部整合性の検査だけでは、観測者の網羅性、帰属の正直さ、独立した観測位置を証明できない。草案は運用上の合否方針も定めない。

出典