要約

  • draft-ietf-opsawg-yang-provenance-07 はXML、JSON、CBORそれぞれの正規化後バイト列にCOSE署名を適用し、署名時点の出所と完全性を検証可能にする。
  • バイト列の一致は、schemaの意味、変換の等価性、データの正しさ、鮮度、意思決定権限、controller実行、service結果を同時には証明しない。

同じYANGインスタンスをJSONで保存した系とCBORで運んだ系があった。両方の署名は、それぞれの正規化規則で正しく検証できた。しかし一方の変換器は旧schemaのdefault値を補い、もう一方は新schemaでその値を明示的なoperator選択として扱った。

バイト列は各領域で一貫していた。業務上の意味は一致していなかった。

Applying COSE Signatures for YANG Data Provenance 第07版は2026年7月6日公開、2027年1月7日失効予定のOPSAWG作業部会Internet-Draftであり、文書上の目標はStandards Trackである。RFC、完了済みIANA割当、相互接続試験、導入調査、security認証ではない。Datatrackerは2026年8月25日時点でYANG検証4 errors、0 warningsを示した。Java参照実装とhackathon実演の記載も、本番導入を意味しない。

署名対象は選択されたYANG内容である

提案はpayloadを内包しないCOSE_Sign1を使い、YANG内容をexternal dataとして署名する。enclosing methodに従って対象を選び、provenance leafなど除外すべき部分を外し、serialization固有の正規化を行う。

CBORはlength-first core deterministic encoding、JSONはJCS、XMLはExclusive XML Canonicalization 1.0を用いる。algorithm、kid、serialization methodは保護対象になる。

この手順が保証するのは、検証者が再構成した正規バイト列と署名入力が一致することだ。対象外node、異なるschema revision、別serializationへの変換、unit解釈までは覆わない。receiptにはpathまたはinstance範囲、schemaとserialization、正規化方式、digest、algorithm、kid、解決したkey、検証policyを残す必要がある。

正規化は意味のversion管理ではない

同じ論理モデルでも、default、metadata、annotation、namespace、numeric表現をどう扱うかで、consumerが読む意味は変わり得る。正規化は署名入力を決定的にするが、異なる表現間のsemantic equivalenceを判定する仕組みではない。

schema validationも役割が違う。構造に適合する誤値や古い設定は存在する。DatatrackerのYANG validation結果を、そのままdraft全体のsecurity判定に昇格させてはならない。

変換器は、入力digest、出力digest、schema revision、変換規則、実装versionを結ぶreceiptを発行し、出力そのものかreceiptを署名すべきだ。元データの署名をコピーするだけでは、変換後の主張を覆えない。

countersignatureは同じ内容への追加関与である

RFC 9338のfull countersignatureを既存COSE objectへ追加できる。primary signatureの入力と値は変わらず、追加signerは同じcanonical contentに結び付く。

これはcustodyや承認の一部を示すのに有用だが、途中処理を自動で記録しない。converterが新しいデータを作ったなら、新しい対象が生まれた。古いCOSE objectへのcountersignatureだけで新しい対象を証明することはできない。

さらにverifierはprimary、countersignatureの一部、または全部をpolicyに従って検証できる。同じ「verified」表示でも要求集合が違う。結果には必須signer、実際に検証したsigner、欠落を許した条件を示さなければならない。

署名がない工程は署名列から見えない

draftは、反復署名がprovenance trailに寄与する一方、trailは存在する署名と同じだけしか完全でなく、連続性を単独では保証しないと明記する。

装置と分析器が署名していても、その間のbroker、aggregator、unit converterが無署名なら、二つの有効署名から中間処理の完全性は導けない。必要なのは期待workflow graphである。どの主体が、どの入力と出力を、どの順番で結ぶべきかを外部policyで定義して初めて、欠落を検出できる。

暗号は提示されたlinkを強くする。存在しないlinkを生成しない。

kidはlocal trustの入口である

kidとpublic keyの対応はverifier側のlocal matterで、draftの範囲外だ。正しい署名でも、mappingが別tenant、退役controller、侵害済みkeyを指せば、source governanceは誤る。

正規のkey holderが誤った、または悪意あるデータを署名する場合もある。署名は「このkeyが署名した」を示し、「現実がこうだった」を示さない。certificate、revocation、key purpose、管理domainをdecision receiptに含める必要がある。

古い署名は古いまま有効である

freshnessは本質的に保証されない。timestamp、nonce、request ID、期限などをsignature contextへ結び付けなければ、以前の有効データをreplayできる。

desired stateでは特に危険だ。昨日承認された設定が、障害対応やpolicy変更後も数学的には有効なまま残る。content integrityとcurrent admissibilityを別々に判定しなければならない。

AI/ML分析も同様である。署名入力からmodelが出した推論は新しい主張だ。model ID、feature処理、version、output digest、不確実性と承認を別receiptにする必要がある。

出所証拠は変更権限ではない

telemetryのsource keyを信頼することと、そのkey holderにnetwork変更権限を与えることは別である。署名済みdesired stateであっても、現在のprincipalとpolicyが適用を許しているかを確認しなければならない。

Heng Luの議論が示す通り、証拠や参加はmandateを自動生成しない。実際にcustomer continuityと損失を負うoperatorの権限を、暗号fieldへ黙って移してはならない。

controller acknowledgementの後にも、device configuration、forwarding、service outcomeが残る。draftが提供するleaf、YANG-Push notification、instance-data metadata、annotationという四つのenclosing methodは証拠を運ぶ。running codeの結果までは運ばない。

最終的な記述は狭く保つべきだ。このcanonical contentは、このlocal mappingで解決したkeyにより署名され、以後変更されていない。意味、鮮度、権限、実行、結果は、それぞれ別の証拠で完結させる。

出典