 1/draftietflampscmshashsig01.txt 20181017 13:13:11.794512471 0700
+++ 2/draftietflampscmshashsig02.txt 20181017 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
+INTERNETDRAFT 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 Hashbased Signature Algorithm
in the Cryptographic Message Syntax (CMS)

+
Abstract
This document specifies the conventions for using the the HSS/LMS
hashbased signature algorithm with the Cryptographic Message Syntax
(CMS). The HSS/LMS algorithm is one form of hashbased 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 Hashbased Signature Algorithm Overview . . . . . . . 3
2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4
2.2. LeightonMicali Signature (LMS) . . . . . . . . . . . . . 4
2.3. LeightonMicali Onetime Signature Algorithm (LMOTS) . . 5
3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6
4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7
 5. Signeddata Conventions . . . . . . . . . . . . . . . . . . . 7
 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
 6.1. Implementation Security Considerations . . . . . . . . . . 8
+ 5. Signeddata 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] signeddata content type. The LeightonMicali Signature (LMS)
system provides a onetime 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
+ hashbased 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 [ASN1B], using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[ASN1E].
@@ 120,59 +121,60 @@
permit the registration of additional oneway hash functions in the
future.
2.1. Hierarchical Signature System (HSS)
The MTS system specified in [HASHSIG] uses a hierarchy of trees. The
Hierarchical Ntime 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 standalone 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[Nspk2] 
signed_public_key[Nspk1] 
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. LeightonMicali 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 SHA256 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 nbyte 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 nbyte string elements that make up the LMOTS
signature.
ls  The number of leftshift 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 LMOTS 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 nbyte random value.
The LMOTS signature value can be summarized as:
u32str(otstype)  C  y[0]  ...  y[p1]
3. Algorithm Identifiers and Parameters
 The algorithm identifier for an HSS/LMS hashbased signature is
 solely the idalghsslmshashsig object identifier:
+ The algorithm identifier for an HSS/LMS hashbased signature when
+ SHA256 [SHS] is used to hash the content is the
+ idalghsslmshashsigwithsha256 object identifier:
 idalghsslmshashsig OBJECT IDENTIFIER ::= { iso(1)
+ idalghsslmshashsigwithsha256 OBJECT IDENTIFIER ::= { iso(1)
memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
 smime(16) alg(3) 17 }
+ smime(16) alg(3) TBD }
 When the idalghsslmshashsig 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 hashbased signature when
+ SHA384 [SHS] is used to hash the content is the
+ idalghsslmshashsigwithsha384 object identifier:
 Note that the idalghsslmshashsig algorithm identifier is also
 referred to as idalgmtshashsig. This synonym is based on the
 terminology used in an early draft of the document that became
 [HASHSIG].
+ idalghsslmshashsigwithsha384 OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ smime(16) alg(3) TBD }
+
+ The algorithm identifier for an HSS/LMS hashbased signature when
+ SHA512 [SHS] is used to hash the content is the
+ idalghsslmshashsigwithsha512 object identifier:
+
+ idalghsslmshashsigwithsha512 OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(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 idalg
+ hsslmshashsig 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.
pkHSSLMSHashSig PUBLICKEY ::= {
IDENTIFIER idalghsslmshashsig
KEY HSSLMSHashSigPublicKey
PARAMS ARE absent
CERTKEYUSAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSSLMSHashSigPublicKey ::= OCTET STRING
+ Note that the idalghsslmshashsig algorithm identifier is also
+ referred to as idalgmtshashsig. 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. Signeddata 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 messagedigest 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 oneway hash function used to
 compute the message digest on the eContent value. Since the
 hashbased signature algorithms all depend on SHA256, it is
 strongly RECOMMENDED that SHA256 also be used to compute the
 message digest on the content.
+ compute the message digest on the eContent value. In
+ [HASHSIG], SHA256 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 SHA256 or a stronger hash function to compute the
+ message digest on the content. For
+ this purpose, Algorithm identifiers for SHA256, SHA384, and
+ SHA512 are provided in this document.
Further, the same oneway 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 hashbased signature algorithms all depend on
 SHA256, it is strongly RECOMMENDED that SHA256 be used.
+ signedAttributes value if signedAttributes are present.
 signatureAlgorithm MUST contain idalghsslmshashsig. The
 algorithm parameters field MUST be absent.
+ signatureAlgorithm MUST contain idalghsslmshashsigwith
+ sha256, idalghsslmshashsigwithsha384, or idalghsslms
+ hashsigwithsha512. 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 hashbased signatures also depends on random
numbers. While the consequences of an inadequate pseudorandom
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 SHA256 is used. Using
 only SHA256 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
"idalghsslmshashsig" 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, "idalghsslmshashsig", is also referred to as
"idalgmtshashsig".
+ In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)
+ registry, assign a new value for idalghsslmshashsigwithsha256
+ 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 idalghsslmshashsigwithsha384
+ 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 idalghsslmshashsigwithsha512
+ 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
[ASN1B] ITUT, "Information technology  Abstract Syntax Notation
@@ 528,65 +561,97 @@
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLICKEY, SIGNATUREALGORITHM, SMIMECAPS
FROM AlgorithmInformation2009  RFC 5911 [CMSASN1]
{ iso(1) identifiedorganization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) idmod(0)
idmodalgorithmInformation02(58) }
 mdasha256
+ mdasha256, mdasha384, mdasha512
FROM PKIX1PSSOAEPAlgorithms2009  RFC 5912 [PKIXASN1]
{ iso(1) identifiedorganization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) idmod(0)
idmodpkix1rsapkalgs02(54) } ;

 Object Identifiers

 idalghsslmshashsig OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }
+ idalghsslmshashsig OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ smime(16) alg(3) 17 }
+
+ idalghsslmshashsigwithsha256 OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ smime(16) alg(3) TBD }
+
+ idalghsslmshashsigwithsha384 OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ smime(16) alg(3) TBD }
+
+ idalghsslmshashsigwithsha512 OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+ smime(16) alg(3) TBD }

 Signature Algorithm and Public Key

 saHSSLMSHashSig SIGNATUREALGORITHM ::= {
 IDENTIFIER idalghsslmshashsig
+ saHSSLMSHashSigwithSHA256 SIGNATUREALGORITHM ::= {
+ IDENTIFIER idalghsslmshashsigwithsha256
PARAMS ARE absent
HASHES { mdasha256 }
PUBLICKEYS { pkHSSLMSHashSig }
 SMIMECAPS { IDENTIFIED BY idalghsslmshashsig } }
+ SMIMECAPS { IDENTIFIED BY idalghsslmshashsigwithsha256 } }
+
+ saHSSLMSHashSigwithSHA384 SIGNATUREALGORITHM ::= {
+ IDENTIFIER idalghsslmshashsigwithsha384
+ PARAMS ARE absent
+ HASHES { mdasha384 }
+ PUBLICKEYS { pkHSSLMSHashSig }
+ SMIMECAPS { IDENTIFIED BY idalghsslmshashsigwithsha384 } }
+
+ saHSSLMSHashSigwithSHA512 SIGNATUREALGORITHM ::= {
+ IDENTIFIER idalghsslmshashsigwithsha512
+ PARAMS ARE absent
+ HASHES { mdasha512 }
+ PUBLICKEYS { pkHSSLMSHashSig }
+ SMIMECAPS { IDENTIFIED BY idalghsslmshashsigwithsha512 } }
pkHSSLMSHashSig PUBLICKEY ::= {
IDENTIFIER idalghsslmshashsig
KEY HSSLMSHashSigPublicKey
PARAMS ARE absent
CERTKEYUSAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSSLMSHashSigPublicKey ::= OCTET STRING

 Expand the signature algorithm set used by CMS [CMSASN1U]

SignatureAlgorithmSet SIGNATUREALGORITHM ::=
 { saHSSLMSHashSig, ... }
+ { saHSSLMSHashSigwithSHA256 
+ saHSSLMSHashSigwithSHA384 
+ saHSSLMSHashSigwithSHA512, ... }

 Expand the S/MIME capabilities set used by CMS [CMSASN1]

 SMimeCaps SMIMECAPS ::= { saHSSLMSHashSig.&smimeCaps, ... }
+ SMimeCaps SMIMECAPS ::=
+ { saHSSLMSHashSigwithSHA256.&smimeCaps 
+ saHSSLMSHashSigwithSHA384.&smimeCaps 
+ saHSSLMSHashSigwithSHA512.&smimeCaps, ... }
END
Author's Address
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA