[要約] RFC 8708は、CMSでHSS/LMSハッシュベースの署名アルゴリズムを使用するための仕様です。目的は、CMSにおいてセキュアな署名を提供するために、HSS/LMSアルゴリズムを利用することです。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8708 Vigil Security
Category: Standards Track February 2020
ISSN: 2070-1721
Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
暗号化メッセージ構文（CMS）でのHSS / LMSハッシュベースの署名アルゴリズムの使用
Abstract
概要
This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.
このドキュメントでは、暗号化メッセージ構文（CMS）で階層型署名システム（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/rfc8708.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8708で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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. ASN.1
1.2. Terminology
1.3. Motivation
2. HSS/LMS Hash-Based 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. Algorithm Identifiers and Parameters
4. HSS/LMS Public Key Identifier
5. Signed-Data Conventions
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. ASN.1 Module
Acknowledgements
Author's Address
This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS) [CMS] signed-data content type. 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 numbers of signatures. The HSS/LMS algorithm is one form of 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 with a given private key, and 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 exclusively use SHA-256 [SHS].
このドキュメントでは、暗号化メッセージ構文（CMS）[CMS]署名付きデータコンテンツタイプで階層型署名システム（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]のみを使用するように定義されています。
CMS values are generated using ASN.1 [ASN1-B], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [ASN1-E].
CMS値は、ASN.1 [ASN1-B]を使用して、基本エンコーディングルール（BER）およびDistinguished Encodingルール（DER）[ASN1-E]を使用して生成されます。
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]で説明されているように解釈されます。
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 when cryptosystems such as RSA and DSA that depend on discrete logarithms and factoring cannot be depended upon.
暗号解読の最近の進歩[BH2013]および量子コンピューターの開発の進歩[NAS2019]は、広く展開されているデジタル署名アルゴリズムに脅威をもたらします。その結果、離散対数や因数分解に依存するRSAやDSAなどの暗号化システムに依存できない日の準備をする必要があります。
If large-scale quantum computers are ever built, these computers 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 quantum computers that have more than a trivial number of quantum bits (qubits). It is open to conjecture when it will be feasible to build such computers; however, RSA, DSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (EdDSA) are all vulnerable if large-scale quantum computers are ever developed.
大規模な量子コンピューターが構築されると、これらのコンピューターは現在使用されている公開鍵暗号システムの多くを破ることができます。ポスト量子暗号化システム[PQC]は、量子ビット（量子ビット）の数がわずかでもない量子コンピューターに対して安全なシステムです。そのようなコンピュータを構築することがいつ実現可能になるかについては、それは推測の余地があります。ただし、RSA、DSA、楕円曲線デジタル署名アルゴリズム（ECDSA）、およびエドワーズ曲線デジタル署名アルゴリズム（EdDSA）は、大規模な量子コンピューターが開発された場合、すべて脆弱です。
Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithms or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. One use of post-quantum-secure signatures is the protection of software updates, perhaps using the format described in [FWPROT], to enable deployment of software that implements new cryptosystems.
HSS / LMS署名アルゴリズムは離散対数や因数分解の難易度に依存しないため、HSS / LMS署名アルゴリズムはポスト量子安全であると見なされます。量子安全な署名の1つの用途は、おそらく[FWPROT]で説明されている形式を使用してソフトウェア更新を保護し、新しい暗号システムを実装するソフトウェアの導入を可能にすることです。
Merkle Tree Signatures (MTS) are a method for signing a large but fixed number of messages. An MTS system depends on a one-time signature method and a collision-resistant hash function.
マークルツリー署名（MTS）は、大量ではあるが一定数のメッセージに署名するための方法です。 MTSシステムは、ワンタイム署名方式と耐衝突性ハッシュ関数に依存しています。
This specification makes use of the hash-based 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]。
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] uses only the SHA-256 one-way hash function [SHS], but it establishes an IANA registry [IANA-LMS] to permit the registration of additional one-way hash functions in the future.
名前からわかるように、ハッシュベースの署名アルゴリズムは、衝突に強いハッシュ関数に依存しています。 [HASHSIG]で指定されたハッシュベースの署名アルゴリズムは、SHA-256一方向ハッシュ関数[SHS]のみを使用しますが、IANAレジストリ[IANA-LMS]を確立して、追加の一方向ハッシュ関数を未来。
The MTS system 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]で指定されたMTSシステムは、ツリーの階層を使用します。 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.
[HASHSIG]で指定されているHSS署名は、署名された公開鍵の数（Nspk）を運び、その数の署名された公開鍵が続き、セクション2.2で説明されているようにLMS署名が続きます。最上位のLMSツリーの公開鍵は、HSSシステムの公開鍵です。親ツリーのLMS秘密鍵は子ツリーのLMS公開鍵に署名し、一番下のツリーのLMS秘密鍵は実際のメッセージに署名します。公開鍵の署名と実際のメッセージの署名は、セクション2.2で説明されているLMS署名です。
The elements of the HSS signature value for a standalone tree (a top tree with no children) can be summarized as:
スタンドアロンツリー（子のないトップツリー）のHSS署名値の要素は、次のように要約できます。
u32str(0) ||
lms_signature /* signature of message */
where, u32str() and || are used as defined in [HASHSIG].
ここで、u32str()および|| [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 */
where, as defined in Section 3.3 of [HASHSIG], the signed_public_key structure contains 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を引いたものであることに注意してください。
Each tree in the system 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] specification supports five values for 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, m, is the number of bytes output by the hash function, and it is the amount of data associated with each node in the tree. The [HASHSIG] specification supports only the SHA-256 hash function [SHS], with m=32. As a result, the [HASHSIG] specification supports five tree sizes; they are identified as:
[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ハッシュ関数[SHS]のみをサポートします。その結果、[HASHSIG]仕様は5つのツリーサイズをサポートします。それらは次のように識別されます。
* LMS_SHA256_M32_H5
* LMS_SHA256_M32_H5
* LMS_SHA256_M32_H10
* LMS_SHA256_M32_H10
* LMS_SHA256_M32_H15
* LMS_SHA256_M32_H15
* LMS_SHA256_M32_H20
* LMS_SHA256_M32_H20
* LMS_SHA256_M32_H25
* LMS_SHA256_M32_H25
The [HASHSIG] specification establishes an IANA registry [IANA-LMS] to permit the registration of additional hash functions and additional tree sizes in the future.
[HASHSIG]仕様は、IANAレジストリ[IANA-LMS]を確立して、将来追加のハッシュ関数と追加のツリーサイズを登録できるようにします。
As specified in [HASHSIG], the LMS public key consists of four elements: the lms_algorithm_type from the list above, the otstype to identify the Leighton-Micali One-Time Signature (LM-OTS) type as discussed in Section 2.3, the private key identifier (I) as described in Section 5.3 of [HASHSIG], and the m-byte string associated with the root node of the tree (T[1]).
[HASHSIG]で指定されているように、LMS公開鍵は4つの要素で構成されています。上記のリストのlms_algorithm_type、2.3節で説明したLeighton-Micaliワンタイム署名（LM-OTS）タイプを識別するotstype、秘密鍵[HASHSIG]のセクション5.3で説明されている識別子（I）、およびツリーのルートノードに関連付けられているmバイトの文字列（T [1]）。
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], an LMS signature consists of four elements: the number of the leaf (q) associated with the LM-OTS signature value, an LM-OTS signature value as described in Section 2.3, a typecode indicating the particular LMS algorithm, and an array of values that is associated with the path through the tree from the leaf associated with the LM-OTS signature value to the root. 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.
[HASHSIG]で指定されているように、LMS署名は4つの要素で構成されています。LM-OTS署名値に関連付けられたリーフ（q）の数、セクション2.3で説明されているLM-OTS署名値、特定のLMSを示すタイプコードアルゴリズム、およびLM-OTS署名値に関連付けられたリーフからルートへのツリーを通るパスに関連付けられた値の配列。値の配列には、リーフからルートへのパス上のノードの兄弟が含まれていますが、パス自体のノードは含まれていません。高さ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]
Merkle Tree Signatures (MTS) depend on a one-time signature method, and [HASHSIG] specifies the use of the LM-OTS, which has five parameters:
マークルツリー署名（MTS）は1回限りの署名方法に依存しており、[HASHSIG]はLM-OTSの使用を指定します。これには5つのパラメーターがあります。
n: The length in bytes of the hash function output. [HASHSIG] supports only SHA-256 [SHS], with n=32.
n：ハッシュ関数出力のバイト単位の長さ。 [HASHSIG]は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 value.
p：LM-OTS署名値を構成するnバイトの文字列要素の数。
ls: The number of bits that are left-shifted in the final step of 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_W1
* LMOTS_SHA256_N32_W2
* LMOTS_SHA256_N32_W2
* LMOTS_SHA256_N32_W4
* LMOTS_SHA256_N32_W4
* LMOTS_SHA256_N32_W8
* LMOTS_SHA256_N32_W8
The [HASHSIG] specification establishes an IANA registry [IANA-LMS] to permit the registration of additional variants in the future.
[HASHSIG]仕様は、IANAレジストリ[IANA-LMS]を確立して、将来追加のバリアントを登録できるようにします。
Signing involves the generation of C, 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]) that correspond to the elements of the public key, as described in Section 4.5 of [HASHSIG]:
LM-OTSシグネチャ値は、LM-OTSバリアントの識別子、ランダム値、およびパブリックの要素に対応するハッシュ値のシーケンス（y [0]からy [p-1]）として要約できます。 [HASHSIG]のセクション4.5で説明されているキー：
u32str(otstype) || C || y[0] || ... || y[p-1]
u32str（otstype）|| C ||と[0] || ... ||と[p-1]
The algorithm identifier for an HSS/LMS hash-based signature is:
HSS / LMSハッシュベースの署名のアルゴリズム識別子は次のとおりです。
id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 17 }
When this object identifier is used for an HSS/LMS signature, the AlgorithmIdentifier parameters field MUST be absent (that is, the parameters are not present, and the parameters are not set to NULL).
このオブジェクト識別子がHSS / LMS署名に使用される場合、AlgorithmIdentifierパラメーターフィールドは存在しない必要があります（つまり、パラメーターが存在せず、パラメーターがNULLに設定されていません）。
The signature value is a large OCTET STRING, as described in Section 2 of this document. The signature format is designed for easy parsing. The HSS, LMS, and LM-OTS components of the signature value each include a counter and a typecode that indirectly provide all of the information that is needed to parse the value during signature validation.
このドキュメントのセクション2で説明されているように、署名値は大きなOCTET STRINGです。署名形式は、簡単に解析できるように設計されています。署名値のHSS、LMS、およびLM-OTSコンポーネントにはそれぞれ、署名検証中に値を解析するために必要なすべての情報を間接的に提供するカウンターとタイプコードが含まれています。
The signature value identifies the hash function used in the HSS/LMS tree. [HASHSIG] uses only the SHA-256 hash function [SHS], but it establishes an IANA registry [IANA-LMS] to permit the registration of additional hash functions in the future.
シグニチャー値は、HSS / LMSツリーで使用されるハッシュ関数を識別します。 [HASHSIG]はSHA-256ハッシュ関数[SHS]のみを使用しますが、IANAレジストリ[IANA-LMS]を確立して、将来追加のハッシュ関数を登録できるようにします。
The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-hss-lms-hashsig object identifier, and the parameters field MUST be absent.
HSS / LMS公開鍵のAlgorithmIdentifierは、id-alg-hss-lms-hashsigオブジェクト識別子を使用し、parametersフィールドは存在しない必要があります。
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of an X.509 certificate [RFC5280], the certificate key usage extension MAY contain digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however, it MUST NOT contain other values.
このAlgorithmIdentifierがX.509証明書の[SubjectPublicKeyInfo]フィールドに表示される場合[RFC5280]、証明書のキー使用拡張には、digitalSignature、nonRepudiation、keyCertSign、およびcRLSignが含まれる場合があります。ただし、他の値を含めることはできません。
pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-hss-lms-hashsig
KEY HSS-LMS-HashSig-PublicKey
PARAMS ARE absent
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSS-LMS-HashSig-PublicKey ::= OCTET STRING
Note that the id-alg-hss-lms-hashsig algorithm identifier is also referred to as id-alg-mts-hashsig. This synonym is based on the terminology used in an early draft version of the document that became [HASHSIG].
id-alg-hss-lms-hashsigアルゴリズム識別子は、id-alg-mts-hashsigとも呼ばれます。この同義語は、[HASHSIG]になったドキュメントの初期ドラフトバージョンで使用されていた用語に基づいています。
The public key value is an OCTET STRING. Like the signature format, it is designed for easy parsing. The value is the number of levels in the public key, L, followed by the LMS public key.
公開鍵の値はOCTET STRINGです。署名形式と同様に、簡単に解析できるように設計されています。値は、公開鍵Lのレベル数であり、その後にLMS公開鍵が続きます。
The HSS/LMS public key value can be described as:
HSS / LMS公開鍵の値は、次のように説明できます。
u32str(L) || lms_public_key
u32str（L）|| lms_public_key
Note that the public key for the topmost LMS tree is the public key of the HSS system. When L=1, the HSS system is a single tree.
最上位のLMSツリーの公開鍵はHSSシステムの公開鍵であることに注意してください。 L = 1の場合、HSSシステムは単一ツリーです。
As specified in [CMS], the digital signature is produced from the message digest and the signer's private key. The signature is computed over different values depending on whether signed attributes are absent or present.
[CMS]で指定されているように、デジタル署名はメッセージダイジェストと署名者の秘密鍵から生成されます。署名は、署名された属性が存在するかどうかに応じて、さまざまな値に対して計算されます。
When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, then a message-digest attribute is constructed with the hash of the content, and then the HSS/LMS signature is computed over the DER-encoded set of signed attributes (which MUST include a content-type attribute and a message-digest attribute). In summary:
署名された属性がない場合、HSS / LMS署名はコンテンツに対して計算されます。署名された属性が存在する場合、HSS / LMSツリーで使用されるのと同じハッシュ関数を使用してコンテンツに対してハッシュが計算され、次にメッセージダイジェスト属性がコンテンツのハッシュで構築され、次にHSS / LMS署名が作成されます。 DERでエンコードされた一連の署名済み属性（コンテンツタイプ属性とメッセージダイジェスト属性を含める必要があります）に対して計算されます。要約すれば：
IF (signed attributes are absent)
THEN HSS_LMS_Sign(content)
ELSE message-digest attribute = Hash(content);
HSS_LMS_Sign(DER(SignedAttributes))
When using [HASHSIG], the fields in the SignerInfo are used as follows:
[HASHSIG]を使用する場合、SignerInfoのフィールドは次のように使用されます。
* digestAlgorithm MUST contain the one-way hash function used in the HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported hash function, but other hash functions might be registered in the future. For convenience, the AlgorithmIdentifier for SHA-256 from [PKIXASN1] is repeated here:
* digestAlgorithmには、HSS / LMSツリーで使用される一方向ハッシュ関数が含まれている必要があります。 [HASHSIG]では、サポートされているハッシュ関数はSHA-256のみですが、将来的には他のハッシュ関数が登録される可能性があります。便宜上、[PKIXASN1]のSHA-256のAlgorithmIdentifierをここで繰り返します。
mda-sha256 DIGEST-ALGORITHM ::= {
IDENTIFIER id-sha256
PARAMS TYPE NULL ARE preferredAbsent }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithms(4) hashalgs(2) 1 }
* signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the algorithm parameters field MUST be absent.
* signatureAlgorithmにはid-alg-hss-lms-hashsigが含まれている必要があり、アルゴリズムパラメータフィールドは存在しない必要があります。
* signature contains the single HSS signature value resulting from the signing operation as specified in [HASHSIG].
* signatureには、[HASHSIG]で指定された署名操作から得られた単一のHSS署名値が含まれます。
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 non-volatile 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 pseudorandom number generator (PRNG) to generate these values is much less severe than in the generation of private keys, the guidance in [RFC4086] remains important.
ハッシュベースの署名の生成も乱数に依存します。これらの値を生成するための不適切な疑似乱数ジェネレーター（PRNG）の結果は、秘密鍵の生成よりもはるかに深刻ではありませんが、[RFC4086]のガイダンスは引き続き重要です。
When computing signatures, the same hash function SHOULD be used to compute the message digest of the content and the signed attributes, if they are present.
署名を計算するとき、同じハッシュ関数を使用して、コンテンツのメッセージダイジェストと署名された属性がある場合はそれらを計算する必要があります（SHOULD）。
In the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry, IANA has updated the reference for value 64 to point to this document.
「SMI Security for S / MIME Module Identifier（1.2.840.113549.1.9.16.0）」レジストリで、IANAは値64の参照を更新してこのドキュメントを指すようにしました。
In the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry, IANA has updated the description for value 17 to "id-alg-hss-lms-hashsig" and updated the reference to point to this document.
「SMI Security for S / MIME Algorithms（1.2.840.113549.1.9.16.3）」レジストリで、IANAは値17の説明を「id-alg-hss-lms-hashsig」に更新し、これを指すように参照を更新しました資料。
IANA has also added the following note to the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry:
IANAは、「SMI Security for S / MIME Algorithms（1.2.840.113549.1.9.16.3）」レジストリに次のメモも追加しました。
Value 17, "id-alg-hss-lms-hashsig", is also referred to as "id-alg-mts-hashsig".
値17、「id-alg-hss-lms-hashsig」は「id-alg-mts-hashsig」とも呼ばれます。
[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, August 2015.
[ASN1-B] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、2015年8月。
[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015.
[ASN1-E] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X。 690、2015年8月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[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>。
[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>。
[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 (SHS)", FIPS PUB 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（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https://doi.org /10.6028/NIST.FIPS.180-4>。
[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>。
[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <https://www.rfc-editor.org/info/rfc5911>.
[CMSASN1] Hoffman、P。およびJ. Schaad、「暗号化メッセージ構文（CMS）およびS / MIMEの新しいASN.1モジュール」、RFC 5911、DOI 10.17487 / RFC5911、2010年6月、<https：//www.rfc -editor.org/info/rfc5911>。
[CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[CMSASN1U] Schaad、J。およびS. Turner、「暗号化メッセージ構文（CMS）およびX.509（PKIX）を使用する公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487 / RFC6268、7月2011、<https://www.rfc-editor.org/info/rfc6268>。
[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[FWPROT] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、DOI 10.17487 / RFC4108、2005年8月、<https://www.rfc-editor.org/info/rfc4108> 。
[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)", <https://www.iana.org/assignments/leighton-micali-signatures/>.
[IANA-LMS] IANA、「Leighton-Micali Signatures（LMS）」、<https://www.iana.org/assignments/leighton-micali-signatures/>。
[LM] Leighton, T. and S. Micali, "Large provably fast and secure digital signature schemes based on secure hash functions", U.S. Patent 5,432,852, July 1995.
[LM] Leighton、T.およびS. Micali、「安全なハッシュ関数に基づく、大きくて高速かつ安全なデジタル署名方式」、米国特許第5,432,852、1995年7月。
[M1979] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Technical Report No. 1979-1, Information Systems Laboratory, Stanford University, 1979.
[M1979]マークルR.、「秘密、認証、公開鍵システム」、テクニカルレポートNo. 1979-1、スタンフォード大学情報システム研究所、1979。
[M1987] Merkle, R., "A Digital Signature Based on a Conventional Encryption Function", Advances in Cryptology -- CRYPTO '87 Proceedings, Lecture Notes in Computer Science Vol. 293, 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 Vol。 293、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 Vol. 435, DOI 10.1007/0-387-34805-0_21, 1990, <https://doi.org/10.1007/0-387-34805-0_21>.
[M1989a]マークルR.、「認定デジタル署名」、暗号学の進歩-CRYPTO '89 Proceedings、Lecture Notes in Computer Science Vol。 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 Vol. 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 Vol。 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, <https://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、<https://doi.org/10.17226/25196>。
[PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[PKIXASN1] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。 rfc-editor.org/info/rfc5912>。
[PQC] Bernstein, D., "Introduction to post-quantum cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009, <http://www.springer.com/cda/content/document/ cda_downloaddocument/9783540887010-c1.pdf>.
[PQC]バーンスタイン、D。、「ポスト量子暗号の概要」、DOI 10.1007 / 978-3-540-88702-7_1、2009、<http://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>。
<CODE STARTS>
<コード開始>
MTS-HashSig-2013
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
すべてエクスポート;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
-- -- Object Identifiers --
--オブジェクト識別子-
id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 17 }
id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig
-- -- Signature Algorithm and Public Key --
--署名アルゴリズムと公開鍵-
sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig
PARAMS ARE absent
PUBLIC-KEYS { pk-HSS-LMS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } }
pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-hss-lms-hashsig
KEY HSS-LMS-HashSig-PublicKey
PARAMS ARE absent
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSS-LMS-HashSig-PublicKey ::= OCTET STRING
-- -- Expand the signature algorithm set used by CMS [CMSASN1U] --
--CMS [CMSASN1U]で使用される署名アルゴリズムセットを拡張します-
SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
{ sa-HSS-LMS-HashSig, ... }
-- -- Expand the S/MIME capabilities set used by CMS [CMSASN1] --
--CMS [CMSASN1]で使用されるS / MIME機能セットを拡張-
SMimeCaps SMIME-CAPS ::=
{ sa-HSS-LMS-HashSig.&smimeCaps, ... }
END
終わり
<CODE ENDS>
<コード終了>
Acknowledgements
謝辞
Many thanks to Joe Clarke, Roman Danyliw, Scott Fluhrer, Jonathan Hammell, Ben Kaduk, Panos Kampanakis, Barry Leiba, John Mattsson, Jim Schaad, Sean Turner, Daniel Van Geest, and Dale Worley for their careful review and comments.
慎重なレビューとコメントを提供してくれたJoe Clarke、Roman Danyliw、Scott Fluhrer、Jonathan Hammell、Ben Kaduk、Panos Kampanakis、Barry Leiba、John Mattsson、Jim Schaad、Sean Turner、Daniel Van Geest、Dale Worleyに感謝します。
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