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

RFC 9052

Internet Engineering Task Force (IETF) J. Schaad Request for Comments: 9052 August Cellars STD: 96 2022年8月 Obsoletes: 8152 Category: Standards Track ISSN: 2070-1721

CBORオブジェクト署名および暗号化 (COSE): 構造とプロセス

要旨

Concise Binary Object Representation (CBOR) は、小さなコードサイズと小さなメッセージサイズのために設計されたデータ形式です。このデータ形式に対して基本的なセキュリティサービスを定義できる必要があります。この文書では、CBORオブジェクト署名および暗号化 (COSE) プロトコルを定義します。この仕様では、CBORをシリアル化に使用して、署名、メッセージ認証コード、および暗号化を作成および処理する方法について説明します。この仕様ではさらに、CBORを使用して暗号化キーを表現する方法についても説明します。

この文書は、RFC 9053とともに、RFC 8152を廃止します。

このメモのステータス

これはインターネット標準化過程の文書です。

この文書は、Internet Engineering Task Force (IETF) の成果物です。これはIETFコミュニティのコンセンサスを表しています。公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2を参照してください。

この文書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9052 で入手できます。

著作権表示

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は、BCP 78およびIETF文書に関連するIETFトラストの法的規定 (https://trustee.ietf.org/license-info) の対象であり、この文書の発行日に有効です。これらの文書は、この文書に関するお客様の権利と制限について説明しているため、注意深く確認してください。この文書から抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eで説明されている改訂BSDライセンスのテキストが含まれている必要があり、改訂BSDライセンスで説明されているように保証なしで提供されます。

目次

  1. はじめに 1.1. 要件の用語 1.2. RFC 8152からの変更点 1.3. JOSEからの設計変更 1.4. CBORデータ構造のCDDL文法 1.5. CBOR関連の用語 1.6. 文書の用語

  2. 基本的なCOSE構造

  3. ヘッダーパラメータ 3.1. 共通のCOSEヘッダーパラメータ

  4. 署名オブジェクト 4.1. 1人以上の署名者による署名 4.2. 1人の署名者による署名 4.3. 外部から提供されたデータ 4.4. 署名および検証プロセス

  5. 暗号化オブジェクト 5.1. Enveloped COSE構造 5.1.1. コンテンツキー配布方法 5.2. 単一受信者暗号化 5.3. AEADアルゴリズムの暗号化と復号化の方法 5.4. AEアルゴリズムの暗号化と復号化の方法

  6. MACオブジェクト 6.1. 受信者付きMACメッセージ 6.2. 暗黙的キー付きMACメッセージ 6.3. MACの計算と検証の方法

  7. キーオブジェクト 7.1. COSEキー共通パラメータ

  8. COSEで使用されるアルゴリズムの分類 8.1. 署名アルゴリズム 8.2. メッセージ認証コード (MAC) アルゴリズム 8.3. コンテンツ暗号化アルゴリズム 8.4. 鍵導出関数 (KDF) 8.5. コンテンツキー配布方法 8.5.1. 直接暗号化 8.5.2. キーラップ 8.5.3. キートランスポート 8.5.4. 直接キー合意 8.5.5. キーラップ付きキー合意

  9. CBORエンコーディングの制限

  10. アプリケーションプロファイリングの考慮事項

  11. IANAの考慮事項 11.1. COSEヘッダーパラメータレジストリ 11.2. COSEキー共通パラメータレジストリ 11.3. メディアタイプ登録 11.3.1. COSEセキュリティメッセージ 11.3.2. COSEキーメディアタイプ 11.4. CoAP Content-Formatsレジストリ 11.5. CBORタグレジストリ 11.6. 専門家レビューの指示

  12. セキュリティに関する考慮事項

  13. 参考文献 13.1. 引用文献 13.2. 参考文献 付録 A. アルゴリズムの外部データ認証に関するガイドライン 付録 B. 2層の受信者情報 付録 C. 例 C.1. 署名付きメッセージの例 C.1.1. 単一署名 C.1.2. 複数の署名者 C.1.3. 重要度付き署名 C.2. 単一署名者の例 C.2.1. 単一ECDSA署名 C.3. Envelopedメッセージの例 C.3.1. 直接ECDH C.3.2. 直接プラス鍵導出 C.3.3. 外部データ付き暗号化コンテンツ C.4. 暗号化メッセージの例 C.4.1. 単純な暗号化メッセージ C.4.2. 部分IV付き暗号化メッセージ C.5. MACメッセージの例 C.5.1. 共有シークレット直接MAC C.5.2. ECDH直接MAC C.5.3. ラップされたMAC C.5.4. 複数受信者MACメッセージ C.6. MAC0メッセージの例 C.6.1. 共有シークレット直接MAC C.7. COSEキー C.7.1. 公開鍵 C.7.2. 秘密鍵 謝辞 著者の住所

  14. はじめに

Internet of Things (IoT) を構成する小型の制約のあるデバイスへの注目が高まっています。このプロセスから生まれた標準の1つが「Concise Binary Object Representation (CBOR)」[STD94] です。CBORは、JavaScript Object Notation (JSON) [STD90] のデータモデルを拡張し、バイナリデータなどを許可しました。CBORは、データ構造をエンコードする方法として、IoTの世界を扱ういくつかのIETFワーキンググループによって採用されています。CBORは、転送されるメッセージと実装サイズの両方の点で小さくなるように、またスキーマフリーのデコーダーを持つように特別に設計されました。IoTにメッセージセキュリティサービスを提供する必要があり、メッセージエンコーディング形式としてCBORを使用することは理にかなっています。

JOSEワーキンググループは、暗号化、署名、およびメッセージ認証コード (MAC) 操作を処理する方法と、JSONを使用してキーをエンコードする方法を指定した一連の文書 [RFC7515] [RFC7516] [RFC7517] [RFC7518] を作成しました。この文書では、CBORエンコーディング形式に対して同じことを行うCBORオブジェクト署名および暗号化 (COSE) 標準を定義しています。この文書は、初期のアルゴリズムセットを提供する [RFC9053] と組み合わされています。元のJSONオブジェクト署名および暗号化 (JOSE) 文書の雰囲気を維持しようとする強い試みがありますが、2つの考慮事項が考慮されています。

  • CBORには、JSONには存在せず、使用するのに適切な機能があります。この一例は、CBORには、最初にbase64エンコードされたテキスト文字列に変換することなく、バイナリデータを直接エンコードする方法があるという事実です。

  • COSEはJOSE仕様の直接のコピーではありません。COSEを作成する過程で、JOSEに対して行われた決定が再検討されました。多くの場合、基準が常に同じではなかったため、異なる結果が決定されました。

この文書には以下が含まれます。

  • 回線上で送信されるCBORオブジェクトの構造の説明。暗号化、署名、およびメッセージ認証のためにそれぞれ2つのオブジェクトが定義されています。キーを転送するためのオブジェクトと、キーのグループを転送するためのオブジェクトが1つ定義されています。

  • 各構造に必要な暗号化関数の入力を構築するために使用される手順。

  • さまざまなセキュリティオブジェクトに適用される属性のセット。

この文書には、特定の暗号化アルゴリズムを使用するためのルールと手順は含まれていません。特定のアルゴリズムの詳細は、[RFC9053] および [RFC8230] に記載されています。追加のアルゴリズムの詳細は、将来の文書で定義される予定です。

COSEは当初、制約のあるRESTful環境 (CoRE) にセキュリティを提供するためのソリューションの一部として設計されており、これは [RFC8613] および [CORE-GROUPCOMM] を使用して行われます。ただし、COSEはこれらのケースだけに限定されるものではなく、セキュリティサービスを提供する目的でJOSEまたは暗号化メッセージ構文 (CMS) [RFC5652] のいずれかを検討する場所であればどこでも使用できます。JOSEやCMSと同様に、COSEはストアアンドフォワードまたはオフラインプロトコルでの使用のみを目的としています。暗号化が必要なオンラインプロトコルでCOSEを使用するには、オブジェクトをやり取りする前にオンラインキー確立プロセスを実行する必要があります。セキュリティサービスにCOSEを使用するアプリケーションは、まずどのセキュリティサービスが必要かを判断し、それらのニーズに基づいて適切なCOSE構造と暗号化アルゴリズムを選択する必要があります。セクション10では、COSEを使用するときにアプリケーションが指定する必要があるものに関する追加情報を提供します。

CMSには存在するがこの標準には存在しない機能の1つは、ダイジェスト構造です。この省略は意図的なものです。プロトコルごとに構造の一部として異なるフィールドセットを含めたいと考えるため、構造は各プロトコルで定義する方がよいでしょう。アルゴリズム識別子とダイジェスト値はすべてのアプリケーションに共通ですが、アルゴリズムを複数の値で1回定義できるため、2つの値が常に隣接しているとは限りません。アプリケーションはさらに、構造の一部として追加のデータフィールドを定義したい場合があります。このようなアプリケーション固有の要素の1つは、ハッシュされているデータを取得できる場所へのURIまたはその他のポインターを含めることです。[RFC9054] には、そのような可能な構造の1つが含まれており、一連のダイジェストアルゴリズムが定義されています。

COSEをインターネット標準に進める過程で、COSE_Sign1構造のカウンター署名のセキュリティプロパティの説明が正しくないことがわかりました。記述されたセキュリティプロパティ（真のカウンター署名のプロパティ）はワーキンググループが望んでいたものであったため、この文書からすべてのカウンター署名のテキストを削除し、古いカウンター署名アルゴリズムとヘッダーパラメータを廃止し、望ましいセキュリティプロパティを持つ新しいアルゴリズムとヘッダーパラメータを定義するために、新しい文書 [COSE-COUNTERSIGN] を作成することが決定されました。

1.1. 要件の用語

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されるべきです。ただし、ここに示されているようにすべて大文字で表示される場合に限ります。

1.2. RFC 8152からの変更点

  • 元の文書をこの文書と [RFC9053] に分割しました。

  • COSEでダイジェスト構造が定義されていない理由を説明するテキストを追加しました。

  • テキストの明確化と用語の変更を行いました。

  • カウンター署名に関するすべての詳細を削除し、それらを [COSE-COUNTERSIGN] に配置しました。

1.3. JOSEからの設計変更

  • 暗号化、署名、およびMACメッセージを簡単に識別でき、かつ一貫したビューを持つことができるように、単一の全体的なメッセージ構造が定義されました。

  • 署名付きメッセージは、コンテンツに関連する保護されたヘッダーパラメータと保護されていないヘッダーパラメータ、および署名に関連するヘッダーパラメータを区別します。

  • MACメッセージは署名付きメッセージから分離されています。

  • MACメッセージは、MAC認証キーを取得するために、Envelopedメッセージと同じ受信者アルゴリズムのセットを使用する機能を備えています。

  • バイナリデータをエンコードするために、base64urlエンコーディングではなくバイナリエンコーディングが使用されます。

  • 暗号化アルゴリズムの認証タグは暗号文と結合されています。

  • 暗号化アルゴリズムのセットは、いくつかの方向で拡張され、他の方向でトリミングされました。

1.4. CBORデータ構造のCDDL文法

COSEが最初に書かれたとき、Concise Data Definition Language (CDDL) [RFC8610] はまだRFCで公開されていなかったため、COSEで採用されているCBORデータ構造を規範的に記述するためのデータ記述言語として使用できませんでした。そのため、ここで定義されているCBORデータオブジェクトは散文で記述されています。COSEデータオブジェクトの追加の（非規範的な）説明は、以下で説明するCDDLのサブセットで提供されています。

この文書は、最初に文法に取り組み、次にそれに付随する散文を開発することによって作成されました。これの副産物として、散文はConcise Data Definition Language (CDDL) [RFC8610] で定義されたプリミティブ型文字列を使用して記述されました。この仕様では、次のプリミティブ型が使用されています。

any: すべてのCBOR値をここに配置できる非特定の値を許可します。

bool: ブール値（メジャータイプ7、値21; false: メジャータイプ7、値20）。

bstr: バイト文字列（メジャータイプ2）。

int: 符号なし整数または負の整数。

nil: null値（メジャータイプ7、値22）。

nint: 負の整数（メジャータイプ1）。

tstr: UTF-8テキスト文字列（メジャータイプ3）。

uint: 符号なし整数（メジャータイプ0）。

CDDLからの3つの構文が、この文書では省略形として表示されます。これらは次のとおりです。

FOO / BAR: FOOまたはBARのいずれかがここに表示できることを示します。

  • FOO: タイプFOOが0回以上表示されることを示します。

CDDLによって定義された制約の2つも、この文書で使用されています。これらは次のとおりです。

type1 .cbor type2: type1（通常はbstr）の内容にtype2の値が含まれていることを示します。

type1 .size integer: type1の内容がintegerバイト長であることを示します。

散文の説明に加えて、CBORデータ構造の文法は、前述のCDDLのサブセットで提示されています。CDDL文法は情報提供のみを目的としており、散文の説明が規範的です。

収集されたCDDLは、以下のXPath式を使用してこの文書のXMLバージョンから抽出できます。（使用しているXPathエバリュエーターによっては、> エンティティを処理する必要がある場合があります。）

//sourcecode[@type='cddl']/text()

CDDLは、最初の非終端記号がファイルの最初の記号であることを期待しています。このため、CDDLの最初のフラグメントをここに示します。

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; これはツールを静かにするために定義されています： Internal_Types = Sig_structure / Enc_structure / MAC_structure

非終端記号Internal_Typesは、この文書の作成中に使用される自動検証ツールを処理するために定義されています。これは、セキュリティ計算に使用されるが転送のために発行されない非終端記号を参照します。

1.5. CBOR関連の用語

JSONでは、マップはオブジェクトと呼ばれ、テキスト文字列という1種類のマップキーしかありません。COSEでは、テキスト文字列、負の整数、および符号なし整数をマップキーとして使用します。整数は、エンコーディングのコンパクトさと簡単な比較のために使用されます。テキスト文字列を含めることで、マップキーとして使用する短いエンコードされた値の追加範囲も可能になります。"key" という単語は主に暗号化キーという別の意味で使用されるため、マップキーとしてのこの使用法には "label"（ラベル）という用語を使用します。

この仕様で定義されているCBORマップでは、テキスト文字列でも整数でもないラベルが存在することはエラーです。アプリケーションは、処理に失敗するか、誤ったラベルを無視してメッセージを処理することができます。ただし、誤ったラベルを持つメッセージを作成してはなりません (MUST NOT)。

CDDL文法フラグメントは、前の段落のように非終端記号 "label" と、任意の値を許可する "values" を定義しています。

label = int / tstr values = any

1.6. 文書の用語

この文書では、次の用語を使用します。

Byte: オクテットの同義語。

Constrained Application Protocol (CoAP): 制約のあるシステムで使用するための専用のWeb転送プロトコル。[RFC7252] で定義されています。

Authenticated Encryption (AE) algorithms [RFC5116]: 暗号化サービスとともに内容の認証チェックを提供する暗号化アルゴリズム。COSEで使用されるAEアルゴリズムの例は、AES Key Wrap [RFC3394] です。これらのアルゴリズムはキー暗号化に使用されますが、関連データ付き認証暗号化 (AEAD) アルゴリズムが推奨されます。

AEAD algorithms [RFC5116]: AEアルゴリズムと同じコンテンツの認証サービスを提供し、暗号化された本体の一部ではない関連データを認証サービスに含めることも許可する暗号化アルゴリズム。COSEで使用されるAEADアルゴリズムの例は、AES-GCM [RFC5116] です。これらのアルゴリズムはコンテンツ暗号化に使用され、キー暗号化にも使用できます。

"Context"（コンテキスト）は、COSEメッセージの一部ではない情報を表すために文書全体で使用されます。コンテキストの一部である情報は、プロトコル相互作用、関連するキー構造、プログラム構成など、いくつかの異なるソースから取得できます。使用するコンテキストは、暗黙的であるか、[RFC8613] で定義されている "kid context" ヘッダーパラメータを使用して識別されるか、プロトコル固有の識別子によって識別されます。コンテキストは通常、暗号化構造に含める必要があります。詳細については、セクション4.3を参照してください。

用語 "byte string"（バイト文字列）はバイトのシーケンスに使用され、用語 "text string"（テキスト文字列）は文字のシーケンスに使用されます。

に最終更新