1.1. 要件用語

本書におけるキーワード「MUST」、「MUST NOT」、 「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および 「OPTIONAL」は、ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174]に記述されるとおりに解釈されます。¶

1.3. JOSEからの設計上の変更

• 暗号化、署名、およびMACedメッセージを容易に 識別でき、かつ一貫した見方を維持できるように、単一の全体メッセージ構造が定義されました。¶
• 署名付きメッセージは、コンテンツに関連する 保護ヘッダーパラメータおよび非保護ヘッダーパラメータと、署名に関連するものを区別します。¶
• MACedメッセージは署名付きメッセージから分離されます。¶
• MACedメッセージは、MAC認証鍵を取得するために、 エンベロープ化メッセージと同じ受信者アルゴリズムの集合を使用する機能を持ちます。¶
• バイナリデータの符号化には、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:

ブール値（true: メジャー型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が配列内に1回以上現れることを 示します。¶

* 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

; This is defined to make the tool quieter:
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

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

このセクションは、共通ヘッダーパラメータの集合を定義します。 これらのヘッダーパラメータの概要は表3にあります。 ラベルの値と値の型を判断するには、この表を参照すべきです。¶

このセクションで定義されるヘッダーパラメータの集合は次のとおりです。¶

alg:

このヘッダーパラメータは、 セキュリティ処理に使用されるアルゴリズムを示すために使用されます。このヘッダーパラメータは、 それが可能な場合には認証されなければMUSTなりません。このサポートは、AEADアルゴリズムまたは構造 （例: COSE_SignおよびCOSE_Mac0）によって提供されます。この認証は、ヘッダーパラメータを protected-header-parametersバケットに配置することによって、または外部から提供されるデータ （セクション4.3）の一部として行うことができます。値は、 「COSE Algorithms」レジストリ（[COSE.Algorithms]を参照）から取得されます。¶

crit:

このヘッダーパラメータは、メッセージを処理する アプリケーションが理解する必要のある保護ヘッダーパラメータを示すために使用されます。 本書で定義されるヘッダーパラメータは、すべての実装が理解すべきであるため、 含める必要はありません。さらに、[RFC8152]によって定義されたヘッダーパラメータ 「counter signature」（ラベル7）は、その文書に従い、すべての実装がそれを 理解すると仮定する送信者との互換性を維持するため、新しい実装で理解されなければなりません。 存在する場合、「crit」ヘッダーパラメータはprotected-header-parametersバケットに 配置されなければMUSTなりません。配列には少なくとも 1つの値が含まれていなければMUSTなりません。¶

すべてのヘッダーパラメータラベルを「crit」ヘッダーパラメータに含める必要はありません。 配列にどのヘッダーパラメータを配置するかを決定する規則は次のとおりです。¶

• 0から7の範囲の整数ラベルは 省略すべきSHOULDです。¶
• -1から-128の範囲の整数ラベルは省略できます。 アルゴリズムは、この範囲にラベルを割り当てることができます。その場合、ラベルの内容を 処理できることは、アルゴリズムの実装における中核であると見なされます。 アルゴリズムは、この範囲外にラベルを割り当て、ラベルの内容を処理できることが アルゴリズムの中核機能とは見なされないが、このインスタンスを正しく処理するために 理解される必要がある場合に、それらを「crit」ヘッダーパラメータに含めることができます。 -129から-65536の範囲の整数ラベルは、これらが一般には サポートされない可能性のある、あまり一般的でないヘッダーパラメータであるため、 含めるべきSHOULDです。¶
• アプリケーションに必要なヘッダーパラメータの ラベルは省略してもMAYかまいません。アプリケーションは、 そのラベルを省略できるかどうかを宣言する文を持つべきです。¶

「crit」によって示されるヘッダーパラメータは、セキュリティライブラリコードによって処理することも、 セキュリティライブラリを使用するアプリケーションによって処理することもできます。唯一の要件は、 そのヘッダーパラメータが処理されることです。「crit」値リストが、 protected-header-parametersバケットに存在しないヘッダーパラメータのラベルを含む場合、 これはメッセージ処理における致命的エラーです。¶

content type:

このヘッダーパラメータは、 「payload」または「ciphertext」フィールド内のデータのコンテンツ型を示すために 使用されます。整数は「CoAP Content-Formats」IANAレジストリ表 [COAP.Formats]から取得されます。テキスト値は 「<type-name>/<subtype-name>」の構文に従います。ここで <type-name>および<subtype-name>は [RFC6838]のセクション4.2で定義されています。 先頭および末尾の空白は許可されません。 テキスト形式のコンテンツ型値は、パラメータおよびサブパラメータとともに、IANAの 「Media Types」レジストリを使用して特定できます。コンテンツ構造が潜在的に曖昧な場合、 アプリケーションはこのヘッダーパラメータを提供すべきSHOULDです。¶

kid:

このヘッダーパラメータは、 必要な暗号鍵を見つけるための入力として使用できる1つのデータを識別します。この ヘッダーパラメータの値は、COSE_Key構造内の「kid」メンバーと照合できます。 鍵配布の他の方法は、照合される同等のフィールドを定義できます。アプリケーションは、 「kid」値が一意であると仮定してはMUST NOTなりません。同じ「kid」値を持つ鍵が 複数存在する場合があるため、この「kid」に関連付けられたすべての鍵を確認する必要がある場合があります。 「kid」値の内部構造は定義されておらず、アプリケーションはそれに依存できません。鍵識別子値は、 使用する鍵についてのヒントです。これはセキュリティ上重要なフィールドではありません。 このため、unprotected-header-parametersバケットに配置できます。¶

IV:

このヘッダーパラメータは、 Initialization Vector（IV）値を保持します。一部の対称暗号化アルゴリズムでは、 これはnonceと呼ばれる場合があります。AEおよびAEADアルゴリズムでは、IVを変更すると 復号が失敗するため、IVは非保護バケットに配置できます。¶

Partial IV:

このヘッダーパラメータはIV値の一部を保持します。 COSE_Encrypt0構造を使用するとき、IVの一部は鍵に関連付けられたcontextの一部 （Context IV）であり、別の一部は各メッセージで変更できます（Partial IV）。 このフィールドは、各メッセージでIVを変更させる値を運ぶために使用されます。 値を変更すると、復号によって明らかに破損していると検出しやすい平文が得られるため、 Partial IVは非保護バケットに配置できます。 「Initialization Vector」および「Partial Initialization Vector」ヘッダーパラメータは、 同じセキュリティレイヤー内に両方存在してはMUST NOTなりません。¶

メッセージIVは次の手順で生成されます。¶

1. Partial IVをIVの長さ（アルゴリズムによって決定される）まで ゼロで左詰めします。¶
2. パディングされたPartial IVとContext IVのXORを取ります。¶

このセクションで定義されるヘッダーパラメータの集合を表すCDDL断片を 以下に示します。各ヘッダーパラメータは任意としてタグ付けされています。これは、それらが すべてのマップに存在する必要はないためです。特定のマップで必要とされるヘッダーパラメータについては 上で説明されています。¶

Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? ( 5 => bstr //    ; IV
        6 => bstr )     ; Partial IV
)

4.1. 1人以上の 署名者による署名

COSE_Sign構造では、メッセージペイロードに1つ以上の署名を適用できます。 内容に関連するヘッダーパラメータと、署名に関連するヘッダーパラメータは、署名自体とともに運ばれます。 これらのヘッダーパラメータは署名によって認証される場合も、単に存在するだけの場合もあります。 内容に関するヘッダーパラメータの例として、content typeヘッダーパラメータがあります。 署名に関するヘッダーパラメータの例としては、署名を作成するために使用されたアルゴリズムと鍵があります。¶

[RFC5652]は次のように示しています。¶

複数の署名が存在する場合、ある署名者に関連付けられた1つの署名の検証が成功すれば、通常はその署名者による 署名として成功したものと扱われます。しかし、別の規則が必要となるアプリケーション環境もあります。 各署名者について1つの有効な署名という規則以外を採用するアプリケーションは、その規則を指定しなければなりません。 また、署名者識別子の単純な照合だけでは、署名が同じ署名者によって生成されたかどうかを判断するのに十分でない場合、 アプリケーション仕様は、どの署名が同じ署名者によって生成されたかを判断する方法を記述しなければなりません。 署名者が複数の署名を含める主な理由は、異なる受信者コミュニティをサポートすることです。¶

たとえば、COSE_Sign構造には、Edwards曲線 Digital Signature Algorithm（EdDSA）[RFC8032] とElliptic Curve Digital Signature Algorithm（ECDSA）[DSS]で生成された署名を含めることができます。これにより、受信者は 一方または他方のアルゴリズムに関連付けられた署名を検証できます。複数署名の評価に関するより詳細な情報は [RFC5752]にあります。¶

署名構造は、それが使用されるcontextに応じて、タグ付きまたはタグなしのいずれかとして 符号化できます。タグ付きCOSE_Sign構造はCBORタグ98によって識別されます。これを表すCDDL断片は次のとおりです。¶

COSE_Sign_Tagged = #6.98(COSE_Sign)

COSE署名付きメッセージは2つの部分で定義されます。本文とメッセージに関する情報を運ぶ CBORオブジェクトはCOSE_Sign構造と呼ばれます。署名と署名に関する情報を運ぶCBORオブジェクトは COSE_Signature構造と呼ばれます。COSE署名付きメッセージの例はAppendix C.1にあります。¶

COSE_Sign構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

payload:

このフィールドは、署名されるシリアライズされた内容を含みます。 payloadがメッセージ内に存在しない場合、アプリケーションはpayloadを別途提供する必要があります。 payloadは、変更されずに転送されることを保証するためにbstrでラップされます。 payloadが別途転送される（「detached content」）場合、この位置にはnil CBORオブジェクトが配置され、 それが変更されずに転送されることを保証する責任はアプリケーションにあります。¶

注: メッセージ復元アルゴリズムを伴う署名が使用される場合（セクション8.1）、復元できる最大バイト数は元のpayloadの長さです。 符号化されたpayloadのサイズは、復元されるバイト数だけ減少します。 元のpayloadのすべてのバイトが消費される場合、転送されるpayloadは存在しないものとしてではなく、 ゼロ長バイト文字列として符号化されます。¶

signatures:

このフィールドは署名の配列です。各署名は COSE_Signature構造として表されます。¶

COSE_Signについて上記の本文を表すCDDL断片は次のとおりです。¶

COSE_Sign = [
    Headers,
    payload : bstr / nil,
    signatures : [+ COSE_Signature]
]

COSE_Signature構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

signature:

このフィールドは計算された署名値を含みます。 フィールドの型はbstrです。署名値が8ビットの倍数でない場合、アルゴリズムはパディングを指定しなければ MUSTなりません。¶

COSE_Signatureについて上記の本文を表すCDDL断片は次のとおりです。¶

COSE_Signature =  [
    Headers,
    signature : bstr
]

4.3. 外部から提供される データ

COSEで提供される機能の1つに、アプリケーションが、認証されるべきだがCOSEオブジェクトの一部として 運ばれない追加データを提供できる機能があります。 これをサポートする主な理由は、CoAPメッセージ構造 [RFC7252]を見ると分かります。そこでは、 payloadの前にoptionを運ぶ機能が存在します。 この位置に配置できるデータの例として、CoAPコードまたはCoAP optionがあります。 データがCoAPメッセージのヘッダー内にある場合、それはプロキシがプロキシ処理を行う際に利用できます。 たとえば、Accept optionは、適切な値がプロキシのキャッシュにあるかどうかを判断するために プロキシで使用できます。 送信者はadditional-data機能を使用して、プロキシまたは攻撃者によって行われたAccept値の集合への 変更を検出できるようにできます。このフィールドを外部から提供されるデータに含めることで、 その後の変更は、サーバーのメッセージ処理を失敗させます。¶

本書は、外部から提供される認証済みデータのバイト配列を使用するためのプロセスを説明します。 バイト配列を構築する方法は、アプリケーションの関数です。 この機能を使用するアプリケーションは、外部から提供される認証済みデータをどのように構築するかを 定義する必要があります。このような構築では、次の問題を考慮する必要があります。¶

• 複数の項目が含まれる場合、異なる入力から同じバイト文字列が生成されないことをアプリケーションは 保証する必要があります。 問題のあるシナリオが発生する例として、テキスト文字列「AB」と「CDE」を連結する場合、または テキスト文字列「ABC」と「DE」を連結する場合があります。 これは通常、フィールドを固定幅にすること、および/またはフィールドの長さを出力の一部として 符号化することによって対処されます。 CoAP [RFC7252]のoptionを例として使用すると、 これらのフィールドはTLV構造を使用するため、問題なく連結できます。¶
• 複数の項目が含まれる場合、項目の順序を定義する必要があります。 CoAPのoptionを例にすると、アプリケーションはフィールドをoption番号順に並べると述べることができます。¶
• アプリケーションは、バイト文字列が両側で同じになることを保証する必要があります。 CoAPのoptionを使用すると、同じ相対番号付けが維持される場合に問題が生じる可能性があります。 中間ノードがoptionを挿入または削除すると、相対番号付けの行われ方が変わります。 アプリケーションは、相対番号が外部データに含まれるoptionだけに対する相対番号として 再符号化されなければならないことを指定する必要があります。¶

4.4. 署名および 検証プロセス

署名を作成するには、明確に定義されたバイト文字列が必要です。 Sig_structureは正準形式を作成するために使用されます。 この署名および検証プロセスは、本文情報（COSE_SignまたはCOSE_Sign1）、 署名者情報（COSE_Signature）、およびアプリケーションデータ（外部ソース）を入力として取ります。 Sig_structureはCBOR配列です。 Sig_structureのフィールドは順に次のとおりです。¶

1. 署名のcontextを識別するcontextテキスト文字列。contextテキスト文字列は次のとおりです。¶

   • COSE_Signature構造を使用する署名では 「Signature」。¶
   • COSE_Sign1構造を使用する署名では 「Signature1」。¶
2. 本文構造からの保護属性。bstr型で符号化されます。保護属性がない場合は、 ゼロ長バイト文字列が使用されます。¶
3. 署名者構造からの保護属性。bstr型で符号化されます。保護属性がない場合は、 ゼロ長バイト文字列が使用されます。このフィールドはCOSE_Sign1署名構造では省略されます。¶
4. アプリケーションから外部的に提供されるデータ。bstr型で符号化されます。 このフィールドが提供されない場合、デフォルトでゼロ長バイト文字列になります。（このフィールドの構築に関する アプリケーション向け指針についてはセクション4.3を参照してください。）¶
5. 署名されるpayload。bstr型で符号化されます。ここでは、転送方法にかかわらず、 完全なpayloadが使用されます。¶

上記の本文を記述するCDDL断片は次のとおりです。¶

Sig_structure = [
    context : "Signature" / "Signature1",
    body_protected : empty_or_serialized_map,
    ? sign_protected : empty_or_serialized_map,
    external_aad : bstr,
    payload : bstr
]

署名を計算する方法は次のとおりです。¶

1. Sig_structureを作成し、適切なフィールドを設定します。¶
2. セクション 9で説明される符号化を使用して、Sig_structureをバイト文字列に符号化することで ToBeSigned値を作成します。¶
3. 署名作成アルゴリズムを呼び出し、K（署名に使用する鍵）、alg（署名に使用する アルゴリズム）、およびToBeSigned（署名される値）を渡します。¶
4. 結果として得られた署名値を正しい場所に配置します。 これはCOSE_SignatureまたはCOSE_Sign1構造の「signature」フィールドです。¶

署名を検証する手順は次のとおりです。¶

1. Sig_structureを作成し、適切なフィールドを設定します。¶
2. セクション 9で説明される符号化を使用して、Sig_structureをバイト文字列に符号化することで ToBeSigned値を作成します。¶
3. 署名検証アルゴリズムを呼び出し、K（検証に使用する鍵）、alg（署名に使用された アルゴリズム）、ToBeSigned（署名される値）、およびsig（検証される署名）を渡します。¶

署名検証の実行に加えて、アプリケーションは、その鍵が署名主体と正しく対応していること、および 操作を実行する前に署名主体が権限を付与されていることを保証するための適切なチェックを行います。¶

5.1. エンベロープ化COSE 構造

エンベロープ化構造では、メッセージの1人以上の受信者を扱うことができます。 内容に関するヘッダーパラメータと、受信者情報に関するヘッダーパラメータをメッセージ内で運ぶための 規定があります。内容に関連付けられた保護ヘッダーパラメータは、コンテンツ暗号化アルゴリズムによって 認証されます。受信者に関連付けられた保護ヘッダーパラメータは、アルゴリズムがそれをサポートする場合、 受信者アルゴリズムによって認証されます。内容に関するヘッダーパラメータの例として、内容の型と コンテンツ暗号化アルゴリズムがあります。受信者に関するヘッダーパラメータの例として、受信者の鍵識別子と 受信者の暗号化アルゴリズムがあります。¶

平文と鍵の両方を暗号化するために、同じ技法とほぼ同じ構造が使用されます。 これは、「Cryptographic Message Syntax（CMS）」[RFC5652]と「JSON Web Encryption（JWE）」 [RFC7516]の両方で使用されるアプローチとは異なります。 そこでは、コンテンツレイヤーと受信者レイヤーに異なる構造が使用されます。 2つの構造が定義されています。暗号化された内容を保持するCOSE_Encryptと、受信者用の 暗号化された鍵を保持するCOSE_recipientです。 エンベロープ化メッセージの例はAppendix C.3にあります。¶

COSE_Encrypt構造は、それが使用されるcontextに応じて、タグ付きまたはタグなしのいずれかとして 符号化できます。タグ付きCOSE_Encrypt構造はCBORタグ96によって識別されます。これを表すCDDL断片は次のとおりです。¶

COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)

COSE_Encrypt構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

ciphertext:

このフィールドは、bstrとして符号化された 暗号文を含みます。暗号文が暗号化プロセスに関する制御情報とは独立して転送される （すなわち、detached content）場合、このフィールドはnil値として符号化されます。¶

recipients:

このフィールドは受信者情報構造の配列を 含みます。受信者情報構造の型はCOSE_recipientです。¶

上記の本文に対応するCDDL断片は次のとおりです。¶

COSE_Encrypt = [
    Headers,
    ciphertext : bstr / nil,
    recipients : [+COSE_recipient]
]

COSE_recipient構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

ciphertext:

このフィールドは、bstrとして符号化された 暗号化された鍵を含みます。すべての符号化された鍵は対称鍵です。鍵のバイナリ値が内容です。 暗号化された鍵がない場合、このフィールドはnil値として符号化されます。¶

recipients:

このフィールドは受信者情報構造の配列を 含みます。受信者情報構造の型はCOSE_recipientです （この例はAppendix Bにあります）。受信者情報構造がない場合、 この要素は存在しません。¶

COSE_recipientについて上記の本文に対応するCDDL断片は次のとおりです。¶

COSE_recipient = [
    Headers,
    ciphertext : bstr / nil,
    ? recipients : [+COSE_recipient]
]

5.2. 単一受信者 暗号化

COSE_Encrypt0暗号化構造には、メッセージの受信者を指定する機能はありません。 この構造は、オブジェクトの受信者が、メッセージを復号するために使用する鍵の識別情報をすでに 知っていることを前提としています。鍵を受信者に識別させる必要がある場合は、エンベロープ化構造を 使用するのが望ましいです。¶

暗号化メッセージの例はAppendix C.4にあります。¶

COSE_Encrypt0構造は、それが使用されるcontextに応じて、タグ付きまたはタグなしの いずれかとして符号化できます。タグ付きCOSE_Encrypt0構造はCBORタグ16によって識別されます。 これを表すCDDL断片は次のとおりです。¶

COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

COSE_Encrypt0構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

ciphertext:

これはセクション5.1で説明されるとおりです。¶

上記の本文に対応するCOSE_Encrypt0のCDDL断片は次のとおりです。¶

COSE_Encrypt0 = [
    Headers,
    ciphertext : bstr / nil,
]

5.3. AEADアルゴリズムで 暗号化および復号する方法

AEADアルゴリズムの暗号化アルゴリズムはかなり単純です。最初の手順は、 認証済みデータ構造のための一貫したバイト文字列を作成することです。この目的のために、 Enc_structureを使用します。Enc_structureはCBOR配列です。Enc_structureのフィールドは順に 次のとおりです。¶

1. 認証済みデータ構造のcontextを識別するcontextテキスト文字列。 contextテキスト文字列は次のとおりです。¶

   • COSE_Encrypt0データ構造の コンテンツ暗号化では「Encrypt0」。¶
   • COSE_Encryptデータ構造の 第1レイヤー（すなわち、コンテンツ暗号化）では「Encrypt」。¶
   • COSE_Encryptデータ構造に配置される 受信者符号化では「Enc_Recipient」。¶
   • MACedメッセージ構造に配置される 受信者符号化では「Mac_Recipient」。¶
   • 受信者構造に配置される 受信者符号化では「Rec_Recipient」。¶
2. 本文構造からの保護属性。bstr型で符号化されます。保護属性がない場合は、 ゼロ長バイト文字列が使用されます。¶
3. アプリケーションから外部的に提供されるデータ。bstr型で符号化されます。 このフィールドが提供されない場合、デフォルトでゼロ長バイト文字列になります。（このフィールドの構築に関する アプリケーション向け指針についてはセクション4.3を参照してください。）¶

上記の本文を記述するCDDL断片は次のとおりです。¶

Enc_structure = [
    context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
        "Mac_Recipient" / "Rec_Recipient",
    protected : empty_or_serialized_map,
    external_aad : bstr
]

メッセージを暗号化する方法は次のとおりです。¶

1. Enc_structureを作成し、適切なフィールドを設定します。¶
2. セクション 9で説明される符号化を使用して、Enc_structureをバイト文字列（Additional Authenticated Data（AAD））に符号化します。¶

3. 暗号化鍵（K）を決定します。この手順は、使用される 受信者アルゴリズムのクラスに依存します。以下の場合です。¶

   No Recipients:

   使用する鍵は、現在のレイヤーの アルゴリズムと鍵によって決定されます。例として、key wrap鍵（セクション8.5.2）と事前共有秘密があります。¶

   Direct Encryption and Direct Key Agreement:

   鍵は受信者構造内の鍵とアルゴリズムによって決定されます。 使用される暗号化アルゴリズムと鍵のサイズは、受信者に使用されるKDFへの入力です。 （directの場合、KDFは恒等操作と考えることができます。） これらのアルゴリズムの例は、[RFC9053]のセクション6.1 および6.3にあります。¶

   Other:

   鍵はランダムに生成されます。¶

4. K（暗号化鍵）、P（平文）、およびAADを指定して暗号化アルゴリズムを呼び出します。 返された暗号文を構造の「ciphertext」フィールドに配置します。¶
5. non-directアルゴリズムを使用するメッセージの受信者については、K（暗号化鍵）を 平文として使用し、その受信者に対して暗号化アルゴリズムを再帰的に実行します。¶

メッセージを復号する方法は次のとおりです。¶

1. Enc_structureを作成し、適切なフィールドを設定します。¶
2. セクション9で説明される符号化を 使用して、Enc_structureをバイト文字列（AAD）に符号化します。¶

3. 復号鍵を決定します。この手順は、使用される受信者アルゴリズムの クラスに依存します。以下の場合です。¶

   No Recipients:

   使用する鍵は、現在のレイヤーの アルゴリズムと鍵によって決定されます。例として、key wrap鍵（セクション8.5.2）と事前共有秘密があります。¶

   Direct Encryption and Direct Key Agreement:

   鍵は受信者構造内の鍵とアルゴリズムによって決定されます。 使用される暗号化アルゴリズムと鍵のサイズは、受信者に使用されるKDFへの入力です。 （directの場合、KDFは恒等操作と考えることができます。）¶

   Other:

   鍵は、受信者構造の1つを デコードおよび復号することによって決定されます。¶

4. K（使用する復号鍵）、C（暗号文）、およびAADを指定して復号アルゴリズムを 呼び出します。¶

5.4. AEアルゴリズムで 暗号化および復号する方法

メッセージを暗号化する方法は次のとおりです。¶

1. 「protected」フィールドがゼロ長バイト文字列であることを検証します。¶
2. この操作に外部の追加認証済みデータが提供されていないことを検証します。¶

3. 暗号化鍵を決定します。この手順は、使用される受信者アルゴリズムの クラスに依存します。以下の場合です。¶

   No Recipients:

   使用する鍵は、現在のレイヤーの アルゴリズムと鍵によって決定されます。例として、key wrap鍵（セクション8.5.2）と事前共有秘密があります。¶

   Direct Encryption and Direct Key Agreement:

   鍵は受信者構造内の鍵と アルゴリズムによって決定されます。使用される暗号化アルゴリズムと鍵のサイズは、 受信者に使用されるKDFへの入力です。（directの場合、KDFは恒等操作と考えることができます。） これらのアルゴリズムの例は、[RFC9053]のセクション6.1 および6.3にあります。¶

   Other:

   鍵はランダムに生成されます。¶

4. K（使用する暗号化鍵）とP（平文）を指定して暗号化アルゴリズムを呼び出します。 返された暗号文を構造の「ciphertext」フィールドに配置します。¶
5. non-directアルゴリズムを使用するメッセージの受信者については、K（暗号化鍵）を 平文として使用し、その受信者に対して暗号化アルゴリズムを再帰的に実行します。¶

メッセージを復号する方法は次のとおりです。¶

1. 「protected」フィールドがゼロ長バイト文字列であることを検証します。¶
2. この操作に外部の追加認証済みデータが提供されていないことを検証します。¶

3. 復号鍵を決定します。この手順は、使用される受信者アルゴリズムの クラスに依存します。以下の場合です。¶

   No Recipients:

   使用する鍵は、現在のレイヤーの アルゴリズムと鍵によって決定されます。例として、key wrap鍵（セクション8.5.2）と事前共有秘密があります。¶

   Direct Encryption and Direct Key Agreement:

   鍵は受信者構造内の鍵と アルゴリズムによって決定されます。使用される暗号化アルゴリズムと鍵のサイズは、 受信者に使用されるKDFへの入力です。（directの場合、KDFは恒等操作と考えることができます。） これらのアルゴリズムの例は、[RFC9053]のセクション6.1 および6.3にあります。¶

   Other:

   鍵は、受信者構造の1つを デコードおよび復号することによって決定されます。¶

4. K（使用する復号鍵）とC（暗号文）を指定して復号アルゴリズムを呼び出します。¶

6.1. 受信者付き MACedメッセージ

複数受信者のMACedメッセージは、本文を運ぶためにこのセクションで定義される COSE_Mac構造と、MAC計算に使用される鍵を保持するためのCOSE_recipient構造（セクション5.1）という2つの構造を使用します。 MACedメッセージの例はAppendix C.5にあります。¶

MAC構造は、それが使用されるcontextに応じて、タグ付きまたはタグなしのいずれかとして 符号化できます。タグ付きCOSE_Mac構造はCBORタグ97によって識別されます。これを表すCDDL断片は 次のとおりです。¶

COSE_Mac_Tagged = #6.97(COSE_Mac)

COSE_Mac構造はCBOR配列です。配列のフィールドは順に次のとおりです。¶

protected:

これはセクション3で説明されるとおりです。¶

unprotected:

これはセクション3で説明されるとおりです。¶

payload:

このフィールドは、MACedされる シリアライズされた内容を含みます。payloadがメッセージ内に存在しない場合、アプリケーションは payloadを別途提供する必要があります。payloadは、変更されずに転送されることを保証するために bstrでラップされます。payloadが別途転送される（すなわち、detached content）場合、この位置には nil CBOR値が配置され、変更されずに転送されることを保証する責任はアプリケーションにあります。¶

tag:

このフィールドはMAC値を含みます。¶

recipients:

これはセクション5.1で説明されるとおりです。¶

COSE_Macについて上記の本文を表すCDDL断片は次のとおりです。¶

COSE_Mac = [
   Headers,
   payload : bstr / nil,
   tag : bstr,
   recipients : [+COSE_recipient]
]

7.1. COSE Key共通 パラメータ

本文書は、COSE Keyオブジェクトの共通パラメータの集合を定義します。表4は、このセクションで定義されるパラメータの概要を 提供します。特定の鍵型向けに定義されるパラメータもあります。 鍵型固有のパラメータは[RFC9053]にあります。¶

kty:

このパラメータは、この構造に対する 鍵のファミリー、したがって検出されるべき鍵型固有パラメータの集合を識別するために使用されます。 本文書で定義される値の集合は[COSE.KeyTypes]にあります。このパラメータは 鍵オブジェクト内に存在しなければMUSTなりません。実装は、 処理中のアルゴリズムに対して鍵型が適切であることを検証しなければMUSTなりません。鍵型は、信頼判断プロセスの一部として含められなければ MUSTなりません。¶

alg:

このパラメータは、鍵とともに使用される アルゴリズムを制限するために使用されます。このパラメータが鍵構造内に存在する場合、アプリケーションは、 このアルゴリズムがその鍵が使用されるアルゴリズムと一致することを検証しなければ MUSTなりません。アルゴリズムが一致しない場合、この鍵オブジェクトは 暗号操作を実行するために使用してはMUST NOTなりません。同じ鍵が、異なるアルゴリズムを指定した、または アルゴリズムを指定しない別の鍵構造内に存在することもできます。ただし、これは不適切なセキュリティ慣行と見なされます。¶

kid:

このパラメータは、鍵の識別子を与えるために 使用されます。識別子は構造化されておらず、ユーザーが提供したバイト文字列から、鍵の公開部分に基づいて 計算された値まで、任意のものにできます。このフィールドは、確認が必要な鍵の集合を絞り込むために、 メッセージ内の「kid」パラメータと照合することを意図しています。 識別子の値は一意の値ではなく、異なる鍵であっても他の鍵オブジェクトに出現する可能性があります。¶

key_ops:

このパラメータは、鍵が使用されるべき 操作の集合を制限するために定義されています。フィールドの値は、表5からの 値の配列です。アルゴリズムは、現れてよいkey opsの値と、特定の操作に必要な値を定義します。 値の集合は[RFC7517]および [W3C.WebCrypto]のものと一致します。¶

Base IV:

このパラメータは、IVの基底部分を運ぶために定義されています。 これは、セクション3.1で定義される Partial IVヘッダーパラメータとともに使用されるように設計されています。このフィールドは、 鍵にBase IVを関連付け、その後、メッセージごとにPartial IVで変更できるようにします。¶

アプリケーションでBase IVを使用するときは、極めて慎重に扱う必要があります。 多くの暗号化アルゴリズムは、同じIVが2回使用されるとセキュリティを失います。¶

送信者ごとに異なる鍵が導出される場合、同じBase IVから開始しても、この条件を満たす可能性が高いです。 同じ鍵が複数の送信者に使用される場合、アプリケーションは送信者間でIV空間を分割する方法を 提供する必要があります。 これは、開始する異なる基点、または開始用の異なるPartial IVを提供し、鍵更新前に送信される メッセージ数を制限することで行えます。¶

11.1. COSE Header Parameters レジストリ

「COSE Header Parameters」レジストリは[RFC8152]によって定義されました。 IANAは、このレジストリの参照を[RFC8152]ではなく本文書を指すように更新しました。IANAはまた、 「counter signature」および「CounterSignature0」を除き、[RFC8152]を参照していた すべてのエントリを本文書を参照するように更新しました。「counter signature」および「CounterSignature0」の参照は、引き続き[RFC8152]を参照します。¶

11.2. COSE Key Common Parametersレジストリ

「COSE Key Common Parameters」レジストリ[COSE.KeyParameters]は[RFC8152]で定義されました。 IANAは、このレジストリの参照を[RFC8152]ではなく本文書を指すように更新しました。IANAはまた、 [RFC8152]を参照していたエントリを本文書を参照するように 更新しました。¶

11.6. 専門家レビュー 指示

[RFC8152]によって確立されたすべてのIANAレジストリは、少なくとも一部が Expert Review [RFC8126]として定義されています。このセクションは、 専門家が何を見るべきかについての一般的な指針を示しますが、専門家として指定されているのには理由があるため、 十分な裁量が与えられるべきです。¶

専門家レビュー担当者は、次を考慮すべきです。¶

• ポイント占有は抑制されるべきです。レビュー担当者は、 登録要求について十分な情報を得て、その使用が既存の登録と重複しないこと、およびそのコードポイントが デプロイメントで使用される可能性が高いことを確認するよう奨励されます。私的使用としてタグ付けされた 範囲は、テスト目的および閉じた環境を意図しています。他の範囲のコードポイントは、テスト用に割り当てるべきではありません。¶
• Standards Action範囲にコードポイントを登録するには、 Standards TrackまたはBCP RFCが必要です。Specification Required範囲については仕様が存在すべきですが、 RFCが利用可能になる前の早期割り当ては許容されると見なされます。first-come, first-served範囲については、 そのポイントが閉じた環境の外で相互運用可能な形で使用されることが期待される場合、仕様が必要です。 仕様が提供されない場合、提供される説明には、そのポイントが何に使用されるのかを識別するのに十分な情報が必要です。¶
• 専門家は、コードポイント割り当てを承認するとき、フィールドの 想定される使用を考慮すべきです。 Standards Action範囲がStandards Track文書にのみ利用可能であるという事実は、 Standards Track文書がその範囲外にポイントを割り当てられないことを意味しません。 符号化値の長さは、その長さのコードポイントがどれだけ残っているか、およびそれが使用されるデバイスの サイズと比較検討されるべきです。¶
• アルゴリズムが登録されるとき、虚栄的な登録は抑制されるべきです。 これを行う1つの方法は、登録に対してアルゴリズムのセキュリティ分析に関する追加文書の提供を要求することです。 もう1つ考慮すべきことは、そのアルゴリズムについてCrypto Forum Research Group（CFRG）の意見を求めることです。 アルゴリズムは、登録に適するために、コミュニティのセキュリティ要件とメッセージ構造の要件を 満たすことが期待されます。¶

C.1. 署名付き メッセージの例

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ]
    ]
  ]
)

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ],
      [
        / protected h'a1013823' / << {
            / alg / 1:-36 / ECDSA 521 /
          } >> ,
        / unprotected / {
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297'
      ]
    ]
  ]
)

98(
  [
    / protected h'a2687265736572766564f40281687265736572766564' /
    << {
        "reserved":false,
        / crit / 2:[
          "reserved"
        ]
      } >>,
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
18aba9d1fad1bd9c'
      ]
    ]
  ]
)

C.2. 単一署名者の例

18(
  [
    / protected h'a10126' / << {
        / alg / 1:-7 / ECDSA 256 /
      } >>,
    / unprotected / {
      / kid / 4:'11'
    },
    / payload / 'This is the content.',
    / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36'
  ]
)

C.3. エンベロープ化 メッセージの例

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >>,
    / unprotected / {
      / iv / 5:h'c9cf4df2fe6c632bf7886413'
    },
    / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
    / recipients / [
      [
        / protected h'a1013818' / << {
            / alg / 1:-25 / ECDH-ES + HKDF-256 /
          } >>,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:1,
            / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
            / y / -3:true
          },
          / kid / 4:'meriadoc.brandybuck@buckland.example'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >>,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a76c'
    },
    / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847',
    / recipients / [
      [
        / protected h'a10129' / << {
            / alg / 1:-10
          } >>,
        / unprotected / {
          / salt / -20:'aabbccddeeffgghh',
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'02d1f7e6f26c43d4868d87ce'
    },
    / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
e5f0165eee976b4a5f6c6f09d',
    / recipients / [
      [
        / protected / h'a101381f' / {
            \ alg \ 1:-32 \ ECDH-SS+A128KW \
          } / ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'0101'
        },
        / ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
e1c62'
      ]
    ]
  ]
)

C.4. 暗号化 メッセージの例

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a78c'
    },
    / ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
460ffb569'
  ]
)

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / partial iv / 6:h'61a7'
    },
    / ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca'
  ]
)

C.5. MACed メッセージの例

97(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'9e1226ba1f81b848',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-6 / direct /,
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41',
    / recipients / [
      [
        / protected h'a101381a' / << {
            / alg / 1:-27 / ECDH-SS + HKDF-256 /
          } >> ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a1010e' / << {
        / alg / 1:14 / AES-CBC-MAC-128//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'36f5afaf0bab5d43',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
b6eb0'
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
1e49e9323e',
    / recipients / [
      [
        / protected h'a101381c' / << {
            / alg / 1:-29 / ECDH-ES+A128KW /
          } >> ,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:3,
            / x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
d613574e7dc242f79c3',
            / y / -3:true
          },
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
      ],
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
518e7736549e998370695e6d6a83b4ae507bb'
      ]
    ]
  ]
)

C.6. MAC0 メッセージの例

17(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'726043745027214f'
  ]
)

C.7. COSE鍵

[
  {
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    1:2,
    2:'meriadoc.brandybuck@buckland.example'
  },
  {
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    1:2,
    2:'11'
  },
  {
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    1:2,
    2:'bilbo.baggins@hobbiton.example'
  },
  {
    -1:1,
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    1:2,
    2:'peregrin.took@tuckborough.example'
  }
]

[
  {
    1:2,
    2:'meriadoc.brandybuck@buckland.example',
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    -4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
208cf'
  },
  {
    1:2,
    2:'11',
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    -4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
7b4d3'
  },
  {
    1:2,
    2:'bilbo.baggins@hobbiton.example',
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    -4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
eb26d'
  },
  {
    1:4,
    2:'our-secret',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  },
  {
    1:2,
    -1:1,
    2:'peregrin.took@tuckborough.example',
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    -4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
df1c3'
  },
  {
    1:4,
    2:'our-secret2',
    -1:h'849b5786457c1491be3a76dcea6c4271'
  },
  {
    1:4,
    2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  }
]