要約

  • RFC 9995のCOSE Hash Envelopeでは、ハッシュ出力そのものがpayloadとなり、必須のpayload_hash_algと、任意の原像形式・所在の手掛かりが保護ヘッダーに置かれる。
  • 署名またはMACは原像なしでも検証できる。その成功は封筒の暗号学的範囲を示すが、原物の可用性、完全なバイト一致、意味、安全性、鮮度、利用許可までは示さない。
  • 依拠する側は、鍵と署名者の役割を確認し、制限付きで取得し、正確なバイトを保持して再計算し、解析・評価・行為の承認を経て、実際の効果を記録しなければならない。

離れた署名設備へ数ギガバイトのファームウェアを送る代わりに、そのハッシュだけを送る。署名設備は短い値を保護し、現場へ小さな封筒を返す。回線費用も待ち時間も減る。現場がすでに同じファイルを持っているなら、これは合理的な構成である。

だが現場のファイルが本当に同じかは、封筒の検証だけでは分からない。ファイルが存在しない可能性すらある。

RFC 9995は2026年7月にIETF Standards Trackとして公開され、この仕組みをCOSE Hash Envelopeとして定義した。大きな原像を運ばずに短いダイジェストを保護できるため、遠隔署名や帯域制約のある環境に向く。仕様が省略したのは転送であって、検証責任ではない。

「外部payload」という一語では足りない

まず三つを分ける。原像は実際にハッシュされたバイト列である。ダイジェストはその出力で、Hash EnvelopeのCOSE payloadになる。さらに通常のCOSE規則により、その小さなダイジェストpayload自体を直列化オブジェクトからdetachedにすることもできる。

原像を封筒に入れないことがRFC 9995の中心である。ダイジェストまで別送するのは追加の伝送状態だ。運用ログが「detached payloadを与えた」とだけ記せば、数十バイトのダイジェストを与えたのか、数ギガバイトの原物を得たのか判別できない。

RFC 9052がCOSEの基礎構造を定める。COSE_Sign1の署名計算は、保護ヘッダー、アプリケーションが選んだ外部認証データ、Sig_structureに入る完全なpayloadを覆う。非保護ヘッダーは同じ範囲に入らない。Hash Envelopeで覆われるpayloadはダイジェストであり、見えない原像が概念上の関連だけで署名対象になるわけではない。

したがって、オフラインで「封筒の署名が有効」と判定するのは正しい。後に候補原像を得て「バイトがダイジェストと一致」と判定するのも正しい。この二段階を一つのverifiedにまとめることが誤りである。

保護された三つのラベル

ラベル258のpayload_hash_algは必須で、保護ヘッダーに置かなければならず、非保護ヘッダーには置けない。payloadのダイジェストを作ったアルゴリズムを示す。

ラベル259のpreimage_content_typeは任意だが、存在する場合は保護される。これは原像のメディアタイプまたはCoAP Content-Formatを示す。通常のCOSE content_type、ラベル3とは別物である。ラベル3は現在のpayload、つまりダイジェストの型を意味してしまうため、RFC 9995はHash Envelopeでの使用を禁じる。

ラベル260のpayload_locationも任意かつ保護対象で、原像を探すための文字列またはURIを置ける。署名後に手掛かりを差し替えられないことと、その場所が安全・利用可能・不変・アクセス許可済みであることは別である。

IANAのCOSEレジストリは安定した番号と参照先を提供する。RFC 8126は登録方針による調整を説明する。登録済みという事実は、製品実装、適合性、特定用途への採用判断を証明しない。

RFC 8610のCDDLは構造の文法を共有する。必須項目の欠落や型の違いは検出できるが、来歴や権限は文法から出ない。RFC 7252のCoAP Content-Formatも解析の座標を与えるだけで、内容が正しい、無害、利用可能だとは判定しない。

正しい鍵でも、正しい権限とは限らない

暗号検証は限定された問いに答える。受け入れたアルゴリズムと入力の下で、保護領域とダイジェストが対応する鍵または共有秘密によって保護されているか、という問いである。

RFC 9052は、検証鍵を正しい署名者の識別情報へ結び、その識別情報が当該行為に権限を持つか確認する責任をアプリケーションに残す。試験用鍵も数学的に正しい署名を作れる。監査記録を承認する鍵も、同じ組織のリリースを承認できるとは限らない。契約終了や役割変更は署名値を変えず、権限を変える。

外部認証データで環境や取引の文脈を結べるが、プロファイルが正確なバイトを定義し、双方が一致させた場合に限る。空の文脈からtenant、版、用途は生まれない。

RFC 9421はHTTPの選択コンポーネントを署名し、アプリケーションプロファイルで意味を定める。対照的にHash EnvelopeはHTTPリクエストを署名せず、位置へのアクセスを承認しない。共通する教訓は、署名結果をそのスコープ内に留めることである。

構造、暗号検証、鍵識別、署名者の役割、目的、外部文脈を別々に記録して初めて、「誰の何に関するダイジェスト主張か」が分かる。

署名済みURIを特権ネットワークで直ちに開かない

位置があっても取得は任意である。検証者がすでに原像を持つ場合も、オフラインの場合も、仲介サービスしか使えない場合もある。原像なしで封筒は検証できるが、照合も利用もできない。

高いネットワーク権限を持つ検証サービスがURIを自動でたどると、署名者は間接的に接続先を指図できる。内部アドレス、別originへのredirect、資格情報の転送、大きな応答、圧縮爆弾が問題になる。署名者の鍵が侵害される場合も、古いドメインが別所有者へ移る場合もある。URIの完全性は、取得先の現在の安全性ではない。

RFC 9110はHTTPのresource、representation、content coding、location、redirectionを区別する。取得側はschemeとorigin、redirect回数、DNS/TLS、資格情報、時間、バイト、展開率、ネットワーク隔離を制限し、最終取得先と変換を保存すべきである。

RFC 6920が示すように、ハッシュに基づく名前と、名前に対応するデータを見つける仕組みは分離できる。ミラーが変わっても同じバイトなら一致する。同じURLでもバイトが変われば一致しない。所在は候補を運び、ダイジェストは取得後の同一性を裁く。

何のバイトを比較するか

候補を取得したらラベル258のアルゴリズムで再計算し、COSE payloadと比較する。ファイル名、版番号、オブジェクトストアのキーは代用にならない。

RFC 9530はHTTP contentとselected representation dataのダイジェストを分ける。content codingが違えば、抽象的には同じ資源でもバイトは異なる。同RFCのDigestフィールド自体も認証、認可、機密性を与えない。

よってプロファイルは、保存された圧縮物、復号・展開後の内容、正規化された直列化など、どのバイト列を原像と呼ぶか定める必要がある。JSONやCBORを一度解析して再直列化すれば、順序、空白、数値表現が変わる。改行の自動変換も別物を作る。

受信バイトを保持し、明示された変換だけを行い、その入力をハッシュして比較する。一致はそのバイトと保護ダイジェストの関係を示すが、鮮度、完全性、安全性、用途適合を示さない。

解析と評価は一致の後に始まる

一致したSBOMが構文エラーであることはあり得る。構文が通ってもschema違反、別ビルド、依存関係の欠落、禁止コンポーネントを含む可能性がある。形式ラベルはparse手段を選ぶが、これらの意味を承認しない。

古いバイトは古いダイジェストと正確に一致し続ける。RFC 9995は一律の鮮度や取消規則を与えない。バージョン、時刻、audience、revoke状態、行為はアプリケーションが結ばなければならない。

対象はCOSE_Sign、Sign1、Mac、Mac0であり、COSE_EncryptとEncrypt0は範囲外である。機密性を提供せず、将来の複合処理で暗号化前後のどちらをハッシュするかも決めない。

アルゴリズム番号も移行を自動化しない。RFC 9053はCOSEアルゴリズムとパラメータ検査を定める。RFC 9995はハッシュと署名/MACの強度の整合を求める。RFC 7696が説くagilityは運用である。生産者が後継を出し、消費者が重複期間に対応し、古い組合せの拒否日と長期保存物の扱いを決める。解析可能は受入可能と同義ではない。

実行された経路を証拠にする

Heng Luのrunning-code優先原則に従えば、「RFC 9995対応」という設定より、実際の原像バイト、生成ダイジェスト、封筒、アルゴリズム、鍵、識別と目的、取得判断、転送経路、再計算、比較、parser、評価、行為の承認、効果が重要になる。

最小初期仕様とローカルな将来判断という考え方は、共通ラベルと構造を狭い調整面に置く。取得権限、許可形式、鮮度、署名者役割、アルゴリズム退役、保存、rollbackは、名前のあるローカル責任者が決め、結果を示す。

現実レイヤーの区別を使えば、封筒のparse、暗号成功、正しいidentity、原像取得、byte一致、意味の合格、行為の許可、意図した効果は別の事実になる。前の事実は次の権限を貸さない。

参照資料はプロトコルと公開された編集思想を示すもので、採用率、性能、製品挙動は示さない。遠隔署名の例も境界説明であり、特定の実装報告ではない。