| < draft-ietf-lamps-cms-hash-sig-08.txt | draft-ietf-lamps-cms-hash-sig-10.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT R. Housley | INTERNET-DRAFT R. Housley | |||
| Internet Engineering Task Force (IETF) Vigil Security | Internet Engineering Task Force (IETF) Vigil Security | |||
| Intended Status: Proposed Standard | Intended Status: Proposed Standard | |||
| Expires: 11 November 2019 10 May 2019 | Expires: 18 March 2020 18 September 2019 | |||
| Use of the HSS/LMS Hash-based Signature Algorithm | Use of the HSS/LMS Hash-based Signature Algorithm | |||
| in the Cryptographic Message Syntax (CMS) | in the Cryptographic Message Syntax (CMS) | |||
| <draft-ietf-lamps-cms-hash-sig-08> | <draft-ietf-lamps-cms-hash-sig-10> | |||
| Abstract | Abstract | |||
| This document specifies the conventions for using the the HSS/LMS | This document specifies the conventions for using the Hierarchical | |||
| hash-based signature algorithm with the Cryptographic Message Syntax | Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based | |||
| (CMS). In addition, the algorithm identifier and public key syntax | signature algorithm with the Cryptographic Message Syntax (CMS). In | |||
| are provided. The HSS/LMS algorithm is one form of hash-based | addition, the algorithm identifier and public key syntax are | |||
| digital signature; it is described in RFC 8554. | provided. The HSS/LMS algorithm is one form of hash-based digital | |||
| signature; it is described in RFC 8554. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.3. Algorithm Considerations . . . . . . . . . . . . . . . . . 3 | 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 4 | 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 4 | |||
| 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 | 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 | |||
| 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 | 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 | |||
| 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 | 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 | |||
| 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 7 | 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 7 | |||
| 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 8 | 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 8 | |||
| 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 9 | 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
| Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 | Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1. Introduction | 1. Introduction | |||
| This document specifies the conventions for using the HSS/LMS hash- | This document specifies the conventions for using the Hierarchical | |||
| based signature algorithm with the Cryptographic Message Syntax (CMS) | Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based | |||
| [CMS] signed-data content type. The Leighton-Micali Signature (LMS) | signature algorithm with the Cryptographic Message Syntax (CMS) [CMS] | |||
| system provides a one-time digital signature that is a variant of | signed-data content type. The LMS system provides a one-time digital | |||
| Merkle Tree Signatures (MTS). The Hierarchical Signature System | signature that is a variant of Merkle Tree Signatures (MTS). The HSS | |||
| (HSS) is built on top of the LMS system to efficiently scale for a | is built on top of the LMS system to efficiently scale for a larger | |||
| larger numbers of signatures. The HSS/LMS algorithm is one form of | numbers of signatures. The HSS/LMS algorithm is one form of hash- | |||
| hash-based digital signature, and it is described in [HASHSIG]. The | based digital signature, and it is described in [HASHSIG]. The | |||
| HSS/LMS signature algorithm can only be used for a fixed number of | HSS/LMS signature algorithm can only be used for a fixed number of | |||
| signing operations. The number of signing operations depends upon | signing operations with a given private key, and the number of | |||
| the size of the tree. The HSS/LMS signature algorithm uses small | signing operations depends upon the size of the tree. The HSS/LMS | |||
| public keys, and it has low computational cost; however, the | signature algorithm uses small public keys, and it has low | |||
| signatures are quite large. The HSS/LMS private key can be very | computational cost; however, the signatures are quite large. The | |||
| small when the signer is willing to perform additional computation at | HSS/LMS private key can be very small when the signer is willing to | |||
| signing time; alternatively, the private key can consume additional | perform additional computation at signing time; alternatively, the | |||
| memory and provide a faster signing time. | 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]. | ||||
| 1.1. ASN.1 | 1.1. ASN.1 | |||
| CMS values are generated using ASN.1 [ASN1-B], using the Basic | CMS values are generated using ASN.1 [ASN1-B], using the Basic | |||
| Encoding Rules (BER) and the Distinguished Encoding Rules (DER) | Encoding Rules (BER) and the Distinguished Encoding Rules (DER) | |||
| [ASN1-E]. | [ASN1-E]. | |||
| 1.2. Terminology | 1.2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 1.3. Algorithm Considerations | 1.3. Motivation | |||
| There have been recent advances in cryptanalysis and advances in the | ||||
| development of quantum computers. Each of these advances pose a | ||||
| threat to widely deployed digital signature algorithms. | ||||
| At Black Hat USA 2013, some researchers gave a presentation on the | Recent advances in cryptanalysis [BH2013] and progress in the | |||
| current state of public key cryptography. They said: "Current | development of quantum computers [NAS2019] pose a threat to widely | |||
| cryptosystems depend on discrete logarithm and factoring which has | deployed digital signature algorithms. As a result, there is a need | |||
| seen some major new developments in the past 6 months" [BH2013]. Due | to prepare for a day that cryptosystems such as RSA and DSA that | |||
| to advances in cryptanalysis, they encouraged preparation for a day | depend on discrete logarithm and factoring cannot be depended upon. | |||
| when RSA and DSA cannot be depended upon. | ||||
| If large-scale quantum computers are ever built, these computers will | If large-scale quantum computers are ever built, these computers will | |||
| be able to break many of the public-key cryptosystems currently in | be able to break many of the public-key cryptosystems currently in | |||
| use. A post-quantum cryptosystem [PQC] is a system that is secure | use. A post-quantum cryptosystem [PQC] is a system that is secure | |||
| against quantum computers that have more than a trivial number of | against quantum computers that have more than a trivial number of | |||
| quantum bits (qu-bits). It is open to conjecture when it will be | quantum bits (qubits). It is open to conjecture when it will be | |||
| feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA | feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA | |||
| are all vulnerable if large-scale quantum computers come to pass. | are all vulnerable if large-scale quantum computers come to pass. | |||
| The HSS/LMS signature algorithm does not depend on the difficulty of | Since the HSS/LMS signature algorithm does not depend on the | |||
| discrete logarithm or factoring, as a result these algorithms are | difficulty of discrete logarithm or factoring, the HSS/LMS signature | |||
| considered to be post-quantum secure. | algorithm is considered to be post-quantum secure. One use of post- | |||
| quantum secure signatures is the protection of software updates, | ||||
| Hash-based signatures [HASHSIG] are currently defined to use | perhaps using the format described in [FWPROT], to enable deployment | |||
| exclusively SHA-256 [SHS]. An IANA registry is defined so that other | of software that implements new cryptosystems. | |||
| hash functions could be used in the future. LM-OTS signature | ||||
| generation prepends a random string as well as other metadata before | ||||
| computing the hash value. The inclusion of the random value reduces | ||||
| the chances of an attacker being able to find collisions, even if the | ||||
| attacker has a large-scale quantum computer. | ||||
| Today, RSA is often used to digitally sign software updates. This | ||||
| means that the distribution of software updates could be compromised | ||||
| if a significant advance is made in factoring or a large-scale | ||||
| quantum computer is invented. The use of HSS/LMS hash-based | ||||
| signatures to protect software update distribution, perhaps using the | ||||
| format described in [FWPROT], will allow the deployment of software | ||||
| that implements new cryptosystems. | ||||
| 2. HSS/LMS Hash-based Signature Algorithm Overview | 2. HSS/LMS Hash-based Signature Algorithm Overview | |||
| Merkle Tree Signatures (MTS) are a method for signing a large but | Merkle Tree Signatures (MTS) are a method for signing a large but | |||
| fixed number of messages. An MTS system depends on a one-time | fixed number of messages. An MTS system depends on a one-time | |||
| signature method and a collision-resistant hash function. | signature method and a collision-resistant hash function. | |||
| This specification makes use of the hash-based algorithm specified in | This specification makes use of the hash-based algorithm specified in | |||
| [HASHSIG], which is the Leighton and Micali adaptation [LM] of the | [HASHSIG], which is the Leighton and Micali adaptation [LM] of the | |||
| original Lamport-Diffie-Winternitz-Merkle one-time signature system | original Lamport-Diffie-Winternitz-Merkle one-time signature system | |||
| [M1979][M1987][M1989a][M1989b]. | [M1979][M1987][M1989a][M1989b]. | |||
| As implied by the name, the hash-based signature algorithm depends on | As implied by the name, the hash-based signature algorithm depends on | |||
| a collision-resistant hash function. The hash-based signature | a collision-resistant hash function. The hash-based signature | |||
| algorithm specified in [HASHSIG] currently uses only the SHA-256 one- | algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash | |||
| way hash function [SHS], but it also establishes an IANA registry to | function [SHS], but it establishes an IANA registry [IANA-LMS] to | |||
| permit the registration of additional one-way hash functions in the | permit the registration of additional one-way hash functions in the | |||
| future. | future. | |||
| 2.1. Hierarchical Signature System (HSS) | 2.1. Hierarchical Signature System (HSS) | |||
| The MTS system specified in [HASHSIG] uses a hierarchy of trees. The | The MTS system specified in [HASHSIG] uses a hierarchy of trees. The | |||
| Hierarchical N-time Signature System (HSS) allows subordinate trees | Hierarchical N-time Signature System (HSS) allows subordinate trees | |||
| to be generated when needed by the signer. Otherwise, generation of | to be generated when needed by the signer. Otherwise, generation of | |||
| the entire tree might take weeks or longer. | the entire tree might take weeks or longer. | |||
| skipping to change at page 5, line 23 ¶ | skipping to change at page 5, line 11 ¶ | |||
| tree signs the actual message. The signature over the public key and | tree signs the actual message. The signature over the public key and | |||
| the signature over the actual message are LMS signatures as described | the signature over the actual message are LMS signatures as described | |||
| in Section 2.2. | in Section 2.2. | |||
| The elements of the HSS signature value for a stand-alone tree (a top | The elements of the HSS signature value for a stand-alone tree (a top | |||
| tree with no children) can be summarized as: | tree with no children) can be summarized as: | |||
| u32str(0) || | u32str(0) || | |||
| lms_signature /* signature of message */ | lms_signature /* signature of message */ | |||
| where, u32str() and || are used as defined in [HASHSIG]. | ||||
| The elements of the HSS signature value for a tree with Nspk signed | The elements of the HSS signature value for a tree with Nspk signed | |||
| public keys can be summarized as: | public keys can be summarized as: | |||
| u32str(Nspk) || | u32str(Nspk) || | |||
| signed_public_key[0] || | signed_public_key[0] || | |||
| signed_public_key[1] || | signed_public_key[1] || | |||
| ... | ... | |||
| signed_public_key[Nspk-2] || | signed_public_key[Nspk-2] || | |||
| signed_public_key[Nspk-1] || | signed_public_key[Nspk-1] || | |||
| lms_signature /* signature of message */ | lms_signature /* signature of message */ | |||
| where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is | where, as defined in Section 3.3 of [HASHSIG], the signed_public_key | |||
| the lms_signature over the public key followed by the public key | structure contains the lms_signature over the public key followed by | |||
| itself. Note that Nspk is the number of levels in the hierarchy of | the public key itself. Note that Nspk is the number of levels in the | |||
| trees minus 1. | hierarchy of trees minus 1. | |||
| 2.2. Leighton-Micali Signature (LMS) | 2.2. Leighton-Micali Signature (LMS) | |||
| Each tree in the system specified in [HASHSIG] uses the Leighton- | Each tree in the system specified in [HASHSIG] uses the Leighton- | |||
| Micali Signature (LMS) system. LMS systems have two parameters. The | Micali Signature (LMS) system. LMS systems have two parameters. The | |||
| first parameter is the height of the tree, h, which is the number of | first parameter is the height of the tree, h, which is the number of | |||
| levels in the tree minus one. The [HASHSIG] specification supports | 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. | 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 is | Note that there are 2^h leaves in the tree. The second parameter, m, | |||
| the number of bytes output by the hash function, m, which is the | 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] | amount of data associated with each node in the tree. The [HASHSIG] | |||
| specification supports only the SHA-256 hash function [SHS], with | specification supports only the SHA-256 hash function [SHS], with | |||
| m=32. | m=32. As a result, the [HASHSIG] specification supports five tree | |||
| sizes; they are identified as: | ||||
| The [HASHSIG] specification supports five tree sizes: | ||||
| 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; and | LMS_SHA256_M32_H20; and | |||
| LMS_SHA256_M32_H25. | LMS_SHA256_M32_H25. | |||
| The [HASHSIG] specification establishes an IANA registry to permit | The [HASHSIG] specification establishes an IANA registry [IANA-LMS] | |||
| the registration of additional hash functions and additional tree | to permit the registration of additional hash functions and | |||
| sizes in the future. | additional tree sizes in the future. | |||
| The LMS public key is the string consists of four elements: the | As specified in [HASHSIG], the LMS public key consists of four | |||
| lms_algorithm_type from the list above, the otstype to identify the | elements: the lms_algorithm_type from the list above, the otstype to | |||
| LM-OTS type as discussed in Section 2.3, the private key identifier | identify the LM-OTS type as discussed in Section 2.3, the private key | |||
| (I) as described in Section 5.3 of [HASHSIG], and the m-byte string | identifier (I) as described in Section 5.3 of [HASHSIG], and the m- | |||
| associated with the root node of the tree. | byte string associated with the root node of the tree (T[1]). | |||
| The LMS public key can be summarized as: | The LMS public key can be summarized as: | |||
| u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] | u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] | |||
| An LMS signature consists of four elements: the number of the leaf | As specified in [HASHSIG], an LMS signature consists of four | |||
| (q) associated with the LM-OTS signature, an LM-OTS signature as | elements: the number of the leaf (q) associated with the LM-OTS | |||
| described in Section 2.3, a typecode indicating the particular LMS | signature, an LM-OTS signature as described in Section 2.3, a | |||
| algorithm, and an array of values that is associated with the path | typecode indicating the particular LMS algorithm, and an array of | |||
| through the tree from the leaf associated with the LM-OTS signature | values that is associated with the path through the tree from the | |||
| to the root. The array of values contains the siblings of the nodes | leaf associated with the LM-OTS signature to the root. The array of | |||
| on the path from the leaf to the root but does not contain the nodes | values contains the siblings of the nodes on the path from the leaf | |||
| on the path itself. The array for a tree with height h will have h | to the root but does not contain the nodes on the path itself. The | |||
| values. The first value is the sibling of the leaf, the next value | array for a tree with height h will have h values. The first value | |||
| is the sibling of the parent of the leaf, and so on up the path to | is the sibling of the leaf, the next value is the sibling of the | |||
| the root. | parent of the leaf, and so on up the path to the root. | |||
| The four elements of the LMS signature value can be summarized as: | The four elements of the LMS signature value can be summarized as: | |||
| u32str(q) || | u32str(q) || | |||
| ots_signature || | ots_signature || | |||
| u32str(type) || | u32str(type) || | |||
| path[0] || path[1] || ... || path[h-1] | path[0] || path[1] || ... || path[h-1] | |||
| 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) | 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) | |||
| Merkle Tree Signatures (MTS) depend on a one-time signature method. | Merkle Tree Signatures (MTS) depend on a one-time signature method, | |||
| and [HASHSIG] specifies the use of the LM-OTS, which has five | ||||
| [HASHSIG] specifies the use of the LM-OTS. An LM-OTS has five | parameters: | |||
| parameters. | ||||
| n - The number of bytes associated with the hash function. | n - The length in bytes of the hash function output. [HASHSIG] | |||
| [HASHSIG] supports only SHA-256 [SHS], with n=32. | supports only SHA-256 [SHS], with n=32. | |||
| H - A preimage-resistant hash function that accepts byte strings | H - A preimage-resistant hash function that accepts byte strings | |||
| of any length, and returns an n-byte string. | of any length, and returns an n-byte string. | |||
| w - The width in bits of the Winternitz coefficients. [HASHSIG] | w - The width in bits of the Winternitz coefficients. [HASHSIG] | |||
| supports four values for this parameter: w=1; w=2; w=4; and | supports four values for this parameter: w=1; w=2; w=4; and | |||
| w=8. | w=8. | |||
| p - The number of n-byte string elements that make up the LM-OTS | p - The number of n-byte string elements that make up the LM-OTS | |||
| signature. | signature. | |||
| ls - The number of left-shift bits used in the checksum function, | ls - The number of bits that are left-shifted in the final step of | |||
| which is defined in Section 4.4 of [HASHSIG]. | the checksum function, which is defined in Section 4.4 of | |||
| [HASHSIG]. | ||||
| The values of p and ls are dependent on the choices of the parameters | The values of p and ls are dependent on the choices of the parameters | |||
| n and w, as described in Appendix B of [HASHSIG]. | n and w, as described in Appendix B of [HASHSIG]. | |||
| The [HASHSIG] specification supports four LM-OTS variants: | The [HASHSIG] specification supports four LM-OTS variants: | |||
| LMOTS_SHA256_N32_W1; | LMOTS_SHA256_N32_W1; | |||
| LMOTS_SHA256_N32_W2; | LMOTS_SHA256_N32_W2; | |||
| LMOTS_SHA256_N32_W4; and | LMOTS_SHA256_N32_W4; and | |||
| LMOTS_SHA256_N32_W8. | LMOTS_SHA256_N32_W8. | |||
| The [HASHSIG] specification establishes an IANA registry to permit | The [HASHSIG] specification establishes an IANA registry [IANA-LMS] | |||
| the registration of additional variants in the future. | to permit the registration of additional variants in the future. | |||
| Signing involves the generation of C, an n-byte random value. | Signing involves the generation of C, an n-byte random value. | |||
| The LM-OTS signature value can be summarized as the identifier of the | 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 that | LM-OTS variant, the random value, and a sequence of hash values (y[0] | |||
| correspond to the elements of the public key as described in Section | through y[p-1]) that correspond to the elements of the public key as | |||
| 4.5 of [HASHSIG]: | described in Section 4.5 of [HASHSIG]: | |||
| u32str(otstype) || C || y[0] || ... || y[p-1] | u32str(otstype) || C || y[0] || ... || y[p-1] | |||
| 3. Algorithm Identifiers and Parameters | 3. Algorithm Identifiers and Parameters | |||
| The algorithm identifier for an HSS/LMS hash-based signatures is: | The algorithm identifier for an HSS/LMS hash-based signatures is: | |||
| id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) | id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) | |||
| member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) | member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) | |||
| smime(16) alg(3) 17 } | smime(16) alg(3) 17 } | |||
| When this object identifier is used for a HSS/LMS signature, the | When this object identifier is used for an HSS/LMS signature, the | |||
| AlgorithmIdentifier parameters field MUST be absent (that is, the | AlgorithmIdentifier parameters field MUST be absent (that is, the | |||
| parameters are not present; the parameters are not set to NULL). | parameters are not present; the parameters are not set to NULL). | |||
| The signature value is a large OCTET STRING. The signature format is | The signature value is a large OCTET STRING as described in Section 2 | |||
| designed for easy parsing. Each format includes a counter and type | of this document. The signature format is designed for easy parsing. | |||
| codes that indirectly providing all of the information that is needed | The HSS, LMS, and LMOTS component of the signature value each format | |||
| to parse the value during signature validation. | include a counter and a type code that indirectly provide all of the | |||
| information that is needed to parse the value during signature | ||||
| validation. | ||||
| The signature value identifies the hash function used in the HSS/LMS | The signature value identifies the hash function used in the HSS/LMS | |||
| tree. In [HASHSIG] only the SHA-256 hash function [SHS] is | tree. In [HASHSIG] uses only the SHA-256 hash function [SHS], but it | |||
| supported, but it also establishes an IANA registry to permit the | establishes an IANA registry [IANA-LMS] to permit the registration of | |||
| registration of additional hash functions in the future. | additional hash functions in the future. | |||
| 4. HSS/LMS Public Key Identifier | 4. HSS/LMS Public Key Identifier | |||
| The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- | The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- | |||
| hss-lms-hashsig object identifier, and the parameters field MUST be | hss-lms-hashsig object identifier, and the parameters field MUST be | |||
| absent. | absent. | |||
| When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo | When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo | |||
| field of an X.509 certificate [RFC5280], the certificate key usage | field of an X.509 certificate [RFC5280], the certificate key usage | |||
| extension MAY contain digitalSignature, nonRepudiation, keyCertSign, | extension MAY contain digitalSignature, nonRepudiation, keyCertSign, | |||
| skipping to change at page 8, line 48 ¶ | skipping to change at page 8, line 35 ¶ | |||
| Note that the id-alg-hss-lms-hashsig algorithm identifier is also | 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 | referred to as id-alg-mts-hashsig. This synonym is based on the | |||
| terminology used in an early draft of the document that became | terminology used in an early draft of the document that became | |||
| [HASHSIG]. | [HASHSIG]. | |||
| The public key value is an OCTET STRING. Like the signature format, | 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 | it is designed for easy parsing. The value is the number of levels | |||
| in the public key, L, followed by the LMS public key. | in the public key, L, followed by the LMS public key. | |||
| The HSS/LMS public key value can be summarized as: | The HSS/LMS public key value can be described as: | |||
| u32str(L) || lms_public_key | u32str(L) || lms_public_key | |||
| Note that the public key for the top-most LMS tree is the public key | Note that the public key for the top-most LMS tree is the public key | |||
| of the HSS system. When L=1, the HSS system is a single tree. | of the HSS system. When L=1, the HSS system is a single tree. | |||
| 5. Signed-data Conventions | 5. Signed-data Conventions | |||
| As specified in [CMS], the digital signature is produced from the | As specified in [CMS], the digital signature is produced from the | |||
| message digest and the signer's private key. The signature is | message digest and the signer's private key. The signature is | |||
| computed over different value depending on whether signed attributes | computed over different values depending on whether signed attributes | |||
| are absent or present. When signed attributes are absent, the | are absent or present. | |||
| HSS/LMS signature is computed over the content. When signed | ||||
| attributes are present, a hash is computed over the content using the | When signed attributes are absent, the HSS/LMS signature is computed | |||
| same hash function that is used in the HSS/LMS tree, and then a | over the content. When signed attributes are present, a hash is | |||
| message-digest attribute is constructed with the resulting hash | computed over the content using the same hash function that is used | |||
| value, and then DER encode the set of signed attributes, which MUST | in the HSS/LMS tree, and then a message-digest attribute is | |||
| include a content-type attribute and a message-digest attribute, and | constructed with the hash of the content, and then the HSS/LMS | |||
| then the HSS/LMS signature is computed over the output of the DER- | signature is computed over the DER-encoded set of signed attributes | |||
| encode operation. In summary: | (which MUST include a content-type attribute and a message-digest | |||
| attribute). In summary: | ||||
| IF (signed attributes are absent) | IF (signed attributes are absent) | |||
| THEN HSS_LMS_Sign(content) | THEN HSS_LMS_Sign(content) | |||
| ELSE message-digest attribute = Hash(content); | ELSE message-digest attribute = Hash(content); | |||
| HSS_LMS_Sign(DER(SignedAttributes)) | HSS_LMS_Sign(DER(SignedAttributes)) | |||
| When using [HASHSIG], the fields in the SignerInfo are used as | When using [HASHSIG], the fields in the SignerInfo are used as | |||
| follows: | follows: | |||
| digestAlgorithm MUST contain the one-way hash function used to in | digestAlgorithm MUST contain the one-way hash function used in the | |||
| the HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported | HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported hash | |||
| hash function, but other hash functions might be registered in | function, but other hash functions might be registered in the | |||
| the future. For convenience, the AlgorithmIdentifier for | future. For convenience, the AlgorithmIdentifier for SHA-256 | |||
| SHA-256 from [PKIXASN1] is repeated here: | from [PKIXASN1] is repeated here: | |||
| mda-sha256 DIGEST-ALGORITHM ::= { | mda-sha256 DIGEST-ALGORITHM ::= { | |||
| IDENTIFIER id-sha256 | IDENTIFIER id-sha256 | |||
| PARAMS TYPE NULL ARE preferredAbsent } | PARAMS TYPE NULL ARE preferredAbsent } | |||
| id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | |||
| country(16) us(840) organization(1) gov(101) csor(3) | country(16) us(840) organization(1) gov(101) csor(3) | |||
| nistAlgorithms(4) hashalgs(2) 1 } | nistAlgorithms(4) hashalgs(2) 1 } | |||
| signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the | signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the | |||
| skipping to change at page 10, line 11 ¶ | skipping to change at page 9, line 44 ¶ | |||
| signature contains the single HSS signature value resulting from | signature contains the single HSS signature value resulting from | |||
| the signing operation as specified in [HASHSIG]. | the signing operation as specified in [HASHSIG]. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| Implementations MUST protect the private keys. Compromise of the | Implementations MUST protect the private keys. Compromise of the | |||
| private keys may result in the ability to forge signatures. Along | private keys may result in the ability to forge signatures. Along | |||
| with the private key, the implementation MUST keep track of which | with the private key, the implementation MUST keep track of which | |||
| leaf nodes in the tree have been used. Loss of integrity of this | leaf nodes in the tree have been used. Loss of integrity of this | |||
| tracking data can cause an one-time key to be used more than once. | tracking data can cause a one-time key to be used more than once. As | |||
| As a result, when a private key and the tracking data are stored on | a result, when a private key and the tracking data are stored on non- | |||
| non-volatile media or stored in a virtual machine environment, care | volatile media or stored in a virtual machine environment, failed | |||
| must be taken to preserve confidentiality and integrity. | writes, virtual machine snapshotting or cloning, and other | |||
| operational concerns must be considered to ensure confidentiality and | ||||
| integrity. | ||||
| When generating a LMS key pair, an implementation MUST generate each | When generating an LMS key pair, an implementation MUST generate each | |||
| key pair independently of all other key pairs in the HSS tree. | key pair independently of all other key pairs in the HSS tree. | |||
| An implementation MUST ensure that a LM-OTS private key is used to | An implementation MUST ensure that a LM-OTS private key is used to | |||
| generate a signature only one time, and ensure that it cannot be used | generate a signature only one time, and ensure that it cannot be used | |||
| for any other purpose. | for any other purpose. | |||
| The generation of private keys relies on random numbers. The use of | The generation of private keys relies on random numbers. The use of | |||
| inadequate pseudo-random number generators (PRNGs) to generate these | inadequate pseudo-random number generators (PRNGs) to generate these | |||
| values can result in little or no security. An attacker may find it | values can result in little or no security. An attacker may find it | |||
| much easier to reproduce the PRNG environment that produced the keys, | much easier to reproduce the PRNG environment that produced the keys, | |||
| searching the resulting small set of possibilities, rather than brute | searching the resulting small set of possibilities, rather than brute | |||
| force searching the whole key space. The generation of quality | force searching the whole key space. The generation of quality | |||
| random numbers is difficult, and [RFC4086] offers important guidance | random numbers is difficult, and [RFC4086] offers important guidance | |||
| in this area. | in this area. | |||
| The generation of hash-based signatures also depends on random | The generation of hash-based signatures also depends on random | |||
| numbers. While the consequences of an inadequate pseudo-random | numbers. While the consequences of an inadequate pseudo-random | |||
| number generator (PRNGs) to generate these values is much less severe | number generator (PRNG) to generate these values is much less severe | |||
| than the generation of private keys, the guidance in [RFC4086] | than in the generation of private keys, the guidance in [RFC4086] | |||
| remains important. | remains important. | |||
| When computing signatures, the same hash function SHOULD be used to | When computing signatures, the same hash function SHOULD be used to | |||
| compute the message digest of the content and the signed attributes, | compute the message digest of the content and the signed attributes, | |||
| if they are present. | if they are present. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) | SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) | |||
| registry, change the reference for value 64 to point to this | registry, change the reference for value 64 to point to this | |||
| skipping to change at page 12, line 28 ¶ | skipping to change at page 12, line 16 ¶ | |||
| for the Cryptographic Message Syntax (CMS) and the Public | for the Cryptographic Message Syntax (CMS) and the Public | |||
| Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI | Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI | |||
| 10.17487/RFC6268, July 2011, <http://www.rfc- | 10.17487/RFC6268, July 2011, <http://www.rfc- | |||
| editor.org/info/rfc6268>. | editor.org/info/rfc6268>. | |||
| [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to | [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to | |||
| Protect Firmware Packages", RFC 4108, DOI | Protect Firmware Packages", RFC 4108, DOI | |||
| 10.17487/RFC4108, August 2005, <http://www.rfc- | 10.17487/RFC4108, August 2005, <http://www.rfc- | |||
| editor.org/info/rfc4108>. | editor.org/info/rfc4108>. | |||
| [IANA-LMS] IANA Registry for Leighton-Micali Signatures (LMS). | ||||
| <https://www.iana.org/assignments/leighton-micali- | ||||
| signatures/leighton-micali-signatures.xhtml>. | ||||
| [LM] Leighton, T. and S. Micali, "Large provably fast and | [LM] Leighton, T. and S. Micali, "Large provably fast and | |||
| secure digital signature schemes from secure hash | secure digital signature schemes from secure hash | |||
| functions", U.S. Patent 5,432,852, July 1995. | functions", U.S. Patent 5,432,852, July 1995. | |||
| [M1979] Merkle, R., "Secrecy, Authentication, and Public Key | [M1979] Merkle, R., "Secrecy, Authentication, and Public Key | |||
| Systems", Stanford University Information Systems | Systems", Stanford University Information Systems | |||
| Laboratory Technical Report 1979-1, 1979. | Laboratory Technical Report 1979-1, 1979. | |||
| [M1987] Merkle, R., "A Digital Signature Based on a Conventional | [M1987] Merkle, R., "A Digital Signature Based on a Conventional | |||
| Encryption Function", Lecture Notes in Computer Science | Encryption Function", Lecture Notes in Computer Science | |||
| crypto87, 1988. | crypto87, 1988. | |||
| [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes | [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes | |||
| in Computer Science crypto89, 1990. | in Computer Science crypto89, 1990. | |||
| [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes | [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes | |||
| in Computer Science crypto89, 1990. | in Computer Science crypto89, 1990. | |||
| [NAS2019] National Academies of Sciences, Engineering, and Medicine, | ||||
| "Quantum Computing: Progress and Prospects", The National | ||||
| Academies Press, DOI 10.17226/25196, 2019. | ||||
| [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | |||
| Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | |||
| DOI 10.17487/RFC5912, June 2010, <http://www.rfc- | DOI 10.17487/RFC5912, June 2010, <http://www.rfc- | |||
| editor.org/info/rfc5912>. | editor.org/info/rfc5912>. | |||
| [PQC] Bernstein, D., "Introduction to post-quantum | [PQC] Bernstein, D., "Introduction to post-quantum | |||
| cryptography", 2009. | cryptography", 2009. | |||
| <http://www.pqcrypto.org/www.springer.com/cda/content/ | <http://www.pqcrypto.org/www.springer.com/cda/content/ | |||
| document/cda_downloaddocument/9783540887010-c1.pdf> | document/cda_downloaddocument/9783540887010-c1.pdf> | |||
| skipping to change at page 14, line 34 ¶ | skipping to change at page 14, line 34 ¶ | |||
| SMimeCaps SMIME-CAPS ::= | SMimeCaps SMIME-CAPS ::= | |||
| { sa-HSS-LMS-HashSig.&smimeCaps, ... } | { sa-HSS-LMS-HashSig.&smimeCaps, ... } | |||
| END | END | |||
| <CODE ENDS> | <CODE ENDS> | |||
| Acknowledgements | Acknowledgements | |||
| Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, | Many thanks to Scott Fluhrer, Jonathan Hammell, Ben Kaduk, Panos | |||
| John Mattsson, Jim Schaad, Sean Turner, and Daniel Van Geest for | Kampanakis, Barry Leiba, John Mattsson, Jim Schaad, Sean Turner, | |||
| Daniel Van Geest, Roman Danyliw, Dale Worley, and Joe Clarke for | ||||
| their careful review and comments. | their careful review and comments. | |||
| Author's Address | Author's Address | |||
| Russ Housley | Russ Housley | |||
| Vigil Security, LLC | Vigil Security, LLC | |||
| 516 Dranesville Road | 516 Dranesville Road | |||
| Herndon, VA 20170 | Herndon, VA 20170 | |||
| USA | USA | |||
| End of changes. 37 change blocks. | ||||
| 135 lines changed or deleted | 135 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||