メインコンテンツまでスキップ

6.2. HTTP Signature Algorithms レジストリ (HTTP Signature Algorithms Registry)

6.2. HTTP Signature Algorithms レジストリ (HTTP Signature Algorithms Registry)​

本文書は HTTP 署名アルゴリズムを定義し, これに対して IANA が「HTTP Signature Algorithms」という名称の新規レジストリを作成し, 現在も維持している. このレジストリの初期値は 6.2.2 節に示す. 将来の割り当ておよび既存割り当ての変更は, Specification Required 登録方針 [RFC8126] に従って行う.

本レジストリに掲載されるアルゴリズムは, 本仕様を用いるアプリケーションが利用しうる暗号アルゴリズムの一部を識別するが, エントリは可能なアルゴリズムの網羅的リストを表すものでもなく, 本仕様の特定のアプリケーションにおける適合性を示すものでもない. アプリケーションは, 署名者と検証者がそのアルゴリズムのパラメータに安全かつ決定的に合意できる限り, 必要に応じた任意のアルゴリズムを実装してよい. アプリケーションが実行時に alg 署名パラメータを用いて特定のアルゴリズムの使用を通知する必要がある場合, 本レジストリはそのパラメータの値と特定のアルゴリズムとの対応を提供する. ただし, 7 節で論じるとおり, alg パラメータの使用はアルゴリズム混同や置換攻撃の各様な形を避けるために注意を要する.

Status の値は標準化の状況および IETF やセキュリティ関連の標準開発組織 (SDO) など関係コミュニティの広い見解を反映すべきである. アルゴリズムが初めて登録される際, 指定専門家 (designated expert, DE) は, アルゴリズムが一般に安全と推奨されることに合意がある場合は Status フィールドを "Active" に, 合意に至っていない場合 (例: 実験的アルゴリズム) は "Provisional" に設定すべきである. "Provisional" の状態はアルゴリズムが不安全であることが既知であることを意味するのではなく, その性質について合意に達していないことを示す. 将来, 登録されたアルゴリズムに欠陥があると判明した場合, レジストリエントリを更新しアルゴリズムを "Deprecated" とマークして, 問題が判明しているアルゴリズムであることを示してよい. この状態はアプリケーションが特定のアルゴリズムを用いることを妨げるものではなく, アプリケーションが考慮すべき既知の問題に関する警告として機能する. DE はさらに, 登録に Status 値の説明と参照が含まれることを確保できる. これは非推奨アルゴリズムについて特に重要である.

DE は次を実施することが期待される:

  • 登録アルゴリズム識別子が参照するアルゴリズムが, すべてのパラメータ (例: salt, hash, 必要な鍵長) が定義文書によって固定された形で完全に定義されていることを確保する.

  • アルゴリズム定義が, 定義されたすべての入出力が基盤となる暗号アルゴリズムにどのように対応するかを含め, HTTP_SIGN および HTTP_VERIFY プリミティブ関数を完全に規定していることを確保する.

  • 既存の登録の別名である登録を拒否する.

  • すべての登録が 6.2.1 節のテンプレートに従うことを確保する. これには, 名前の長さが過大でない一方で一意かつ識別可能であることの確認が含まれる.

本仕様は, アルゴリズム名が開発者にとって一意かつ識別しやすいように, 識別子文字列に主要パラメータを含めることでアルゴリズム識別子を作成する. ただし, 本レジストリのアルゴリズム識別子は文字列全体として解釈され, 部分の組み合わせとして解釈してはならない. つまり, 実装者は rsa-pss-sha512 を, 問題の識別子を確立する定義文書で設定されているとおりハッシュ, マスク, salt の値が固定された 1 つの特定のアルゴリズムを指すものとして理解することが期待され, 識別子から rsa, pss, sha512 の部分を解析して署名アルゴリズムのパラメータを決定してはならない. また, あるパラメータの組み合わせの登録が, 他の組み合わせの登録を意味するものではない.

に最終更新