draft-ietf-lamps-cms-hash-sig-00.txt   draft-ietf-lamps-cms-hash-sig-01.txt 
INTERNET-DRAFT R. Housley Internet Engineering Task Force (IETF) R. Housley
Intended Status: Proposed Standard Vigil Security Intended Status: Proposed Standard Vigil Security
Expires: 4 March 2019 31 August 2018 Expires: 27 March 2019 23 September 2018
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-00> <draft-ietf-lamps-cms-hash-sig-01>
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). The HSS/LMS algorithm is one form of hash-based digital (CMS). The HSS/LMS algorithm is one form of hash-based digital
signature; it is described in [HASHSIG]. signature; it is described in [HASHSIG].
Status of this Memo Status of this Memo
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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
2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 3 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 3
2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4
2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 4 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 4
2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 5 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 5
3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6
4. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7
5.1. Implementation Security Considerations . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.2. Algorithm Security Considerations . . . . . . . . . . . . 8 6.1. Implementation Security Considerations . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2. Algorithm Security Considerations . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 12
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). A Hierarchical Signature System (HSS) Merkle Tree Signatures (MTS). A Hierarchical Signature System (HSS)
built on top of the LMS system to efficiently scale for a larger 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- numbers of signatures. The HSS/LMS algorithm is one form of hash-
skipping to change at page 4, line 30 skipping to change at page 4, line 30
The elements of the HSS signature value for a stand-alone tree can be The elements of the HSS signature value for a stand-alone tree can be
summarized as: summarized as:
u32str(0) || u32str(0) ||
lms_signature /* signature of message */ lms_signature /* signature of message */
The elements of the HSS signature value for a tree with Nspk levels The elements of the HSS signature value for a tree with Nspk levels
can be summarized as: can be summarized as:
u32str(Nspk) || u32str(Nspk) ||
signed_public_key[0] ||
signed_public_key[1] || signed_public_key[1] ||
signed_public_key[2] ||
... ...
sigend_public_key[Nspk-1] || signed_public_key[Nspk-2] ||
signed_public_key[Nspk] || signed_public_key[Nspk-1] ||
lms_signature_on_message lms_signature_on_message
where, as defined in Section 7 of [HASHSIG], a signed_public_key is where, as defined in Section 7 of [HASHSIG], a signed_public_key is
the lms_signature over the public key followed by the public key the lms_signature over the public key followed by the public key
itself. itself.
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
skipping to change at page 6, line 33 skipping to change at page 6, line 33
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 LM-OTS signature value can be summarized as:
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 signature is The algorithm identifier for an HSS/LMS hash-based signature is
id-alg-hss-lms-hashsig: solely the id-alg-hss-lms-hashsig object identifier:
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 the id-alg-hss-lms-hashsig algorithm identifier is used for a When the id-alg-hss-lms-hashsig object identifier is used for a
signature, the AlgorithmIdentifier parameters field MUST be absent signature, the AlgorithmIdentifier parameters field MUST be absent
(that is, the parameters are not present; the parameters are not set (that is, the parameters are not present; the parameters are not set
to NULL). to NULL).
Note that the id-alg-hss-lms-hashsig algorithm identifier is also 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 referred to as id-alg-mts-hashsig. This synonym is based on the
terminology used in an early draft of the document that became terminology used in an early draft of the document that became
[HASHSIG]. [HASHSIG].
The signature values is a large OCTET STRING. The signature format The signature values is a large OCTET STRING. The signature format
is designed for easy parsing. Each format includes a counter and is designed for easy parsing. Each format includes a counter and
type codes that indirectly providing all of the information that is type codes that indirectly providing all of the information that is
needed to parse the value during signature validation. needed to parse the value during signature validation.
4. Signed-data Conventions 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 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.
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
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.
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 As specified in [CMS], the digital signature is produced from the
message digest and the signer's private key. If signed attributes message digest and the signer's private key. If signed attributes
are absent, then the message digest is the hash of the content. If are absent, then the message digest is the hash of the content. If
signed attributes are present, then the hash of the content is placed signed attributes are present, then the hash of the content is placed
in the message-digest attribute, the set of signed attributes is DER in the message-digest attribute, the set of signed attributes is DER
encoded, and the message digest is the hash of the encoded encoded, and the message digest is the hash of the encoded
attributes. In summary: attributes. In summary:
IF (signed attributes are absent) IF (signed attributes are absent)
skipping to change at page 7, line 43 skipping to change at page 8, line 26
signedAttributes value if signedAttributes are present. Again, signedAttributes value if signedAttributes are present. Again,
since the hash-based signature algorithms all depend on since the hash-based signature algorithms all depend on
SHA-256, it is strongly RECOMMENDED that SHA-256 be used. SHA-256, it is strongly RECOMMENDED that SHA-256 be used.
signatureAlgorithm MUST contain id-alg-hss-lms-hashsig. The signatureAlgorithm MUST contain id-alg-hss-lms-hashsig. The
algorithm parameters field MUST be absent. algorithm parameters field MUST be absent.
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].
5. Security Considerations 6. Security Considerations
5.1. Implementation Security Considerations 6.1. Implementation 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 an one-time key to be used more than once.
As a result, when a private key and the tracking data are stored on As a result, when a private key and the tracking data are stored on
non-volatile media or stored in a virtual machine environment, care non-volatile media or stored in a virtual machine environment, care
must be taken to preserve confidentiality and integrity. must be taken to preserve confidentiality and integrity.
skipping to change at page 8, line 31 skipping to change at page 9, line 14
numbers. While the consequences of an inadequate pseudo-random numbers. While the consequences of an inadequate pseudo-random
number generator (PRNGs) to generate these values is much less severe number generator (PRNGs) to generate these values is much less severe
than the generation of private keys, the guidance in [RFC4086] than the generation of private keys, the guidance in [RFC4086]
remains important. remains important.
When computing signatures, the same hash function SHOULD be used for When computing signatures, the same hash function SHOULD be used for
all operations. In this specification, only SHA-256 is used. Using all operations. In this specification, only SHA-256 is used. Using
only SHA-256 reduces the number of possible failure points in the only SHA-256 reduces the number of possible failure points in the
signature process. signature process.
5.2. Algorithm Security Considerations 6.2. Algorithm Security Considerations
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 sate of public key cryptography. They said: "Current current sate 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].
They encouraged preparation for a day when RSA and DSA cannot be They encouraged preparation for a day when RSA and DSA cannot be
depended upon. depended upon.
A post-quantum cryptosystem is a system that is secure against A post-quantum cryptosystem is a system that is secure against
quantum computers that have more than a trivial number of quantum quantum computers that have more than a trivial number of quantum
bits. It is open to conjecture when it will be feasible to build bits. It is open to conjecture when it will be feasible to build
such a machine. RSA, DSA, and ECDSA are not post-quantum secure. such a machine. RSA, DSA, and ECDSA are not post-quantum secure.
The LM-OTP one-time signature, LMS, and HSS do not depend on discrete The LM-OTP one-time signature, LMS, and HSS do not depend on discrete
logarithm or factoring, as a result these algorithms are considered logarithm or factoring, as a result these algorithms are considered
to be post-quantum secure. to be post-quantum secure.
Hash-based signatures [HASHSIG] are currently defined to use
exclusively SHA-256. An IANA registry is defined to that other 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 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 quantum computer
is invented. The use of HSS/LMS hash-based signatures to protect is invented. The use of HSS/LMS hash-based signatures to protect
software update distribution, perhaps using the format described in software update distribution, perhaps using the format described in
[FWPROT], will allow the deployment of software that implements new [FWPROT], will allow the deployment of software that implements new
cryptosystems. cryptosystems.
6. IANA Considerations 7. IANA Considerations
SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) 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 registry, change the reference for value 64 to point to this
document. document.
In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)
registry, change the description for value 17 to registry, change the description for value 17 to
"id-alg-hss-lms-hashsig" and change the reference to point to this "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 at the top of the registry:
Value 17, "id-alg-hss-lms-hashsig", is also referred to as Value 17, "id-alg-hss-lms-hashsig", is also referred to as
"id-alg-mts-hashsig". "id-alg-mts-hashsig".
7. Acknowledgements 8. Acknowledgements
Many thanks to Panos Kampanakis, Jim Schaad, and Sean Turner for Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel
their careful review and comments. Van Geest for their careful review and comments.
8. Normative References 9. References
9.1. Normative References
[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, 2015. Recommendation X.680, 2015.
[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.
skipping to change at page 10, line 5 skipping to change at page 11, line 5
[HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based [HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based
Signatures", Work in progress. Signatures", Work in progress.
<draft-mcgrew-hash-sigs-12> <draft-mcgrew-hash-sigs-12>
[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate [RFC2219] 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.,
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,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, DOI RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017, <https://www.rfc- 10.17487/RFC8174, May 2017, <https://www.rfc-
editor.org/info/rfc8174>. editor.org/info/rfc8174>.
[SHS] National Institute of Standards and Technology (NIST), [SHS] National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard, October FIPS Publication 180-3: Secure Hash Standard, October
2008. 2008.
9. Informative References 9.2. Informative References
[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The [BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The
Factoring Dead: Preparing for the Cryptopocalypse", August Factoring Dead: Preparing for the Cryptopocalypse", August
2013. <https://media.blackhat.com/us-13/us-13-Stamos-The- 2013. <https://media.blackhat.com/us-13/us-13-Stamos-The-
Factoring-Dead.pdf> Factoring-Dead.pdf>
[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for [CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010, <http://www.rfc- DOI 10.17487/RFC5911, June 2010, <http://www.rfc-
editor.org/info/rfc5911>. editor.org/info/rfc5911>.
 End of changes. 20 change blocks. 
28 lines changed or deleted 76 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/