draft-ietf-lamps-cms-hash-sig-08.txt | draft-ietf-lamps-cms-hash-sig-09.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: 10 February 2020 10 August 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-09> | |||

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. The number of signing operations depends upon | |||

the size of the tree. The HSS/LMS signature algorithm uses small | the size of the tree. The HSS/LMS signature algorithm uses small | |||

public keys, and it has low computational cost; however, the | public keys, and it has low computational cost; however, the | |||

signatures are quite large. The HSS/LMS private key can be very | signatures are quite large. The HSS/LMS private key can be very | |||

small when the signer is willing to perform additional computation at | small when the signer is willing to perform additional computation at | |||

signing time; alternatively, the private key can consume additional | signing time; alternatively, the private key can consume additional | |||

memory and provide a faster signing time. | 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 | There have been recent advances in cryptanalysis and advances in the | |||

development of quantum computers. Each of these advances pose a | development of quantum computers. Each of these advances pose a | |||

threat to widely deployed digital signature algorithms. | threat to widely deployed digital signature algorithms. | |||

At Black Hat USA 2013, some researchers gave a presentation on the | Recent advances in cryptoanalysis [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 (qu-bits). 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 | The HSS/LMS signature algorithm does not depend on the difficulty of | |||

discrete logarithm or factoring, as a result these algorithms are | discrete logarithm or factoring, as a result these algorithms are | |||

considered to be post-quantum secure. | considered to be post-quantum secure. One use of post-quantum secure | |||

signatures is the protection of software updates, perhaps using the | ||||

Hash-based signatures [HASHSIG] are currently defined to use | format described in [FWPROT], to enable deployment of software that | |||

exclusively SHA-256 [SHS]. An IANA registry is defined so that other | 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] currently uses only the SHA-256 one- | |||

way hash function [SHS], but it also establishes an IANA registry to | way hash function [SHS], but it also establishes an IANA registry | |||

permit the registration of additional one-way hash functions in the | [IANA-LMS] to permit the registration of additional one-way hash | |||

future. | functions in the 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. | |||

An HSS signature as specified in [HASHSIG] carries the number of | An HSS signature as specified in [HASHSIG] carries the number of | |||

signed public keys (Nspk), followed by that number of signed public | signed public keys (Nspk), followed by that number of signed public | |||

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 is | |||

the number of bytes output by the hash function, m, which is the | 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] | 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. The signature format is | |||

designed for easy parsing. Each format includes a counter and type | designed for easy parsing. Each format includes a counter and type | |||

codes that indirectly providing all of the information that is needed | codes that indirectly providing all of the information that is needed | |||

to parse the value during signature validation. | 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] only the SHA-256 hash function [SHS] is | |||

supported, but it also establishes an IANA registry to permit the | supported, but it also establishes an IANA registry [IANA-LMS] to | |||

registration of additional hash functions in the future. | permit the registration of 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 9, line 10 ¶ | skipping to change at page 8, line 45 ¶ | |||

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 to contain the resulting hash value, and then the result | |||

then the HSS/LMS signature is computed over the output of the DER- | of DER encoding the set of signed attributes (which MUST include a | |||

encode operation. In summary: | content-type attribute and a message-digest attribute, and then the | |||

HSS/LMS signature is computed over the DER-encoded output. 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 to in | |||

skipping to change at page 10, line 11 ¶ | skipping to change at page 9, line 43 ¶ | |||

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, care must | |||

must be taken to preserve confidentiality and integrity. | be taken to preserve 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, | |||

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 35 ¶ | skipping to change at page 14, line 35 ¶ | |||

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, Panos Kampanakis, | |||

John Mattsson, Jim Schaad, Sean Turner, and Daniel Van Geest for | John Mattsson, Jim Schaad, Sean Turner, Daniel Van Geest, Roman | |||

their careful review and comments. | Danyliw, Dale Worley, and Joe Clarke for 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 | |||

EMail: housley@vigilsec.com | EMail: housley@vigilsec.com | |||

End of changes. 31 change blocks. | ||||

108 lines changed or deleted | | 108 lines changed or added | ||

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |