RFC 8778 - Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8778.html
タイトル : RFC 8778 - HSS / LMSハッシュベースの署名アルゴリズムとCBORオブジェクトの署名および暗号化（COSE）の併用
翻訳編集 : 自動生成

[要約] RFC 8778は、CBOR Object Signing and Encryption (COSE) でのHSS/LMSハッシュベース署名アルゴリズムの使用に関する文書です。このRFCの目的は、量子コンピュータに対する耐性を持つハッシュベースの署名方式をCOSEフレームワーク内で利用可能にすることにあります。これは、特に量子コンピュータの脅威が現実のものとなる未来において、セキュアなデジタル署名の手段を提供することを意図しています。関連するRFCには、COSEを定義するRFC 8152や、HSS/LMS署名自体を詳述するRFC 8554などがあります。利用場面としては、セキュリティが重視される通信でのメッセージの認証やデータの完全性保証に適用されます。

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 8778                                Vigil Security
Category: Standards Track                                     April 2020
ISSN: 2070-1721

Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)

HSS / LMSハッシュベースの署名アルゴリズムとCBORオブジェクトの署名および暗号化（COSE）の併用

Abstract

概要

このドキュメントでは、CBORオブジェクト署名および暗号化（COSE）構文で階層型署名システム（HSS）/ Leighton-Micali署名（LMS）ハッシュベースの署名アルゴリズムを使用するための規則を指定します。 HSS / LMSアルゴリズムは、ハッシュベースのデジタル署名の1つの形式です。 RFC 8554で説明されています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8778.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8778で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

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

Table of Contents

   1.  Introduction
     1.1.  Motivation
     1.2.  Terminology
   2.  LMS Digital Signature Algorithm Overview
     2.1.  Hierarchical Signature System (HSS)
     2.2.  Leighton-Micali Signature (LMS)
     2.3.  Leighton-Micali One-Time Signature (LM-OTS) Algorithm
   3.  Hash-Based Signature Algorithm Identifiers
   4.  Security Considerations
   5.  Operational Considerations
   6.  IANA Considerations
     6.1.  COSE Algorithms Registry Entry
     6.2.  COSE Key Types Registry Entry
     6.3.  COSE Key Type Parameters Registry Entry
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Examples
     A.1.  Example COSE Full Message Signature
     A.2.  Example COSE_Sign1 Message
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) [RFC8152] syntax. The LMS system provides a one-time digital signature that is a variant of Merkle Tree Signatures (MTS). The HSS is built on top of the LMS system to efficiently scale for a larger number of signatures. The HSS/LMS algorithm is one form of a hash-based digital signature, and it is described in [HASHSIG]. The HSS/ LMS signature algorithm can only be used for a fixed number of signing operations. The number of signing operations depends upon the size of the tree. The HSS/LMS signature algorithm uses small public keys, and it has low computational cost; however, the signatures are quite large. The HSS/LMS private key can be very small when the signer is willing to perform additional computation at signing time; alternatively, the private key can consume additional memory and provide a faster signing time. The HSS/LMS signatures [HASHSIG] are currently defined to use exclusively SHA-256 [SHS].

このドキュメントでは、CBORオブジェクトの署名と暗号化（COSE）[RFC8152]構文で階層型署名システム（HSS）/ Leighton-Micali署名（LMS）ハッシュベースの署名アルゴリズムを使用するための規則を指定します。 LMSシステムは、Merkle Tree Signatures（MTS）の変形であるワンタイムデジタル署名を提供します。 HSSはLMSシステムの上に構築され、より多くのシグネチャに効率的にスケーリングします。 HSS / LMSアルゴリズムはハッシュベースのデジタル署名の1つの形式であり、[HASHSIG]で説明されています。 HSS / LMS署名アルゴリズムは、一定数の署名操作にのみ使用できます。署名操作の数は、ツリーのサイズによって異なります。 HSS / LMS署名アルゴリズムは小さな公開鍵を使用し、計算コストが低くなります。ただし、署名は非常に大きいです。署名者が署名時に追加の計算を実行する意思がある場合、HSS / LMS秘密鍵は非常に小さくなります。または、秘密鍵は追加のメモリを消費し、署名時間を短縮できます。 HSS / LMS署名[HASHSIG]は現在、SHA-256 [SHS]のみを使用するように定義されています。

1.1. Motivation

1.1. 動機

Recent advances in cryptanalysis [BH2013] and progress in the development of quantum computers [NAS2019] pose a threat to widely deployed digital signature algorithms. As a result, there is a need to prepare for a day that cryptosystems, such as RSA and DSA, that depend on discrete logarithm and factoring cannot be depended upon.

暗号解読の最近の進歩[BH2013]および量子コンピューターの開発の進歩[NAS2019]は、広く展開されているデジタル署名アルゴリズムに脅威をもたらします。その結果、RSAやDSAなどの離散対数と因数分解に依存する暗号化システムに依存できない日のために準備する必要があります。

If large-scale quantum computers are ever built, these computers will have more than a trivial number of quantum bits (qubits), and they will be able to break many of the public-key cryptosystems currently in use. A post-quantum cryptosystem [PQC] is a system that is secure against such large-scale quantum computers. When it will be feasible to build such computers is open to conjecture; however, RSA [RFC8017], DSA [DSS], Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS], and Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] are all vulnerable if large-scale quantum computers come to pass.

大規模な量子コンピューターが構築されると、これらのコンピューターはごくわずかな数の量子ビット（量子ビット）を持ち、現在使用されている公開鍵暗号システムの多くを破ることができます。ポスト量子暗号システム[PQC]は、このような大規模な量子コンピューターに対して安全なシステムです。そのようなコンピュータを構築することが可能になるのはいつか、推測の余地があります。ただし、RSA [RFC8017]、DSA [DSS]、楕円曲線デジタル署名アルゴリズム（ECDSA）[DSS]、およびエドワーズ曲線デジタル署名アルゴリズム（EdDSA）[RFC8032]は、大規模な量子コンピューターが通過する場合、すべて脆弱です。

Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. The use of HSS/ LMS hash-based signatures to protect software update distribution will allow the deployment of future software that implements new cryptosystems. By deploying HSS/LMS today, authentication and integrity protection of the future software can be provided, even if advances break current digital-signature mechanisms.

HSS / LMS署名アルゴリズムは離散対数や因数分解の難易度に依存しないため、HSS / LMS署名アルゴリズムはポスト量子安全であると見なされます。ソフトウェア更新の配布を保護するためにHSS / LMSハッシュベースの署名を使用すると、新しい暗号化システムを実装する将来のソフトウェアの展開が可能になります。今日のHSS / LMSを導入することにより、現在のデジタル署名メカニズムが進歩しても、将来のソフトウェアの認証と完全性保護を提供できます。

1.2. Terminology

1.2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. LMS Digital Signature Algorithm Overview

2. LMSデジタル署名アルゴリズムの概要

This specification makes use of the hash-based signature algorithm specified in [HASHSIG], which is the Leighton and Micali adaptation [LM] of the original Lamport-Diffie-Winternitz-Merkle one-time signature system [M1979][M1987][M1989a][M1989b].

この仕様は、元のLamport-Diffie-Winternitz-Merkleワンタイム署名システム[M1979] [M1987] [M1989aのLeighton and Micali適応[LM]である、[HASHSIG]で指定されたハッシュベースの署名アルゴリズムを利用します。 ] [M1989b]。

The hash-based signature algorithm has three major components:

ハッシュベースの署名アルゴリズムには、3つの主要なコンポーネントがあります。

* Hierarchical Signature System (HSS) -- see Section 2.1

* 階層署名システム（HSS）-セクション2.1を参照

* Leighton-Micali Signature (LMS) -- see Section 2.2

* Leighton-Micali Signature（LMS）-セクション2.2を参照

* Leighton-Micali One-time Signature (LM-OTS) Algorithm-- see Section 2.3

* Leighton-Micaliワンタイム署名（LM-OTS）アルゴリズム-セクション2.3を参照

As implied by the name, the hash-based signature algorithm depends on a collision-resistant hash function. The hash-based signature algorithm specified in [HASHSIG] currently makes use of the SHA-256 one-way hash function [SHS], but it also establishes an IANA registry to permit the registration of additional one-way hash functions in the future.

名前からわかるように、ハッシュベースの署名アルゴリズムは、衝突に強いハッシュ関数に依存しています。 [HASHSIG]で指定されているハッシュベースの署名アルゴリズムは現在、SHA-256一方向ハッシュ関数[SHS]を利用していますが、IANAレジストリを確立して、将来追加の一方向ハッシュ関数を登録できるようにもしています。

2.1. Hierarchical Signature System (HSS)

2.1. 階層署名システム（HSS）

The hash-based signature algorithm specified in [HASHSIG] uses a hierarchy of trees. The N-time Hierarchical Signature System (HSS) allows subordinate trees to be generated when needed by the signer. Otherwise, generation of the entire tree might take weeks or longer.

[HASHSIG]で指定されたハッシュベースの署名アルゴリズムは、ツリーの階層を使用します。 N-Time Hierarchical Signature System（HSS）により、署名者が必要なときに下位ツリーを生成できます。そうしないと、ツリー全体の生成に数週間以上かかる場合があります。

An HSS signature, as specified in [HASHSIG], carries the number of signed public keys (Nspk), followed by that number of signed public keys, followed by the LMS signature, as described in Section 2.2. The public key for the topmost LMS tree is the public key of the HSS system. The LMS private key in the parent tree signs the LMS public key in the child tree, and the LMS private key in the bottom-most tree signs the actual message. The signature over the public key and the signature over the actual message are LMS signatures, as described in Section 2.2.

セクション2.2で説明されているように、[HASHSIG]で指定されているHSS署名は、署名された公開鍵の数（Nspk）、それに続いて署名された公開鍵の数、LMS署名が含まれます。最上位のLMSツリーの公開鍵は、HSSシステムの公開鍵です。親ツリーのLMS秘密鍵は子ツリーのLMS公開鍵に署名し、一番下のツリーのLMS秘密鍵は実際のメッセージに署名します。セクション2.2で説明されているように、公開鍵の署名と実際のメッセージの署名はLMS署名です。

The elements of the HSS signature value for a stand-alone tree (a top tree with no children) can be summarized as:

スタンドアロンツリー（子のない最上位ツリー）のHSS署名値の要素は、次のように要約できます。

      u32str(0) ||
      lms_signature  /* signature of message */

where the notation comes from [HASHSIG].

表記は[HASHSIG]から来ています。

The elements of the HSS signature value for a tree with Nspk signed public keys can be summarized as:

Nspkで署名された公開鍵を持つツリーのHSS署名値の要素は、次のように要約できます。

      u32str(Nspk) ||
      signed_public_key[0] ||
      signed_public_key[1] ||
         ...
      signed_public_key[Nspk-2] ||
      signed_public_key[Nspk-1] ||
      lms_signature  /* signature of message */

As defined in Section 3.3 of [HASHSIG], a signed_public_key is the lms_signature over the public key followed by the public key itself. Note that Nspk is the number of levels in the hierarchy of trees minus 1.

[HASHSIG]のセクション3.3で定義されているように、signed_public_keyは、公開鍵に続くlms_signatureであり、その後に公開鍵自体が続きます。 Nspkは、ツリー階層のレベル数から1を引いたものであることに注意してください。

2.2. Leighton-Micali Signature (LMS)

2.2. レイトン・ミカリ署名（LMS）

Subordinate LMS trees are placed in the HSS structure, as discussed in Section 2.1. Each tree in the hash-based signature algorithm specified in [HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS systems have two parameters. The first parameter is the height of the tree, h, which is the number of levels in the tree minus one. The [HASHSIG] includes support for five values of this parameter: h=5, h=10, h=15, h=20, and h=25. Note that there are 2^h leaves in the tree. The second parameter is the number of bytes output by the hash function, m, which is the amount of data associated with each node in the tree. The [HASHSIG] specification supports only SHA-256 with m=32. An IANA registry is defined so that other hash functions could be used in the future.

セクション2.1で説明するように、下位LMSツリーはHSS構造に配置されます。 [HASHSIG]で指定されたハッシュベースの署名アルゴリズムの各ツリーは、Leighton-Micali Signature（LMS）システムを使用します。 LMSシステムには2つのパラメーターがあります。最初のパラメーターは、ツリーの高さhです。これは、ツリーのレベル数から1を引いたものです。 [HASHSIG]は、このパラメーターの5つの値（h = 5、h = 10、h = 15、h = 20、およびh = 25）のサポートを含みます。ツリーには2 ^ hの葉があることに注意してください。 2番目のパラメーターは、ハッシュ関数によって出力されるバイト数mです。これは、ツリー内の各ノードに関連付けられているデータの量です。 [HASHSIG]仕様は、m = 32のSHA-256のみをサポートします。 IANAレジストリは、他のハッシュ関数を将来使用できるように定義されています。

The [HASHSIG] specification supports five tree sizes:

[HASHSIG]仕様は5つのツリーサイズをサポートしています。

* LMS_SHA256_M32_H5

* LMS_SHA256_M32_H10

* LMS_SHA256_M32_H15

* LMS_SHA256_M32_H20

* LMS_SHA256_M32_H25

The [HASHSIG] specification establishes an IANA registry to permit the registration of additional hash functions and additional tree sizes in the future.

[HASHSIG]仕様は、追加のハッシュ関数と将来の追加のツリーサイズの登録を許可するIANAレジストリを確立します。

The [HASHSIG] specification defines the value I as the private key identifier, and the same I value is used for all computations with the same LMS tree. The value I is also available in the public key. In addition, the [HASHSIG] specification defines the value T[r] as the m-byte string associated with the ith node in the LMS tree, and the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the m-byte string associated with the root of the LMS tree.

[HASHSIG]仕様では、値Iを秘密鍵識別子として定義しており、同じLMSツリーでのすべての計算に同じI値が使用されます。値Iは公開鍵でも使用できます。さらに、[HASHSIG]仕様では、値T [r]をLMSツリーのi番目のノードに関連付けられたmバイト文字列として定義し、ノードには1から2 ^（h + 1）-1までのインデックスが付けられています。したがって、T [1]はLMSツリーのルートに関連付けられたmバイトの文字列です。

The LMS public key can be summarized as:

LMS公開鍵は次のように要約できます。

u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]

u32str（lms_algorithm_type）|| u32str（otstype）||私|| T [1]

As specified in [HASHSIG], the LMS signature consists of four elements:

[HASHSIG]で指定されているように、LMS署名は4つの要素で構成されています。

* the number of the leaf associated with the LM-OTS signature,

* LM-OTSシグネチャに関連付けられたリーフの番号、

* an LM-OTS signature, as described in Section 2.3,

* セクション2.3で説明されているLM-OTSシグネチャ

* a type code indicating the particular LMS algorithm, and

* 特定のLMSアルゴリズムを示すタイプコード、および

* an array of values that is associated with the path through the tree from the leaf associated with the LM-OTS signature to the root.

* LM-OTSシグニチャーに関連付けられたリーフからルートへのツリーのパスに関連付けられた値の配列。

The array of values contains the siblings of the nodes on the path from the leaf to the root but does not contain the nodes on the path itself. The array for a tree with height h will have h values. The first value is the sibling of the leaf, the next value is the sibling of the parent of the leaf, and so on up the path to the root.

値の配列には、リーフからルートへのパス上のノードの兄弟が含まれていますが、パス自体のノードは含まれていません。高さhのツリーの配列にはh値があります。最初の値は葉の兄弟であり、次の値は葉の親の兄弟であり、以下同様にルートへのパスです。

The four elements of the LMS signature value can be summarized as:

LMS署名値の4つの要素は、次のように要約できます。

u32str(q) || ots_signature || u32str(type) || path[0] || path[1] || ... || path[h-1]

u32str（q）|| ots_signature || u32str（タイプ）||パス[0] ||パス[1] || ... ||パス[h-1]

2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm

2.3. Leighton-Micaliワンタイム署名（LM-OTS）アルゴリズム

The hash-based signature algorithm depends on a one-time signature method. This specification makes use of the Leighton-Micali One-time Signature (LM-OTS) Algorithm [HASHSIG]. An LM-OTS has five parameters:

ハッシュベースの署名アルゴリズムは、ワンタイム署名方式に依存しています。この仕様は、Leighton-Micaliワンタイム署名（LM-OTS）アルゴリズム[HASHSIG]を利用しています。 LM-OTSには5つのパラメーターがあります。

n: The number of bytes output by the hash function. For SHA-256 [SHS], n=32.

n：ハッシュ関数が出力するバイト数。 SHA-256 [SHS]の場合、n = 32。

H: A preimage-resistant hash function that accepts byte strings of any length and returns an n-byte string.

H：任意の長さのバイト文字列を受け入れ、nバイトの文字列を返す、プリイメージ耐性のあるハッシュ関数。

w: The width in bits of the Winternitz coefficients. [HASHSIG] supports four values for this parameter: w=1, w=2, w=4, and w=8.

w：Winternitz係数のビット単位の幅。 [HASHSIG]は、このパラメーターの4つの値をサポートします：w = 1、w = 2、w = 4、およびw = 8。

p: The number of n-byte string elements that make up the LM-OTS signature.

p：LM-OTS署名を構成するnバイトの文字列要素の数。

ls: The number of left-shift bits used in the checksum function, which is defined in Section 4.4 of [HASHSIG].

ls：チェックサム関数で使用される左シフトビットの数。[HASHSIG]のセクション4.4で定義されています。

The values of p and ls are dependent on the choices of the parameters n and w, as described in Appendix B of [HASHSIG].

[HASHSIG]の付録Bで説明されているように、pとlsの値はパラメーターnとwの選択に依存します。

The [HASHSIG] specification supports four LM-OTS variants:

[HASHSIG]仕様は、4つのLM-OTSバリアントをサポートしています。

* LMOTS_SHA256_N32_W1

* LMOTS_SHA256_N32_W2

* LMOTS_SHA256_N32_W4

* LMOTS_SHA256_N32_W8

The [HASHSIG] specification establishes an IANA registry to permit the registration of additional hash functions and additional parameter sets in the future.

[HASHSIG]仕様は、将来追加のハッシュ関数と追加のパラメーターセットの登録を許可するIANAレジストリを確立します。

Signing involves the generation of C, which is an n-byte random value.

署名には、nバイトのランダム値であるCの生成が含まれます。

The LM-OTS signature value can be summarized as the identifier of the LM-OTS variant, the random value, and a sequence of hash values (y[0] through y[p-1]), as described in Section 4.5 of [HASHSIG]:

[のセクション4.5で説明されているように、LM-OTSシグネチャ値は、LM-OTSバリアントの識別子、ランダム値、およびハッシュ値のシーケンス（y [0]からy [p-1]）として要約できます。 HASHSIG]：

u32str(otstype) || C || y[0] || ... || y[p-1]

u32str（otstype）|| C ||と[0] || ... ||と[p-1]

3. Hash-Based Signature Algorithm Identifiers

3. ハッシュベースの署名アルゴリズム識別子

The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two signature algorithm schemes. This specification makes use of the signature with appendix scheme for hash-based signatures.

CBORオブジェクトの署名と暗号化（COSE）[RFC8152]は、2つの署名アルゴリズムスキームをサポートしています。この仕様では、ハッシュベースの署名に、付録スキームを使用した署名を利用しています。

The signature value is a large byte string, as described in Section 2. The byte string is designed for easy parsing. The HSS, LMS, and LM-OTS components of the signature value format include counters and type codes that indirectly provide all of the information that is needed to parse the byte string during signature validation.

セクション2で説明されているように、署名値は大きなバイト文字列です。バイト文字列は簡単に解析できるように設計されています。署名値形式のHSS、LMS、およびLM-OTSコンポーネントには、署名検証中にバイト文字列を解析するために必要なすべての情報を間接的に提供するカウンターとタイプコードが含まれています。

When using a COSE key for this algorithm, the following checks are made:

このアルゴリズムにCODEキーを使用すると、次のチェックが行われます。

* The 'kty' field MUST be 'HSS-LMS'.

* 「kty」フィールドは「HSS-LMS」でなければなりません。

* If the 'alg' field is present, it MUST be 'HSS-LMS'.

* 「alg」フィールドが存在する場合、「HSS-LMS」でなければなりません。

* If the 'key_ops' field is present, it MUST include 'sign' when creating a hash-based signature.

* 「key_ops」フィールドが存在する場合、ハッシュベースの署名を作成するときに「sign」を含める必要があります。

* If the 'key_ops' field is present, it MUST include 'verify' when verifying a hash-based signature.

* 「key_ops」フィールドが存在する場合、ハッシュベースの署名を検証するときに「verify」を含める必要があります。

* If the 'kid' field is present, it MAY be used to identify the top of the HSS tree. In [HASHSIG], this identifier is called 'I', and it is the 16-byte identifier of the LMS public key for the tree.

* 「kid」フィールドが存在する場合、HSSツリーの最上部を識別するために使用できます（MAY）。 [HASHSIG]では、この識別子は「I」と呼ばれ、ツリーのLMS公開鍵の16バイトの識別子です。

4. Security Considerations

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

The security considerations from [RFC8152] and [HASHSIG] are relevant to implementations of this specification.

[RFC8152]と[HASHSIG]のセキュリティに関する考慮事項は、この仕様の実装に関連しています。

There are a number of security considerations that need to be taken into account by implementers of this specification.

この仕様の実装者が考慮する必要のあるセキュリティ上の考慮事項がいくつかあります。

Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures. Along with the private key, the implementation MUST keep track of which leaf nodes in the tree have been used. Loss of integrity of this tracking data can cause a one-time key to be used more than once. As a result, when a private key and the tracking data are stored on nonvolatile media or in a virtual machine environment, failed writes, virtual machine snapshotting or cloning, and other operational concerns must be considered to ensure confidentiality and integrity.

実装は秘密鍵を保護しなければなりません。秘密鍵が侵害されると、署名を偽造できる可能性があります。実装は、秘密鍵とともに、ツリー内のどのリーフノードが使用されたかを追跡する必要があります。この追跡データの整合性が失われると、1回限りのキーが複数回使用される可能性があります。その結果、秘密キーと追跡データが不揮発性メディアまたは仮想マシン環境に保存される場合、機密性と整合性を確保するために、書き込みの失敗、仮想マシンのスナップショットまたはクローン作成、およびその他の運用上の考慮事項を考慮する必要があります。

When generating an LMS key pair, an implementation MUST generate each key pair independently of all other key pairs in the HSS tree.

LMSキーペアを生成する場合、実装はHSSツリー内の他のすべてのキーペアとは無関係に各キーペアを生成する必要があります。

An implementation MUST ensure that an LM-OTS private key is used to generate a signature only one time and ensure that it cannot be used for any other purpose.

実装では、LM-OTS秘密鍵を使用して署名を1回だけ生成し、それが他の目的で使用できないことを保証する必要があります。

The generation of private keys relies on random numbers. The use of inadequate pseudorandom number generators (PRNGs) to generate these values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities rather than brute-force searching the whole key space. The generation of quality random numbers is difficult, and [RFC4086] offers important guidance in this area.

秘密鍵の生成は、乱数に依存しています。これらの値を生成するために不適切な疑似乱数ジェネレータ（PRNG）を使用すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、キースペース全体を総当たりで検索するよりも、キーを生成したPRNG環境を再現し、結果として生じる可能性のある小さなセットを検索する方がはるかに簡単であることに気付く場合があります。高品質の乱数の生成は困難であり、[RFC4086]はこの領域で重要なガイダンスを提供します。

The generation of hash-based signatures also depends on random numbers. While the consequences of an inadequate PRNG to generate these values is much less severe than in the generation of private keys, the guidance in [RFC4086] remains important.

ハッシュベースの署名の生成も乱数に依存します。これらの値を生成するのに不十分なPRNGの結果は、秘密鍵の生成よりもはるかに深刻ではありませんが、[RFC4086]のガイダンスは依然として重要です。

5. Operational Considerations

5. 運用上の考慮事項

The public key for the hash-based signature is the key at the root of Hierarchical Signature System (HSS). In the absence of a public key infrastructure [RFC5280], this public key is a trust anchor, and the number of signatures that can be generated is bounded by the size of the overall HSS set of trees. When all of the LM-OTS signatures have been used to produce a signature, then the establishment of a new trust anchor is required.

ハッシュベースの署名の公開鍵は、階層署名システム（HSS）のルートにある鍵です。公開鍵インフラストラクチャ[RFC5280]がない場合、この公開鍵はトラストアンカーであり、生成できる署名の数は、ツリーのHSSセット全体のサイズによって制限されます。すべてのLM-OTS署名を使用して署名を作成した場合、新しいトラストアンカーの確立が必要です。

To ensure that none of the tree nodes are used to generate more than one signature, the signer maintains state across different invocations of the signing algorithm. Section 9.2 of [HASHSIG] offers some practical implementation approaches around this statefulness. In some of these approaches, nodes are sacrificed to ensure that none are used more than once. As a result, the total number of signatures that can be generated might be less than the overall HSS set of trees.

複数の署名を生成するためにどのツリーノードも使用されないようにするために、署名者は、署名アルゴリズムのさまざまな呼び出しにわたって状態を維持します。 [HASHSIG]のセクション9.2は、このステートフル性に関するいくつかの実用的な実装アプローチを提供しています。これらのアプローチの一部では、ノードが犠牲になるのは、1回しか使用されないようにするためです。その結果、生成できるシグネチャの総数は、ツリーのHSSセット全体よりも少なくなる可能性があります。

A COSE Key Type Parameter for encoding the HSS/LMS private key and the state about which tree nodes have been used is deliberately not defined. It was not defined to avoid creating the ability to save the private key and state, generate one or more signatures, and then restore the private key and state. Such a restoration operation provides disastrous opportunities for tree node reuse.

HSS / LMS秘密鍵をエンコードするためのCOSE鍵タイプパラメータと、ツリーノードが使用されている状態については、意図的に定義されていません。秘密鍵と状態を保存し、1つ以上の署名を生成してから、秘密鍵と状態を復元する機能の作成を回避することは定義されていません。このような復元操作は、ツリーノードの再利用に悲惨な機会をもたらします。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has added entries for the HSS/LMS hash-based signature algorithm in the "COSE Algorithms" registry and added HSS/LMS hash-based signature public keys in the "COSE Key Types" registry and the "COSE Key Type Parameters" registry.

IANAは、「COSEアルゴリズム」レジストリにHSS / LMSハッシュベースの署名アルゴリズムのエントリを追加し、「COSEキータイプ」レジストリと「COSEキータイプパラメータ」レジストリにHSS / LMSハッシュベースの署名公開鍵を追加しました。

6.1. COSE Algorithms Registry Entry

6.1. COSEアルゴリズムのレジストリエントリ

The new entry in the "COSE Algorithms" registry [IANA] appears as follows:

「COSE Algorithms」レジストリ[IANA]の新しいエントリは、次のように表示されます。

   Name:  HSS-LMS
   Value:  -46
   Description:  HSS/LMS hash-based digital signature
   Reference:  RFC 8778
   Recommended:  Yes

6.2. COSE Key Types Registry Entry

6.2. COSEキータイプレジストリエントリ

The new entry in the "COSE Key Types" registry [IANA] appears as follows:

「COSEキータイプ」レジストリ[IANA]の新しいエントリは、次のように表示されます。

Name: HSS-LMS Value: 5 Description: Public key for HSS/LMS hash-based digital signature Reference: RFC 8778

名前：HSS-LMS値：5説明：HSS / LMSハッシュベースのデジタル署名の公開キー参照：RFC 8778

6.3. COSE Key Type Parameters Registry Entry

6.3. COSEキータイプパラメータレジストリエントリ

The new entry in the "COSE Key Type Parameters" registry [IANA] appears as follows:

「COSEキータイプパラメータ」レジストリ[IANA]の新しいエントリは、次のように表示されます。

   Key Type:  5
   Name:  pub
   Label:  -1
   CBOR Type:  bstr
   Description:  Public key for HSS/LMS hash-based digital signature
   Reference:  RFC 8778

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, April 2019, <https://www.rfc-editor.org/info/rfc8554>.

[HASHSIG] McGrew、D.、Curcio、M。、およびS. Fluhrer、「Leighton-Micaliハッシュベースの署名」、RFC 8554、DOI 10.17487 / RFC8554、2019年4月、<https：//www.rfc-editor。 org / info / rfc8554>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.

[RFC8152] Schaad、J。、「CBOR Object Signing and Encryption（COSE）」、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS Publication 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.

[SHS]米国国立標準技術研究所（NIST）、「Secure Hash Standard」、FIPS Publication 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https://doi.org/10.6028/ NIST.FIPS.180-4>。

7.2. Informative References

7.2. 参考引用

[BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The Factoring Dead: Preparing for the Cryptopocalypse", August 2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf>.

[BH2013] Ptacek、T.、Ritter、T.、Samuel、J。、およびA. Stamos、「The Factoring Dead：Preparing for the Cryptopocalypse」、2013年8月、<https://media.blackhat.com/us- 13 / us-13-Stamos-The-Factoring-Dead.pdf>。

[DSS] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://doi.org/10.6028/NIST.FIPS.186-4>.

[DSS]国立標準技術研究所（NIST）、「デジタル署名標準（DSS）」、FIPS Publication 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https://doi.org /10.6028/NIST.FIPS.186-4>。

[IANA] IANA, "CBOR Object Signing and Encryption (COSE)", <https://www.iana.org/assignments/cose>.

[IANA] IANA、「CBORオブジェクトの署名と暗号化（COSE）」、<https://www.iana.org/assignments/cose>。

[LM] Leighton, F. and S. Micali, "Large provably fast and secure digital signature schemes from secure hash functions", U.S. Patent 5,432,852, July 1995.

[LM] Leighton、F。およびS. Micali、「安全なハッシュ関数からの証明可能な高速で安全なデジタル署名方式」、米国特許第5 432 852号、1995年7月。

[M1979] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Information Systems Laboratory, Stanford University, Technical Report No. 1979-1, June 1979.

[M1979]マークルR.、「秘密、認証、公開鍵システム」、スタンフォード大学情報システム研究所、テクニカルレポートNo. 1979-1、1979年6月。

[M1987] Merkle, R., "A Digital Signature Based on a Conventional Encryption Function", Advances in Cryptology -- CRYPTO '87 Proceedings, Lecture Notes in Computer Science, Volume 291, DOI 10.1007/3-540-48184-2_32, 1988, <https://doi.org/10.1007/3-540-48184-2_32>.

[M1987]マークルR.、「従来の暗号化機能に基づくデジタル署名」、暗号学の進歩-CRYPTO '87 Proceedings、Lecture Notes in Computer Science、Volume 291、DOI 10.1007 / 3-540-48184-2_32、 1988年、<https://doi.org/10.1007/3-540-48184-2_32>。

[M1989a] Merkle, R., "A Certified Digital Signature", Advances in Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in Computer Science, Volume 435, DOI 10.1007/0-387-34805-0_21, 1990, <https://doi.org/10.1007/0-387-34805-0_21>.

[M1989a] Merkle、R。、「A Certified Digital Signature」、Advance in Cryptology-CRYPTO '89 Proceedings、Lecture Notes in Computer Science、Volume 435、DOI 10.1007 / 0-387-34805-0_21、1990、<https： //doi.org/10.1007/0-387-34805-0_21>。

[M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in Computer Science, Volume 435, DOI 10.1007/0-387-34805-0_40, 1990, <https://doi.org/10.1007/0-387-34805-0_40>.

[M1989b]マークル、R。、「一方向ハッシュ関数とDES」、暗号学の進歩-CRYPTO '89 Proceedings、Lecture Notes in Computer Science、Volume 435、DOI 10.1007 / 0-387-34805-0_40、1990、< https://doi.org/10.1007/0-387-34805-0_40>。

[NAS2019] National Academies of Sciences, Engineering, and Medicine, "Quantum Computing: Progress and Prospects", The National Academies Press, DOI 10.17226/25196, 2019, <http://dx.doi.org/10.17226/25196>.

[NAS2019] National Academy of Sciences、Engineering、and Medicine、「Quantum Computing：Progress and Prospects」、The National Academies Press、DOI 10.17226 / 25196、2019、<http://dx.doi.org/10.17226/25196>。

[PQC] Bernstein, D., "Introduction to post-quantum cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009, <http://www.pqcrypto.org/www.springer.com/cda/content/ document/cda_downloaddocument/9783540887010-c1.pdf>.

[PQC] Bernstein、D。、「Introduction to post-quantum cryptography」、DOI 10.1007 / 978-3-540-88702-7_1、2009、<http://www.pqcrypto.org/www.springer.com/cda / content / document / cda_downloaddocument / 9783540887010-c1.pdf>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現するための表記法」、RFC 8610、DOI 10.17487 / RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。

Appendix A. Examples

付録A.例

This appendix provides a non-normative example of a COSE full message signature and an example of a COSE_Sign1 message. This section is formatted according to the extended CBOR diagnostic format defined by [RFC8610].

この付録では、COSE完全メッセージ署名の非規範的な例とCOSE_Sign1メッセージの例を示します。このセクションは、[RFC8610]で定義されている拡張CBOR診断フォーマットに従ってフォーマットされています。

The programs that were used to generate the examples can be found at <https://github.com/cose-wg/Examples>.

サンプルの生成に使用されたプログラムは、<https://github.com/cose-wg/Examples>にあります。

A.1. Example COSE Full Message Signature

A.1. COSE完全メッセージ署名の例

This section provides an example of a COSE full message signature.

このセクションでは、COSE完全メッセージ署名の例を示します。

The size of binary file is 2560 bytes.

バイナリファイルのサイズは2560バイトです。

   98(
     [
       / protected / h'a10300' / {
           \ content type \ 3:0
         } / ,
       / unprotected / {},
       / payload / 'This is the content.',
       / signatures / [
         [
           / protected / h'a101382d' / {
               \ alg \ 1:-46 \ HSS-LMS \
             } / ,
           / unprotected / {
             / kid / 4:'ItsBig'
           },
           / signature / h'00000000000000010000000391291de76ce6e24d1e2a
   9b60266519bc8ce889f814deb0fc00edd3129de3ab9b6bfa3bf47d007d844af7db74
   9ea97215e82f456cbdd473812c6a042ae39539898752c89b60a276ec8a9feab900e2
   5bdfe0ab8e773aa1c36ae214d67c65bb68630450a5db2c7c6403b77f6a9bf4d30a02
   19db5cced884d7514f3cbd19220020bf3045b0e5c6955b32864f16f97da02f0cbfea
   70458b07032e30b0342d75b8f3dc6871442e6384b10f559f5dc594a214924c48ccc3
   37078665653fc740340428138b0fb5154f2f2cb291ad05ace7acae60031b2d09b2f4
   17712d1c01e34b165af2e070f5a521a85a5fb3dd2a6288947bcbd5e2265d3670bd61
   92eb2bf643964e2783d84aec343f8e3571e4fcf09cbeea94e80470aa7252d1c733a5
   535907e66c7b9f0b88b159dc2a7370ee47f13e7e134d3d05e5f53fac640b784a9b0f
   183fe14217325626f487cc8d8cb9eaf0abb174ee0b7076cf39c45037cefdf3f1e61b
   5174581214c09870b72c39737ec4c46a96199b66cad2990bcbe5bb1abfde99107c7f
   7289395bf2a433598ede0b1969f23db949afb5b4d33831dae6c641a6355f8f9bf16c
   dffc4bf86891b93a557c2152ac8a1de51c995344cc10cc4bc9ecfbb4e418bed0f334
   af165339e6725dc4fc1e995521e1be8a566d59b57cd130903b42d07087d63646ef8f
   c1e9e9071bb67a123fdec3f37638cdaf0f4bf3084074069171c17885b9431ad908d3
   6a6f8a826256d2aa34f8aa0731a357c060db8e80fefd61b1c323890e640633b98d17
   5d4d6ebff800a71cfc864ec02837de9d0e079f0f400acafd56805cb273e631ba395d
   23e86acf6eae63181a5afe1f0a361cbbd5fefeb7db0c95591ec3128e80dfbea9ca0f
   89fc035d761c05d41e7a010892c42e8e2af62aa604f4e214c0bb08075481f9cc307a
   555adf333b9424f209b89f161032e413b047ae5ab0aa15643bb4c643446d2c9829eb
   256e7375ce9639047a24a44f4da446b7359556f3ab3484c56511c68a140dc0531f65
   3105800d9f20990d4ebdc5ceea918d7ae95c0d7ec69a00d6a936b25fc19b9dfc5561
   400f046191136c367038d6a9d0e0ae30dcdc4733712cbd5a2aee35315eff5c1a7e08
   5b68c5cf0c64c495df2ca6f030db04480a2e11d4a0a0dbf29d9463d5b9e41e346e49
   c894d5e43993c834c4746309c886d6131f2f92155ca1160bac9660802a947b5aba94
   b35357d13fdf02d2aeabef568912f68ae5d3a60214f6d00c4dd9f0af09eb0bf961cd
   9f27251d46899c28d87080ba2ead3e8193f51a789706ec32aacee9f4b14eeca91a25
   2fe894b30dc3938abbbe7d217948cae79ce3adb4d7d7df6756f3099f2543ed3b522b
   acab257503c9e07fcd32cc32fa9aa17977ec05bc5fe0f5954d51f160f52d33f93166
   af68aa90261b3f5ad273adacf2d0cb5b0c5402bfa62da67a52dcddfa463e72d2c005
   f1ac0ea3cb62364ee3419333612e07bf685006137a592e2fcd58398265c4ff9e11e7
   0c2b79152e4604b4f94676e955bcff4dfc429a8a88728b95bfc2826e25ba6eab9cfb
   066c9911693efff242f7b51c3cb88546143b8ab2142dd3c9bda55d16fe3084a86b74
   3f294dd9d0aa84f3ce3b083a5879a4762a756e9b41f4bdf8b71418073b0a0d4a9c13
   1882455ece23e50324c5feea217920b0f3109dcbdc81762e41b7ca271efac8e39cc2
   6ebe085abdbf6b314a38929799fb7feebee2e20b97056ed17ef3881e6e89330314dd
   7e9c629c46dfdb925c7c5f5d243f159d964691745cd46579fd0696479e1c49cbd2af
   879a2bce8576619cca7b6e516e6c94c1087441a81f11b9a83535b24ddc725a81a9d1
   ff62da2804c8d84c6e382065574282ea1f23eaf648cfa9767afb098fd81654d76133
   f5f39bcc762c9bc31f7f4665cc0efa929b5c05dedd76143c63dc7018ab130c108ea9
   01be32b9d911b66da13a1528c32a9694c899a772f8e1fe00c17eceb343e737d72cba
   06cf5ddac9a4d3df7ef391cf6595a6d8c14b0d80f93023b1b3d4371239da98b67a1b
   6a379422616282a16e8d1f97a130baf21e572bcca91abb760eac6957f9b1b05e49e2
   d181874ac6dd160d1c717b73bd28ef55f08d47466d5aef754814c7e206fa9e2ec533
   85d14d52f7769d95ea50524ffb20dc7275b04d71d1967e3bbc6ed481f1fc5a15e78a
   1fd967d96045625645dbd173cccdd97661e995ce47d6b3ead96ee6d006a5ce6f4c97
   77fe2e3f91bebe877cac8c6486dfce0315dc71bbb93879759b8981c5ff2e11deb809
   abf4280ee93d1711e73645b410acb518538ce3d4bda1e355c988f068165668e99d6a
   8de356b4b13298036ad05d526c4a5e2591612a477b7e86550adde128cd71ee651d44
   99699000a02979e42bbccf32c83b1eb0ff99aa4d352e20e0b3382422df2c2ed4ce90
   c94cf1a359e92ef971dc6db06047a333c2ebe827eb6d5f2811fdbe0bf0f12bf2094e
   0dcd8e418f3f691a60ceb0cefb6f45f47883d6b9f320950e91266740c6dbfad6b3cf
   e56de0aa6658b0dc893bb6e49e6294537a7878e86cfc8e6c150675db1a89d188ea6e
   fe7d88ff57b39b8610e392811ee097ca61c4841e0fbd346ed3ff6a5e412acb0d9f13
   022df2e7fdaa8e0face7366c8ffe6f446995b564fc3d59c70fecdb60a25e28650417
   157f43f3e72c3afc601509641cfd099a78130e1f7ba8333502ad4f036f46411a43d0
   35e2ca0ed0c346d9aac5df05196c95c38e6e52763ed896b6d02464a910dda6cca340
   24e3b9c3723d26e2886ad724dd56ea285e8e4b60beec924d55dd700c38877b74552f
   ea1f8741579b02061416131db390f628522885236b51f7aef23167d3a5fe5eadcd88
   b0e99b2b6bc56b0dea4fb22146294766c28e5e7c834dbdcb6bfdd7bd8455252522ff
   2e974f6fd3fda176749b7cdced5b9aba092b2982c89cb7d2b36348928c8f01170618
   ecff14d9e0eed9d88d97e38bcf7a837f674be5243fc624c8afd3d105f462bfa939b8
   143a3a98f78fbb8c915e00bdbbf707b12c45784f4d1cb1426b583a0d5fbec1f5ea6d
   0067c090168cb788e532aca770c7be366ec07e7808f1892b00000006ed1ce8c6e437
   918d43fba7bd9385694c41182703f6b7f704deedd9384ba6f8bc362c948646b3c984
   8803e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e
   7c81a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc5
   6211d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d26
   246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba
   e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c
   29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10
   7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9
   ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b
   a7b3bd0d824a4570'
         ]
       ]
     ]
   )

A.2. Example COSE_Sign1 Message

A.2. COSE_Sign1メッセージの例

This section provides an example of a COSE_Sign1 message.

このセクションでは、COSE_Sign1メッセージの例を示します。

The size of binary file is 2552 bytes.

バイナリファイルのサイズは2552バイトです。

   18(
     [
       / protected / h'a101382d' / {
           \ alg \ 1:-46 \ HSS-LMS \
         } / ,
       / unprotected / {
         / kid / 4:'ItsBig'
       },
       / payload / 'This is the content.',
       / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60
   266519bc8ce889f814deb0fc00edd3129de3ab9b9aa5b5ac783bdf0fe689f57fb204
   f1992dbc1ce2484f316c74bce3f2094cfa8e96a4a9548cead0f78ee5d549510d1910
   f647320448ae27ecce77249802a0c39c645bf8db08573af52c93d91fd0e217f245c7
   52c176b81514eb6e3067e0fbb329225eaa88c7d21635e32ae84213f89018cb06f1b8
   4e61eac348b690d7c6265c19f9d868952d99826aecd417b5279dd674cd951c306016
   cfee4fee3bfcf5ee5a5ad08b5b4f53bc93995f26cfe7c0c1c5ba2574c1f2d8470993
   e8bd47ef9b9cf309ef895226e92be60683459009611defbb9a43217956a0ab2959bb
   da0feca39de37e7c4a6cd8a5314d6b02b377406d5a5e589e91feaa9f2e4ec1682ba1
   f633c7784499323e40da651f71d3c19e38c634d898b0c508324c0bfcf7c5f0a8c014
   b4af200a739f96cddba94daf86ce80c76158d4f5cf3cd2ba9f1393df47e556887f91
   68540485242a05ec6bcc76659ec3d0d2fedae3fd1608a701c226f5fd83c9b1ed3152
   ddac7426c30e3390bec8f1da6174abe8d3568c9b76b149eb077d61ac15b8fb11b8ce
   5f9d14e448e216f375e1f96a52d39619459b131026143e8809bad408f5ef66cd3da2
   27431e68670c0b4b2c3801e1e9025b1ebed218e0956967158ccc274c704adcd8cc23
   c149a89eda25478742dadc15f233844535e4021000b5d557313d4f271875680e6d5e
   7f6681fdd19f8b9a748cabb2377aac1387fdb80e618eb7d69a368729ca9a092af91e
   be1c584c35fe62734d1d53d10b35dd02093a201c889ad37a558b610f1ab00179a11f
   881600e944cedc47a7ae6d828009d7c61ffea9dd5aa5406408e2e85dc056e47b5758
   9eaba18e792f4631af62d4588a1818167274273c69e7a0735be5dada7e224e3b178b
   3b093212eb74e762f564a26d577aa22ebd8c7b4a999419908e2f2d9c8689dc923905
   c198b9ee335d1e0de6d689655f446dffea997b6e58f5f648415233ede3b9d8a2db29
   e8c3dde5d8dbd55e6348cd9f421783db090e087de46425d62d513597b00d7de32fad
   87752a79cee8b2a38b1e0f2562836721cbbfba20f131130c009a436b93a0bb44fcbb
   86228b1bf1a35f4fc626817924eaebd5b78d64a7970d18dade90cf0ad759b1c45d95
   3c08cd1189685077c5a56069da0944669d797496f8f886fea6f792598db2ac66b657
   af838ed3c3a914dffbb164170a1f63250b125eda53ecaeaf6ee0d2b8a3c804104d7e
   d575b66469bc59f37eec6c6f6fb19e0f7ea02d7c85306230063adb58950589f6ffaf
   f1407233828ae0dfbe5889e5de00bb640a4bc24c3f704488fa669676a9ebbbed399b
   8a9ac0ee4cc944f864b21f642e04f610319ac9271f8bd820e77e41dac6553d234d94
   80e26142c0fa37416651d6450e1f2082bd0213d6783e1ae3cc5c5af677c3316e173b
   a4716d6bc8a9d89383f8b025a0859b99a43daeaf8ddaed46d223b9b503651a67560b
   feb2f35ba544722620ec4086dcc77e6e87bb53f1f18c38368662be460ede31325cae
   aebf018a6fa9d32e3c3a6898e15fe114dcce51241c61afabc36de3608b4d342712a8
   33615c6131e89e1d46b713d9638a08b5a768d53af0298b9c874ded7084358223840c
   2e78cd6fbfca695279a4c1883bb7de81b04a069de8277f7f5109c16938347a643713
   c9ac36fffc8bf141e899f48bc25c7b636d43bebcfa7742d4e1462263e56732ad2021
   eef8ce84023c4959cfd250343d62074724907de9d49ea2f6c968fd9e9bf28feafcdc
   81702108805dec60f2781272d2425a6ee29c66122d2c557867c1a5aed82131e06fc3
   84ecf49017e1c9d6cf63b9f2285ccf890cbb9bbf796e0fd02101948b7ef663849367
   7b33fd787d9d3fc2c7cc7babc21af8c748afb80cf86b45dc89f0b9c7959621e85b98
   b542dc263db9255273bb9054a7f194748f28373ba123d73fc71fef43e7e2ac9a8000
   8e85cf2f04aa433075dfc54c4de24a341ebf7cf1e6b383dbba85898fdc368017fd67
   c153e7a991a3a3cee6dae4fbe2fe6f25a8df314140a8176c8e6fd0c6f042ca66eb6a
   bba9a2502bb6dfa52960ae86a942a673e4e45439594fefcd2974e20554d1dc70b8e0
   34fd1787801343d5f6edc95ce0348c25727c771526e3fd4effb5f16e25a1ea3dcd82
   82e778e91ae9b339a5013c77fd6ea2432704e293f5e82a24121c73900bea4b4ef14a
   2adc1ab3c68224bae1de9c61a48b84e84c1b0e83701be3d988012a24fa40268c8d6e
   f1fd2818ae8e4b6f52f89beab6bfdd1ff1b7ecd573edff3703b800b5b2a206f451f1
   bf2713b4ae9085bd7fe34ad4306a290e4cdb7817ee9ab7ccfb816d002b619f77d46d
   7dd0f8eefe10f5c0f9723ffdb14ca75a185543770f41508b9983d5eed78225bc6e21
   f876bfdd08fe8bc63e0cb253c7dfc67c330897c515244f3f631682f2141eba48ca86
   dfff9206f78edcb9dec4b2371aeddbe141ef96a10957e29a94747c4438fb30b14d37
   e7428eb7fbe4f9d870e72f35f55847f230374bdf56dcae6c129b4468ebaedc340ff4
   cc160c6b410e2d8989488ac8ef9a9febbf65ad4fdfba532a8122ef82dc1a4ffc361c
   bf9f752b36aa9821683d5f3f5842f90134eb423d5cbc76858b4c0a7ba798ec94a089
   fdb24b5b25f42d7b6bb8192f07b98eb2de1fe7bc8b6c740fa5cde6fb4890d2f17916
   64a96c25a0a71a541025b5ec825eed91f393505473e21d0620177993982e6c1b6bf9
   1b777b5ab5739b84946c518c7e6aa0e689e9ad1d34e6ef6ca0e709c4aefecd6f2594
   b017940742aceb72c5a52d7d47a3a74f9d09eb84cf82b349de32278a771cebc31ebc
   580c09b11799b1f0e6d11d75b17e389d259c531f957a1e699250711df2e36f64f21c
   92eff698a392d92df0b2f91991408a076b83149e025a9ffba1ff1caed916a2fc1ac5
   d3081c30b5c64b7d677c314b6e76ac20ed8bb4a4c0eb465ae5c0c265969264b27e6d
   54c266f79e58e2fa6a381069090bec00189562abcf831adc86a05a2fc7ffaa70dbd3
   fa60e09d447cd76b2ff2b851c38e72650ade093ba8bd000000067b95de445abf8916
   1dff4b91a4a9e3bf156a39a4660f98f06bf3f017686d9dfc362c948646b3c9848803
   e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e7c81
   a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211
   d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465
   95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716
   96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4
   f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362
   f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94
   9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3
   bd0d824a4570'
     ]
   )

Acknowledgements

謝辞

Many thanks to Roman Danyliw, Elwyn Davies, Scott Fluhrer, Ben Kaduk, Laurence Lundblade, John Mattsson, Jim Schaad, and Tony Putman for their valuable review and insights. In addition, an extra special thank you to Jim Schaad for generating the examples in Appendix A.

Roman Danyliw、Elwyn Davies、Scott Fluhrer、Ben Kaduk、Laurence Lundblade、John Mattsson、Jim Schaad、Tony Putmanの貴重なレビューと洞察に感謝します。さらに、付録Aの例を生成してくれたJim Schaadに特別に感謝します。

Author's Address

著者のアドレス

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America

Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com