draft-ietf-lamps-cms-hash-sig-07.txt   draft-ietf-lamps-cms-hash-sig-08.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: 6 September 2019 6 March 2019 Expires: 11 November 2019 10 May 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-07> <draft-ietf-lamps-cms-hash-sig-08>
Abstract Abstract
This document specifies the conventions for using the the HSS/LMS This document specifies the conventions for using the the HSS/LMS
hash-based signature algorithm with the Cryptographic Message Syntax hash-based signature algorithm with the Cryptographic Message Syntax
(CMS). In addition, the algorithm identifier and public key syntax (CMS). In addition, the algorithm identifier and public key syntax
are provided. The HSS/LMS algorithm is one form of hash-based are provided. The HSS/LMS algorithm is one form of hash-based
digital signature; it is described in [HASHSIG]. 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 32 skipping to change at page 2, line 32
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. Algorithm Considerations . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 8 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
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 HSS/LMS hash-
based signature algorithm with the Cryptographic Message Syntax (CMS) based signature algorithm with the Cryptographic Message Syntax (CMS)
[CMS] signed-data content type. The Leighton-Micali Signature (LMS) [CMS] signed-data content type. The Leighton-Micali Signature (LMS)
system provides a one-time digital signature that is a variant of system provides a one-time digital signature that is a variant of
Merkle Tree Signatures (MTS). The Hierarchical Signature System Merkle Tree Signatures (MTS). The Hierarchical Signature System
(HSS) is built on top of the LMS system to efficiently scale for a (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 larger numbers of signatures. The HSS/LMS algorithm is one form of
hash-based digital signature, and it is described in [HASHSIG]. The hash-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.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
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. 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 At Black Hat USA 2013, some researchers gave a presentation on the
current state of public key cryptography. They said: "Current current state of public key cryptography. They said: "Current
cryptosystems depend on discrete logarithm and factoring which has cryptosystems depend on discrete logarithm and factoring which has
seen some major new developments in the past 6 months" [BH2013]. seen some major new developments in the past 6 months" [BH2013]. Due
They encouraged preparation for a day when RSA and DSA cannot be to advances in cryptanalysis, they encouraged preparation for a day
depended upon. when RSA and DSA cannot be depended upon.
A post-quantum cryptosystem [PQC] is a system that is secure against If large-scale quantum computers are ever built, these computers will
quantum computers that have more than a trivial number of quantum be able to break many of the public-key cryptosystems currently in
bits. It is open to conjecture when it will be feasible to build use. A post-quantum cryptosystem [PQC] is a system that is secure
such a machine. RSA, DSA, and ECDSA are not post-quantum secure. against quantum computers that have more than a trivial number of
quantum bits (qu-bits). It is open to conjecture when it will be
feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA
are all vulnerable if large-scale quantum computers come to pass.
The LM-OTS one-time signature, LMS, and HSS do not depend on discrete The HSS/LMS signature algorithm does not depend on the difficulty of
logarithm or factoring, as a result these algorithms are considered discrete logarithm or factoring, as a result these algorithms are
to be post-quantum secure. considered to be post-quantum secure.
Hash-based signatures [HASHSIG] are currently defined to use Hash-based signatures [HASHSIG] are currently defined to use
exclusively SHA-256 [SHS]. An IANA registry is defined so that other exclusively SHA-256 [SHS]. An IANA registry is defined so that other
hash functions could be used in the future. LM-OTS signature hash functions could be used in the future. LM-OTS signature
generation prepends a random string as well as other metadata before generation prepends a random string as well as other metadata before
computing the hash value. The inclusion of the random value reduces computing the hash value. The inclusion of the random value reduces
the chances of an attacker being able to find collisions, even if the the chances of an attacker being able to find collisions, even if the
attacker has a large-scale quantum computer. attacker has a large-scale quantum computer.
Today, RSA is often used to digitally sign software updates. This Today, RSA is often used to digitally sign software updates. This
means that the distribution of software updates could be compromised means that the distribution of software updates could be compromised
if a significant advance is made in factoring or a quantum computer if a significant advance is made in factoring or a large-scale
is invented. The use of HSS/LMS hash-based signatures to protect quantum computer is invented. The use of HSS/LMS hash-based
software update distribution, perhaps using the format described in signatures to protect software update distribution, perhaps using the
[FWPROT], will allow the deployment of software that implements new format described in [FWPROT], will allow the deployment of software
cryptosystems. 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
skipping to change at page 6, line 6 skipping to change at page 6, line 14
The [HASHSIG] specification supports five tree sizes: 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 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 The LMS public key is the string consists of four elements: the
lms_algorithm_type from the list above, the otstype to identify the lms_algorithm_type from the list above, the otstype to identify the
LM-OTS type as discussed in Section 2.3, the private key identifier LM-OTS type as discussed in Section 2.3, the private key identifier
(I) as described in Section 5.3 of [HASHSIG], and the m-byte string (I) as described in Section 5.3 of [HASHSIG], and the m-byte string
associated with the root node of the tree. associated with the root node of the tree.
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]
skipping to change at page 11, line 14 skipping to change at page 11, line 27
[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: [ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, 2015.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Signatures", Work in progress. Hash-Based Signatures", RFC 8554, April 2019,
<draft-mcgrew-hash-sigs-12> <https://rfc-editor.org/rfc/rfc8554.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc- 10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 13, line 7 skipping to change at page 13, line 17
<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>
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <http://www.rfc- DOI 10.17487/RFC4086, June 2005, <http://www.rfc-
editor.org/info/rfc4086>. editor.org/info/rfc4086>.
Appendix: ASN.1 Module Appendix: ASN.1 Module
<CODE STARTS>
MTS-HashSig-2013 MTS-HashSig-2013
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
skipping to change at page 14, line 20 skipping to change at page 14, line 30
-- --
-- Expand the S/MIME capabilities set used by CMS [CMSASN1] -- Expand the S/MIME capabilities set used by CMS [CMSASN1]
-- --
SMimeCaps SMIME-CAPS ::= SMimeCaps SMIME-CAPS ::=
{ sa-HSS-LMS-HashSig.&smimeCaps, ... } { sa-HSS-LMS-HashSig.&smimeCaps, ... }
END END
<CODE ENDS>
Acknowledgements Acknowledgements
Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, Jim Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis,
Schaad, Sean Turner, and Daniel Van Geest for their careful review John Mattsson, Jim Schaad, Sean Turner, and Daniel Van Geest for
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
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 16 change blocks. 
31 lines changed or deleted 43 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/