付録 A. アルゴリズムの外部データ認証に関するガイドライン

COSEの開発中、アルゴリズム識別子が保護された属性にある必要があるという要件は、mustからshouldに緩和されました。この立場を支持するために、2つの基本的な理由が提示されています。第一に、CoAP環境で最も一般的なメッセージからアルゴリズム識別子が省略された場合、結果として得られるメッセージはより小さくなります。第二に、アルゴリズム識別子が配置される可能性のあるさまざまな場所（メッセージ自体、アプリケーションステートメント、送信者が所有する鍵構造、および受信者が所有する鍵構造）の間で完全なチェックが正しく行われない場合、潜在的なバグが発生する可能性があります。

この付録では、このような変更をどのように行うことができるか、およびアプリケーションがこのオプションを使用するために指定する必要がある詳細について説明します。2つの異なる詳細セットが指定されています。1つはアルゴリズム識別子を省略するために必要なもの、もう1つはそれ自体に関する属性を含まないカウンター署名属性のバリアントを使用するために必要なものです。

3つの推奨事項セットが提示されています。最初の推奨事項セットは、COSEオブジェクトの単一層に対して暗黙的なアルゴリズムが識別される場合に適用されます。2番目の推奨事項セットは、COSEオブジェクトの複数の層に対して複数の暗黙的なアルゴリズムが識別される場合に適用されます。3番目の推奨事項セットは、複数のCOSEオブジェクト構造に対して暗黙的なアルゴリズムを持つ場合に適用されます。

BCP 14（[RFC2119]および[RFC8174]）のキーワードは、ここでは意図的に使用されていません。この仕様は推奨事項を提供することはできますが、それらを強制することはできません。

この推奨事項セットは、アプリケーションが単一のCOSEオブジェクトで使用するための鍵情報とともに固定アルゴリズムを配布している場合に適用されます。これは通常、最小のCOSEオブジェクト、具体的にはCOSE_Sign1、COSE_Mac0、およびCOSE_Encrypt0に適用されますが、他の構造にも適用される可能性があります。

以下の項目を考慮する必要があります。

アプリケーションは、暗黙的なアルゴリズムが使用されるCOSE構造のセットをリストする必要があります。アプリケーションは、これらの構造のいずれかで明示的なアルゴリズム識別子を受信した場合、メッセージが拒否されることを要求する必要があります。この要件は、どのアルゴリズムを使用すべきか（暗黙的か明示的か）という質問について曖昧さが生じるケースが決してないようにするために述べられています。これは、転送されたアルゴリズム識別子が保護された属性である場合でも適用されます。これは、転送されたアルゴリズムが暗黙的なアルゴリズムと同じである場合でも適用されます。
アプリケーションは、アルゴリズム識別子を省略するときにコンテキストの一部と見なされる情報のセットを定義する必要があります。少なくとも、これは鍵識別子（必要な場合）、鍵、アルゴリズム、およびそれが使用されるCOSE構造になります。アプリケーションは、単一の鍵の使用を単一のアルゴリズムに制限すべきです。[RFC9053]の一部のアルゴリズムについて指摘されているように、異なる関連するアルゴリズムで同じ鍵を使用すると、鍵に関する情報の漏洩、データに関する漏洩、または偽造を実行する能力につながる可能性があります。
多くの場合、アルゴリズム識別子を暗黙的にするアプリケーションは、同じ理由でコンテキスト識別子も暗黙的にしたいと考えるでしょう。つまり、コンテキスト識別子を省略すると、メッセージサイズが（識別子の長さに応じて、潜在的に大幅に）減少します。これを行うアプリケーションは、コンテキスト識別子が省略される状況と、これらの場合にコンテキスト識別子がどのように推測されるかを説明する必要があります。（すべての鍵に対する網羅的な検索は、通常、許容されるとは見なされません。）これを行う方法の例は、コンテキストをトランザクション識別子に結び付けることです。両方が元のメッセージで送信されますが、コンテキストがトランザクション識別子に結び付けられているため、その時点以降はトランザクション識別子のみを送信する必要があります。別の方法は、コンテキストをネットワークアドレスに関連付けることです。単一のネットワークアドレスから来るすべてのメッセージは、特定のコンテキストに関連付けられていると見なすことができます。（この場合、アドレスは通常、コンテキストの一部として配布されます。）
アプリケーションは、この保証を作成するような方法で計算されることを保証するために多大な努力を払わない限り、鍵識別子が一意であることに依存することはできません。アプリケーションがこれを行ったとしても、アプリケーションが異なるコンテキスト（つまり、異なるコンテキストプロバイダーを使用）で実行されている場合、またはシステムが異なるアプリケーションからのセキュリティコンテキストを単一のストアに結合する場合、一意性が侵害される可能性があります。
アプリケーションは、アルゴリズム識別子を保護する慣行を継続すべきです。これは保護された属性フィールドに配置することによって行われるわけではないため、アプリケーションはこの値を含むアプリケーション固有の外部データ構造を定義すべきです。この外部データフィールドは、コンテンツ暗号化、MAC、および署名アルゴリズムのためにそのまま使用できます。これは、KDFを使用して鍵値を導出するアルゴリズムのSuppPrivInfoフィールドで使用できます。アプリケーションは、コンテキスト構造の一部である他の情報も保護したい場合があります。暗号計算で使用されることによって保護されるフィールド（鍵やベースIVなど）は、外部データフィールドに含める必要がないことに注意してください。

2番目のケースは、多層COSEオブジェクトに対して複数の暗黙的なアルゴリズム識別子が指定されている場合です。これがどのように機能するかの例は、アプリケーションが指定する暗号化コンテキストであり、これにはコンテンツ暗号化アルゴリズム、キーラップアルゴリズム、鍵識別子、および共有シークレットが含まれます。送信者は、コンテンツ層と受信者層の両方のアルゴリズム識別子の送信を省略し、鍵識別子のみを残します。受信者は、鍵識別子を使用して暗黙的なアルゴリズム識別子を取得します。

以下の追加項目を考慮する必要があります。

これをサポートしたいアプリケーションは、特定の鍵で使用されるCOSE構造と、二次層で使用される構造およびアルゴリズムの両方を可能にし、明確に識別する構造を定義する必要があります。二次層の鍵は、通常どおり受信者層から計算されます。

3番目のケースは、複数の暗黙的なアルゴリズム識別子を持っているが、潜在的に無関係な層または異なるCOSEオブジェクトを対象としている場合です。これが適用可能かもしれない多くの異なるシナリオがあります。これらのシナリオのいくつかは次のとおりです。

2つのコンテキストがペアとして配布されます。各コンテキストは、COSE_Encryptメッセージで使用するためのものです。各コンテキストは、別個の秘密鍵とIV、そして潜在的に異なるアルゴリズムで構成されます。1つのコンテキストはパーティAからパーティBにメッセージを送信するためのものであり、2番目のコンテキストはパーティBからパーティAにメッセージを送信するためのものです。これは、各パーティがメッセージを送信するために異なる秘密鍵を使用するため、リフレクション攻撃が発生する可能性がないことを意味します。反射されたメッセージは復号化に失敗します。
2つのコンテキストがペアとして配布されます。最初のコンテキストはメッセージの暗号化に使用され、2番目のコンテキストはメッセージにカウンター署名を配置するために使用されます。その意図は、2番目のコンテキストを最初のコンテキストとは独立して他のエンティティに配布できることです。これにより、これらのエンティティは、メッセージを復号化して内容を見ることができなくても、メッセージが個人からのものであることを検証できます。
2つのコンテキストがペアとして配布されます。最初のコンテキストにはMAC化されたメッセージを処理するための鍵が含まれ、2番目のコンテキストには暗号化されたメッセージを処理するための別の鍵が含まれます。これにより、異なる鍵を持つ異なるタイプのメッセージに対して参加者に鍵を統一的に配布できますが、鍵は調整された方法で使用される場合があります。

これらのケースについては、以下の追加項目を考慮する必要があります。

アプリケーションは、複数のコンテキストが関連付けられたままであることを保証する必要があります。コンテキストの1つが何らかの理由で無効になった場合、それに関連付けられたすべてのコンテキストも無効になるべきです。