要約

  • 9月17日にLACNICブログへ掲載された寄稿は、XARF v4の最小要件を七項目と説明した。現在のXARF仕様書は、全報告に共通する必須の最上位項目を八つ列挙している。
  • 短い一覧にないのはsenderである。XARFはreporterと分け、CERTや送信基盤事業者が申告者に代わって報告を運べるようにしている。
  • この差から実際の報告紛失やLACNICによるXARF義務化は導けない。検証結果を正確な仕様版、要件一覧、役割、配送結果、トリアージ状態に結び付ける必要は導ける。

七項目がそろっても、誰が運んだかは消え得る

七つの入力欄を持つ受付を考える。仕様版、報告ID、発生時刻、申告者、発生源、カテゴリー、タイプが埋まり、検証は成功する。ところが、実際には加盟組織の代わりに国のCERTが送っており、その事実を置く欄がない。

これは既存システムの障害を示す例ではない。簡潔な説明が、そのまま受付の役割モデルになり得ることを示している。

きっかけは、Guillermo Pereyraが9月17日にLACNICブログへ寄稿した「How to Keep an Abuse Report from Getting Lost in Your Mailbox」である。記事はXARF v4を、七カテゴリー・32種類のインシデントを扱う、コミュニティー管理のJSON形式として紹介する。

続いて最小七項目として、仕様版、一意ID、発生時刻、reporter、悪用の発生源、カテゴリー、タイプを挙げる。一方、現在公開されているXARF v4技術仕様には、xarf_version、report_id、timestamp、reporter、sender、発生源識別項目、category、typeの八項目が、すべての報告に必須とある。

共通項目リファレンスも同じ八項目を示し、reporterとsenderの内部に必須属性を定める。さらにカテゴリーごとの必須項目がある。したがって八という数字は共通の最上位項目数であって、個別の報告が八個の値だけで完成するという意味ではない。

寄稿自体はsenderを理解している。次の段落でreporterとの違いを正しく説明し、JSON例にも両方を置く。ページには、見解は著者個人のものでLACNICの見解を必ずしも表さないとの注記もある。

ここから言える範囲は狭い。LACNICが七項目のパーサーを導入したことも、XARF実装が失敗したことも、特定の報告がこの表現のために未処理になったことも確認できない。確認できるのは、短い数え方と現行仕様が一致しないことだ。

しかし、落ちた項目の意味は小さくない。reporterは悪用を見つけた、または申告した組織であり、senderは報告を送信した組織である。通常は同じでも、申告基盤、ブランド保護会社、対策サービス、国のCERTが別組織のために送る場合がある。

受信側が二つを分ければ、誰が主張したのか、どのシステムが認証・送信したのか、形式修正を誰に返すのかを説明できる。同一仲介者による再送と、複数申告者による独立観測も区別できる。一つの「発信元」に畳むと、列は減るが由来も減る。

そもそもスキーマ適合は処理の入口にすぎない。XARFはsource_port、evidence、evidence_source、confidenceを共通の推奨項目とする。カテゴリー別に追加必須項目があり、標準モードは必須項目を、厳格モードは推奨項目も要求する。

そのため、許容的な検証を通った報告に証拠配列がないことはあり得る。証拠があっても内容が無関係かもしれない。完全なJSONでもメール配送に失敗し、誤ったキューへ入り、人に読まれず、または事実関係を争われる。構文、配送、振り分け、審査、判断、是正は別々の状態である。

ブログ記事もこの境界を認める。証拠は仕様上推奨だが、実務では対応可能性を左右すると書く。また、対象資源、UTC時刻、悪用種別、証拠、返信可能な連絡先があれば、平文も有効だとする。中身のある平文は、中身のないJSONよりよい。XARFは共通言語の候補であり、他形式を無視する許可ではない。

LACNIC Policy Manual第12節は地域上の前提を定める。abuse-cとabuse-mailboxは能動的に管理され、手動・自動の報告を受け、フォームを強制してはならない。この規則は到達可能な窓口と運用を求めるが、XARFを義務付けず、個別申告の真偽も決めない。

配送にも同じ限界がある。寄稿はARFとRFC 5965を挙げる。RFCは拡張可能なメール報告形式を定めるが、送付先、内容検証、生成者と受信者の信頼関係を対象外と明記する。RFC 6650は後の適用指針である。整った封筒は、中身の判断を代行しない。

必要なのは小さな受理記録だ。スキーマ名とセマンティック版、検証器が使ったファイルまたは文書のハッシュ、共通およびカテゴリー固有の要件一覧を残す。値が同じでもreporterとsenderは別の役割として保存する。

さらに検証モード、結果、警告、証拠がある場合の件数と束のハッシュ、輸送メッセージID、受信点、時刻、担当キュー、トリアージ状態、訂正経路を記す。ハッシュが証明するのは同じバイトを見たことで、内容の真実ではない。

文書が修正されたとき、どの報告が旧規則で検証されたかを抽出し、必要な集合だけを再検証できる。記録がなければ「有効なXARF」は、参照したページやローカル実装によって意味が変わるラベルになる。

情報源