--- 1/draft-ietf-lamps-cms-hash-sig-01.txt 2018-10-17 13:13:11.794512471 -0700 +++ 2/draft-ietf-lamps-cms-hash-sig-02.txt 2018-10-17 13:13:11.830513336 -0700 @@ -1,18 +1,19 @@ -Internet Engineering Task Force (IETF) R. Housley -Intended Status: Proposed Standard Vigil Security -Expires: 27 March 2019 23 September 2018 +INTERNET-DRAFT R. Housley +Internet Engineering Task Force (IETF) Vigil Security +Intended Status: Proposed Standard +Expires: 17 April 2019 17 October 2018 Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) - + Abstract This document specifies the conventions for using the the HSS/LMS hash-based signature algorithm with the Cryptographic Message Syntax (CMS). The HSS/LMS algorithm is one form of hash-based digital signature; it is described in [HASHSIG]. Status of this Memo @@ -54,42 +55,42 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 3 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 4 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 5 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7 - 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 6.1. Implementation Security Considerations . . . . . . . . . . 8 + 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6.1. Implementation Security Considerations . . . . . . . . . . 9 6.2. Algorithm Security Considerations . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 12 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document specifies the conventions for using the HSS/LMS hash- based signature algorithm with the Cryptographic Message Syntax (CMS) [CMS] signed-data content type. The Leighton-Micali Signature (LMS) system provides a one-time digital signature that is a variant of - Merkle Tree Signatures (MTS). A Hierarchical Signature System (HSS) - 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 + Merkle Tree Signatures (MTS). The Hierarchical Signature System + (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. The HSS/LMS signature algorithm uses small private and public keys, and it has low computational cost; however, the signatures are quite large. 1.1. ASN.1 CMS values are generated using ASN.1 [ASN1-B], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [ASN1-E]. @@ -120,59 +121,60 @@ permit the registration of additional one-way hash functions in the future. 2.1. Hierarchical Signature System (HSS) The MTS system specified in [HASHSIG] uses a hierarchy of trees. The Hierarchical N-time 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. - An HSS signature as specified in 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. Each signed public key is represented by the hash value - at the root of the tree, and it also contains information about the - tree structure. The signature over the public key is an LMS - signature as described in Section 2.2. + 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. + Each signed public key is represented by the hash value at the root + of the tree, and it also contains information about the tree + structure. The signature over the public key is an LMS signature as + described in Section 2.2. The elements of the HSS signature value for a stand-alone tree can be summarized as: u32str(0) || lms_signature /* signature of message */ - The elements of the HSS signature value for a tree with Nspk levels - can be summarized as: + The elements of the HSS signature value for a tree with Nspk signed + public keys can be summarized as: u32str(Nspk) || signed_public_key[0] || signed_public_key[1] || ... signed_public_key[Nspk-2] || signed_public_key[Nspk-1] || lms_signature_on_message - where, as defined in Section 7 of [HASHSIG], a signed_public_key is + where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is the lms_signature over the public key followed by the public key - itself. + itself. Note that Nspk is the number of levels in the hierarchy of + trees minus 1. 2.2. Leighton-Micali Signature (LMS) 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 is - the number of bytes output by the hash function, m, which the amount - of data associated with each node in the tree. The [HASHSIG] + the number of bytes output by the hash function, m, which is the + amount of data associated with each node in the tree. The [HASHSIG] specification supports only the SHA-256 hash function [SHS], with m=32. Currently, the [HASHSIG] specification supports five tree sizes: LMS_SHA256_M32_H5; LMS_SHA256_M32_H10; LMS_SHA256_M32_H15; LMS_SHA256_M32_H20; and LMS_SHA256_M32_H25. @@ -212,89 +214,105 @@ of any length, and returns an n-byte string. 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. p - The number of n-byte string elements that make up the LM-OTS signature. ls - The number of left-shift bits used in the checksum function, - which is defined in Section 4.5 of [HASHSIG]. + which is defined in Section 4.4 of [HASHSIG]. The values of p and ls are dependent on the choices of the parameters - n and w, as described in Appendix A of [HASHSIG]. + n and w, as described in Appendix B of [HASHSIG]. Currently, the [HASHSIG] specification supports four LM-OTS variants: LMOTS_SHA256_N32_W1; LMOTS_SHA256_N32_W2; LMOTS_SHA256_N32_W4; and LMOTS_SHA256_N32_W8. The [HASHSIG] specification establishes an IANA registry to permit the registration of additional variants in the future. Signing involves the generation of C, an n-byte random value. The LM-OTS signature value can be summarized as: u32str(otstype) || C || y[0] || ... || y[p-1] 3. Algorithm Identifiers and Parameters - The algorithm identifier for an HSS/LMS hash-based signature is - solely the id-alg-hss-lms-hashsig object identifier: + The algorithm identifier for an HSS/LMS hash-based signature when + SHA-256 [SHS] is used to hash the content is the + id-alg-hss-lms-hashsig-with-sha256 object identifier: - id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) + id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) - smime(16) alg(3) 17 } + smime(16) alg(3) TBD } - When the id-alg-hss-lms-hashsig object identifier is used for a - signature, the AlgorithmIdentifier parameters field MUST be absent - (that is, the parameters are not present; the parameters are not set - to NULL). + The algorithm identifier for an HSS/LMS hash-based signature when + SHA-384 [SHS] is used to hash the content is the + id-alg-hss-lms-hashsig-with-sha384 object identifier: - 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 of the document that became - [HASHSIG]. + id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + smime(16) alg(3) TBD } + + The algorithm identifier for an HSS/LMS hash-based signature when + SHA-512 [SHS] is used to hash the content is the + id-alg-hss-lms-hashsig-with-sha512 object identifier: + + id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + smime(16) alg(3) TBD } + + When any of these object identifiers is used for a signature, the + AlgorithmIdentifier parameters field MUST be absent (that is, the + parameters are not present; the parameters are not set to NULL). The signature values is a large OCTET STRING. The signature format is designed for easy parsing. Each format includes a counter and type codes that indirectly providing all of the information that is needed to parse the value during signature validation. 4. HSS/LMS Public Key Identifier - When using [HASHSIG], the algorithm identifier that is used to - identify the signature value is also used to identify the HSS/LMS - public key. The algorithm parameters field MUST be absent. + The AlgorithmIdentifier for an HHS/LMS public key uses the id-alg- + hss-lms-hashsig object identifier, and the parameters field MUST be + absent. The SubjectPublicKeyInfo field of an X.509 certificate [RFC5280] is - one place where this identifier appears. In this situation, the - certificate key usage extension MAY contain digitalSignature, - nonRepudiation, keyCertSign, and cRLSign; however, it MUST NOT - contain other values. + one place where this algorithm identifier appears. In this + situation, the certificate key usage extension MAY contain + digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however, + it MUST NOT contain other values. 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 of the document that became + [HASHSIG]. + The public key value is an OCTET STRING. Like the signature format, - it is designed for easy parsing. The value is a length, L, followed - by the public key itself. + it is designed for easy parsing. The value is the number of levels + in the public key, L, followed by the LMS public key. The HSS/LMS public key value can be summarized as: u32str(L) || lms_public_key 5. Signed-data Conventions As specified in [CMS], the digital signature is produced from the message digest and the signer's private key. If signed attributes @@ -308,33 +326,37 @@ THEN md = Hash(content) ELSE message-digest attribute = Hash(content); md = Hash(DER(SignedAttributes)) Sign(md) When using [HASHSIG], the fields in the SignerInfo are used as follows: digestAlgorithms SHOULD contain the one-way hash function used to - compute the message digest on the eContent value. Since the - hash-based signature algorithms all depend on SHA-256, it is - strongly RECOMMENDED that SHA-256 also be used to compute the - message digest on the content. + compute the message digest on the eContent value. In + [HASHSIG], SHA-256 is used throughout the hash tree, and the + hash computation includes a random string. This random data + makes it harder for an attacker to find collisions. The signer + SHOULD use SHA-256 or a stronger hash function to compute the + message digest on the content. For + this purpose, Algorithm identifiers for SHA-256, SHA-384, and + SHA-512 are provided in this document. Further, the same one-way hash function SHOULD be used to compute the message digest on both the eContent and the - signedAttributes value if signedAttributes are present. Again, - since the hash-based signature algorithms all depend on - SHA-256, it is strongly RECOMMENDED that SHA-256 be used. + signedAttributes value if signedAttributes are present. - signatureAlgorithm MUST contain id-alg-hss-lms-hashsig. The - algorithm parameters field MUST be absent. + signatureAlgorithm MUST contain id-alg-hss-lms-hashsig-with- + sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms- + hashsig-with-sha512. The algorithm parameters field MUST be + absent. signature contains the single HSS signature value resulting from the signing operation as specified in [HASHSIG]. 6. Security Considerations 6.1. Implementation Security Considerations Implementations must protect the private keys. Compromise of the private keys may result in the ability to forge signatures. Along @@ -357,24 +379,23 @@ force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area. The generation of hash-based signatures also depends on random numbers. While the consequences of an inadequate pseudo-random number generator (PRNGs) to generate these values is much less severe than the generation of private keys, the guidance in [RFC4086] remains important. - When computing signatures, the same hash function SHOULD be used for - all operations. In this specification, only SHA-256 is used. Using - only SHA-256 reduces the number of possible failure points in the - signature process. + 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. 6.2. Algorithm Security Considerations At Black Hat USA 2013, some researchers gave a presentation on the current sate of public key cryptography. They said: "Current cryptosystems depend on discrete logarithm and factoring which has seen some major new developments in the past 6 months" [BH2013]. They encouraged preparation for a day when RSA and DSA cannot be depended upon. @@ -405,25 +426,37 @@ 7. IANA Considerations 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 document. In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry, change the description for value 17 to "id-alg-hss-lms-hashsig" and change the reference to point to this - document. Also, add the following note at the top of the registry: + document. Also, add the following note to the registry: Value 17, "id-alg-hss-lms-hashsig", is also referred to as "id-alg-mts-hashsig". + In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) + registry, assign a new value for id-alg-hss-lms-hashsig-with-sha256 + with a reference to this document. + + In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) + registry, assign a new value for id-alg-hss-lms-hashsig-with-sha384 + with a reference to this document. + + In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) + registry, assign a new value for id-alg-hss-lms-hashsig-with-sha512 + with a reference to this document. + 8. Acknowledgements Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel Van Geest for their careful review and comments. 9. References 9.1. Normative References [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation @@ -528,65 +561,97 @@ 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) } - mda-sha256 + mda-sha256, mda-sha384, mda-sha512 FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54) } ; -- -- 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-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-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + smime(16) alg(3) TBD } + + id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + smime(16) alg(3) TBD } + + id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + smime(16) alg(3) TBD } -- -- Signature Algorithm and Public Key -- - sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= { - IDENTIFIER id-alg-hss-lms-hashsig + sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= { + IDENTIFIER id-alg-hss-lms-hashsig-with-sha256 PARAMS ARE absent HASHES { mda-sha256 } PUBLIC-KEYS { pk-HSS-LMS-HashSig } - SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } } + SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } } + + sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= { + IDENTIFIER id-alg-hss-lms-hashsig-with-sha384 + PARAMS ARE absent + HASHES { mda-sha384 } + PUBLIC-KEYS { pk-HSS-LMS-HashSig } + SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } } + + sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= { + IDENTIFIER id-alg-hss-lms-hashsig-with-sha512 + PARAMS ARE absent + HASHES { mda-sha512 } + PUBLIC-KEYS { pk-HSS-LMS-HashSig } + SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } } 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] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= - { sa-HSS-LMS-HashSig, ... } + { sa-HSS-LMS-HashSig-with-SHA256 | + sa-HSS-LMS-HashSig-with-SHA384 | + sa-HSS-LMS-HashSig-with-SHA512, ... } -- -- Expand the S/MIME capabilities set used by CMS [CMSASN1] -- - SMimeCaps SMIME-CAPS ::= { sa-HSS-LMS-HashSig.&smimeCaps, ... } + SMimeCaps SMIME-CAPS ::= + { sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps | + sa-HSS-LMS-HashSig-with-SHA384.&smimeCaps | + sa-HSS-LMS-HashSig-with-SHA512.&smimeCaps, ... } END Author's Address Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA