 1/draftietflampscmshashsig07.txt 20190510 08:15:41.004462763 0700
+++ 2/draftietflampscmshashsig08.txt 20190510 08:15:41.036463573 0700
@@ 1,27 +1,27 @@
INTERNETDRAFT R. Housley
Internet Engineering Task Force (IETF) Vigil Security
Intended Status: Proposed Standard
Expires: 6 September 2019 6 March 2019
+Expires: 11 November 2019 10 May 2019
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). In addition, the algorithm identifier and public key syntax
are provided. The HSS/LMS algorithm is one form of hashbased
 digital signature; it is described in [HASHSIG].
+ digital signature; it is described in RFC 8554.
Status of this Memo
This InternetDraft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
@@ 57,26 +57,26 @@
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Algorithm Considerations . . . . . . . . . . . . . . . . . 3
2. HSS/LMS Hashbased Signature Algorithm Overview . . . . . . . 4
2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4
2.2. LeightonMicali Signature (LMS) . . . . . . . . . . . . . 5
2.3. LeightonMicali Onetime Signature Algorithm (LMOTS) . . 6
3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 7
4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 8
 5. Signeddata Conventions . . . . . . . . . . . . . . . . . . . 8
 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 5. Signeddata Conventions . . . . . . . . . . . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
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
@@ 102,51 +102,58 @@
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Algorithm Considerations
+ 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
current state 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.
+ seen some major new developments in the past 6 months" [BH2013]. Due
+ to advances in cryptanalysis, they encouraged preparation for a day
+ when RSA and DSA cannot be depended upon.
 A postquantum cryptosystem [PQC] is a system that is secure against
 quantum computers that have more than a trivial number of quantum
 bits. It is open to conjecture when it will be feasible to build
 such a machine. RSA, DSA, and ECDSA are not postquantum secure.
+ If largescale quantum computers are ever built, these computers will
+ be able to break many of the publickey cryptosystems currently in
+ use. A postquantum cryptosystem [PQC] is a system that is secure
+ against quantum computers that have more than a trivial number of
+ quantum bits (qubits). It is open to conjecture when it will be
+ feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA
+ are all vulnerable if largescale quantum computers come to pass.
 The LMOTS onetime signature, LMS, and HSS do not depend on discrete
 logarithm or factoring, as a result these algorithms are considered
 to be postquantum secure.
+ The HSS/LMS signature algorithm does not depend on the difficulty of
+ discrete logarithm or factoring, as a result these algorithms are
+ considered to be postquantum secure.
Hashbased signatures [HASHSIG] are currently defined to use
exclusively SHA256 [SHS]. An IANA registry is defined so that other
hash functions could be used in the future. LMOTS 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 largescale 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 quantum computer
 is invented. The use of HSS/LMS hashbased signatures to protect
 software update distribution, perhaps using the format described in
 [FWPROT], will allow the deployment of software that implements new
 cryptosystems.
+ if a significant advance is made in factoring or a largescale
+ quantum computer is invented. The use of HSS/LMS hashbased
+ 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 Hashbased Signature Algorithm Overview
Merkle Tree Signatures (MTS) are a method for signing a large but
fixed number of messages. An MTS system depends on a onetime
signature method and a collisionresistant hash function.
This specification makes use of the hashbased algorithm specified in
[HASHSIG], which is the Leighton and Micali adaptation [LM] of the
original LamportDiffieWinternitzMerkle onetime signature system
@@ 213,21 +220,22 @@
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.
The [HASHSIG] specification establishes an IANA registry to permit
 the registration of additional tree sizes in the future.
+ the registration of additional hash functions and additional tree
+ sizes in the future.
The LMS public key is the string consists of four elements: the
lms_algorithm_type from the list above, the otstype to identify the
LMOTS type as discussed in Section 2.3, the private key identifier
(I) as described in Section 5.3 of [HASHSIG], and the mbyte string
associated with the root node of the tree.
The LMS public key can be summarized as:
u32str(lms_algorithm_type)  u32str(otstype)  I  T[1]
@@ 459,23 +468,23 @@
[ASN1E] ITUT, "Information technology  ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITUT Recommendation X.690, 2015.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
.
 [HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "HashBased
 Signatures", Work in progress.

+ [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "LeightonMicali
+ HashBased Signatures", RFC 8554, April 2019,
+ .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, .
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
@@ 541,20 +550,22 @@
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, .
Appendix: ASN.1 Module
+
+
MTSHashSig2013
{ iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
idsmime(16) idmod(0) idmodmtshashsig2013(64) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLICKEY, SIGNATUREALGORITHM, SMIMECAPS
@@ 600,25 +612,27 @@

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

SMimeCaps SMIMECAPS ::=
{ saHSSLMSHashSig.&smimeCaps, ... }
END
+
+
Acknowledgements
 Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, Jim
 Schaad, Sean Turner, and Daniel Van Geest for their careful review
 and comments.
+ Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis,
+ John Mattsson, Jim Schaad, Sean Turner, and Daniel Van Geest for
+ their careful review and comments.
Author's Address
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
USA
EMail: housley@vigilsec.com