要約

  • RFC 9589 は RPKI Signed Object に CMS signing-time を必須化し、binary-signing-time を認めない。
  • RRDP で得たファイルと rsync 側のファイルに同じ mod-time を与え、RRDP 障害後の不要な転送を減らす。
  • その値は信頼できる時刻、現在の manifest、証明書有効性、ROA の利用、実際の転送結果を示さない。

ふたつの配送経路をつなぐだけの値

RRDP は snapshot と delta、rsync はファイル階層を提供する。どちらも配送手段であり、正しさを決める主体ではない。RRDP は壊れた XML、期限切れ TLS、timeout で失敗しうる。その時点で relying party が DER オブジェクトを持っていても、rsync はファイル属性を見て比較する。

rsync の速い比較では、サイズと修正時刻が同じなら再転送を省くことがある。RRDP 由来のローカルコピーに取得時刻を付け、rsync サーバーが別時刻を付ければ、同じオブジェクトを障害時にもう一度運びかねない。RFC 9589 は小さな共通規則を置く。発行者は CMS に signing-time を入れる。repository operator は rsync ファイルの mod-time に用い、relying party も RRDP から materialize したコピーに同じ値を用いる。これで配送形式を越えた比較が可能になる。

省けるのは帯域、ディスク I/O、CPU である。省けないのは検証である。この値は「転送しないかもしれない」ための座標であり、「受け入れるべき」を命じない。

署名されても時計にはならない

署名は、運ばれた属性が途中で書き換えられていないことを守る。発行者の時計が正しいこと、鍵がその時刻に使われたこと、公開がその時刻に起きたことは守らない。RFC 9589 は signing-time の正確性を要求せず、署名生成時刻に関する信頼できる情報を与えないと明記する。

これは最小仕様として正しい。両側で同じオブジェクトに同じ値を付ければ、切替最適化には足りる。法的な時間証明や全体の鮮度判断は別の記録と観測を必要とする。サイズと mod-time の一致も暗号学的な同一性証明ではなく、rsync の転送判断である。CMS、resource certificate、各オブジェクト固有の検証は残る。

なお通過すべき連鎖

取得または保持したオブジェクトは RFC 6488 の共通プロファイルと型固有規則を通る。EE certificate の連鎖と失効を確認する。RFC 9286 の current manifest は署名済み inventory を与える。RFC 9829 によれば対象の CRL は、証明書の CRLDP が示し、かつ発行 CA の current manifest に一致する hash で載るものでなければならない。

ROA も範囲を越えない。資源保有者が特定 prefix をある AS が origin することを認める、という限定的主張である。BGP に現れていること、他者が選ぶこと、router に入ること、packet が届くことは示さない。RRDP の成功も rsync の省略もこの意味を広げない。

検証可能な順序は、URI と bytes、転送決定、certificate、CRL、manifest、object validation、validated output fingerprint、そして policy input である。配送の成功を権限の成功に読み替えてはいけない。

実装で切替を試す

正常な RRDP 後に同一 bytes の rsync へ切替える試験だけでなく、不正 XML、期限切れ TLS、timeout、欠落ファイル、異なる size/mod-time、失効 EE certificate、current manifest にない object を含める。各製品と version について URI、path、hash、signing-time、両方の mod-time、size、転送判断、certificate/CRL/manifest 結果、出力 fingerprint を残す。

validator 間の差はノイズではなく証拠である。転送を省いても accepted set が変わるなら説明が要る。転送量が増えても出力が同じなら、信頼破綻でなく効率の問題かもしれない。実行中の経路を試さない「対応済み」は保証にならない。

出典