draft-ietf-lamps-cms-hash-sig-03.txt   draft-ietf-lamps-cms-hash-sig-04.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: 20 June 2019 20 December 2018 Expires: 12 August 2019 12 February 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-03> <draft-ietf-lamps-cms-hash-sig-04>
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). In addition, the algorithm identifier and public key syntax
signature; it is described in [HASHSIG]. are provided. The HSS/LMS algorithm is one form of hash-based
digital signature; it is described in [HASHSIG].
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 3, line 16 skipping to change at page 3, line 16
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 HSS/LMS signature algorithm uses small signing operations. The number of signing operations depends upon
the size of the tree. The HSS/LMS signature algorithm uses small
private and public keys, and it has low computational cost; however, private and public keys, and it has low computational cost; however,
the signatures are quite large. the signatures are quite large.
1.1. ASN.1 1.1. ASN.1
CMS values are generated using ASN.1 [ASN1-B], using the Basic CMS values are generated using ASN.1 [ASN1-B], using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[ASN1-E]. [ASN1-E].
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
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.
A post-quantum cryptosystem 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 post-quantum secure.
The LM-OTS one-time signature, LMS, and HSS do not depend on discrete
logarithm or factoring, as a result these algorithms are considered
to be post-quantum secure.
Hash-based signatures [HASHSIG] are currently defined to use
exclusively SHA-256. An IANA registry is defined so 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
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 hash-based 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 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
[M1979][M1987][M1989a][M1989b]. [M1979][M1987][M1989a][M1989b].
skipping to change at page 4, line 14 skipping to change at page 4, line 48
2.1. Hierarchical Signature System (HSS) 2.1. Hierarchical Signature System (HSS)
The MTS system specified in [HASHSIG] uses a hierarchy of trees. The The MTS system specified in [HASHSIG] uses a hierarchy of trees. The
Hierarchical N-time Signature System (HSS) allows subordinate trees Hierarchical N-time Signature System (HSS) allows subordinate trees
to be generated when needed by the signer. Otherwise, generation of to be generated when needed by the signer. Otherwise, generation of
the entire tree might take weeks or longer. the entire tree might take weeks or longer.
An HSS signature as specified in [HASHSIG] carries the number of An HSS signature as specified in [HASHSIG] carries the number of
signed public keys (Nspk), followed by that number of signed public signed public keys (Nspk), followed by that number of signed public
keys, followed by the LMS signature as described in Section 2.2. keys, followed by the LMS signature as described in Section 2.2. The
Each signed public key is represented by the hash value at the root public key for the top-most LMS tree is the public key of the HSS
of the tree, and it also contains information about the tree system. The LMS private key in the parent tree signs the LMS public
structure. The signature over the public key is an LMS signature as key in the child tree, and the LMS private key in the bottom-most
described in Section 2.2. tree signs the actual message. The signature over the public key and
the signature over the actual message are LMS signatures as described
in Section 2.2.
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 (a top
summarized as: tree with no children) can be 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 signed The elements of the HSS signature value for a tree with Nspk signed
public keys can be summarized as: public keys can be summarized as:
u32str(Nspk) || u32str(Nspk) ||
signed_public_key[0] || signed_public_key[0] ||
signed_public_key[1] || signed_public_key[1] ||
... ...
signed_public_key[Nspk-2] || signed_public_key[Nspk-2] ||
signed_public_key[Nspk-1] || signed_public_key[Nspk-1] ||
lms_signature_on_message lms_signature /* signature of message */
where, as defined in Section 3.3 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 the lms_signature over the public key followed by the public key
itself. Note that Nspk is the number of levels in the hierarchy of itself. Note that Nspk is the number of levels in the hierarchy of
trees minus 1. trees minus 1.
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 5, line 18 skipping to change at page 6, line 5
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 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
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
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]
An LMS signature consists of four elements: the number of the leaf An LMS signature consists of four elements: the number of the leaf
associated with the LM-OTS signature, an LM-OTS signature as (q) associated with the LM-OTS signature, an LM-OTS signature as
described in Section 2.3, a typecode indicating the particular LMS described in Section 2.3, a typecode indicating the particular LMS
algorithm, and an array of values that is associated with the path algorithm, and an array of values that is associated with the path
through the tree from the leaf associated with the LM-OTS signature through the tree from the leaf associated with the LM-OTS signature
to the root. The array of values contains the siblings of the nodes to the root. The array of values contains the siblings of the nodes
on the path from the leaf to the root but does not contain the nodes on the path from the leaf to the root but does not contain the nodes
on the path itself. The array for a tree with height h will have h on the path itself. The array for a tree with height h will have h
values. The first value is the sibling of the leaf, the next value values. The first value is the sibling of the leaf, the next value
is the sibling of the parent of the leaf, and so on up the path to is the sibling of the parent of the leaf, and so on up the path to
the root. the root.
skipping to change at page 6, line 26 skipping to change at page 7, line 23
LMOTS_SHA256_N32_W1; LMOTS_SHA256_N32_W1;
LMOTS_SHA256_N32_W2; LMOTS_SHA256_N32_W2;
LMOTS_SHA256_N32_W4; and LMOTS_SHA256_N32_W4; and
LMOTS_SHA256_N32_W8. LMOTS_SHA256_N32_W8.
The [HASHSIG] specification establishes an IANA registry to permit The [HASHSIG] specification establishes an IANA registry to permit
the registration of additional variants in the future. the registration of additional variants in the future.
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 the identifier of the
LM-OTS variant, the random value, and a sequence of hash values that
correspond to the elements of the public key as described in Section
4.5 of [HASHSIG]:
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 when The algorithm identifier for an HSS/LMS hash-based signature when
SHA-256 [SHS] is used to hash the content is the 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-with-sha256 object identifier:
id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1) id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
skipping to change at page 7, line 24 skipping to change at page 8, line 21
AlgorithmIdentifier parameters field MUST be absent (that is, the AlgorithmIdentifier parameters field MUST be absent (that is, the
parameters are not present; the parameters are not set to NULL). parameters are not present; the parameters are not set to NULL).
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. HSS/LMS Public Key Identifier 4. HSS/LMS Public Key Identifier
The AlgorithmIdentifier for an HHS/LMS public key uses the id-alg- The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-
hss-lms-hashsig object identifier, and the parameters field MUST be hss-lms-hashsig object identifier, and the parameters field MUST be
absent. absent.
The SubjectPublicKeyInfo field of an X.509 certificate [RFC5280] is The SubjectPublicKeyInfo field of an X.509 certificate [RFC5280] is
one place where this algorithm identifier appears. In this one place where this algorithm identifier appears. In this
situation, the certificate key usage extension MAY contain situation, the certificate key usage extension MAY contain
digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however, digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however,
it MUST NOT contain other values. it MUST NOT contain other values.
pk-HSS-LMS-HashSig PUBLIC-KEY ::= { pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
skipping to change at page 8, line 7 skipping to change at page 8, line 51
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 public key value is an OCTET STRING. Like the signature format, The public key value is an OCTET STRING. Like the signature format,
it is designed for easy parsing. The value is the number of levels it is designed for easy parsing. The value is the number of levels
in the public key, L, followed by the LMS public key. in the public key, L, followed by the LMS public key.
The HSS/LMS public key value can be summarized as: The HSS/LMS public key value can be summarized as:
u32str(L) || u32str(L) || lms_public_key
lms_public_key
Note that the public key for the top-most LMS tree is the public key
of the HSS system, and when L=1 it is a stand-alone tree.
5. Signed-data Conventions 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:
skipping to change at page 8, line 36 skipping to change at page 9, line 34
When using [HASHSIG], the fields in the SignerInfo are used as When using [HASHSIG], the fields in the SignerInfo are used as
follows: follows:
digestAlgorithms SHOULD contain the one-way hash function used to digestAlgorithms SHOULD contain the one-way hash function used to
compute the message digest on the eContent value. In compute the message digest on the eContent value. In
[HASHSIG], SHA-256 is used throughout the hash tree, and the [HASHSIG], SHA-256 is used throughout the hash tree, and the
hash computation includes a random string. This random data hash computation includes a random string. This random data
makes it harder for an attacker to find collisions. The signer makes it harder for an attacker to find collisions. The signer
SHOULD use SHA-256 or a stronger hash function to compute the SHOULD use SHA-256 or a stronger hash function to compute the
message digest on the content. For message digest on the content. For this purpose, Algorithm
this purpose, Algorithm identifiers for SHA-256, SHA-384, and identifiers for SHA-256, SHA-384, and SHA-512 are provided in
SHA-512 are provided in this document. this document.
Further, the same one-way hash function SHOULD be used to Further, the same one-way hash function SHOULD be used to
compute the message digest on both the eContent and the compute the message digest on both the eContent and the
signedAttributes value if signedAttributes are present. signedAttributes value if signedAttributes are present.
signatureAlgorithm MUST contain id-alg-hss-lms-hashsig-with- signatureAlgorithm MUST contain id-alg-hss-lms-hashsig-with-
sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms- sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms-
hashsig-with-sha512. The algorithm parameters field MUST be hashsig-with-sha512. The algorithm parameters field MUST be
absent. 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].
6. Security Considerations 6. 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.
When a LMS key pair is generating a LMS key pair, an implementation When generating a LMS key pair, an implementation MUST generate each
must must generate the key pair and the corresponding identifier key pair independently of all other key pairs in the HSS tree.
independently of all other key pairs in the HSS tree.
An implementation must ensure that a LM-OTS private key is used to An implementation MUST ensure that a LM-OTS private key is used to
generate a signature only one time, and ensure that it cannot be used generate a signature only one time, and ensure that it cannot be used
for any other purpose. for any other purpose.
The generation of private keys relies on random numbers. The use of The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these inadequate pseudo-random number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities, rather than brute
force searching the whole key space. The generation of quality force searching the whole key space. The generation of quality
random numbers is difficult. RFC 4086 [RANDOM] offers important random numbers is difficult, and [RFC4086] offers important guidance
guidance in this area. in this area.
The generation of hash-based signatures also depends on random The generation of hash-based signatures also depends on random
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 to When computing signatures, the same hash function SHOULD be used to
compute the message digest of the content and the signed attributes, compute the message digest of the content and the signed attributes,
if they are present. 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.
A post-quantum cryptosystem 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 post-quantum secure.
The LM-OTP one-time signature, LMS, and HSS do not depend on discrete
logarithm or factoring, as a result these algorithms are considered
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
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 hash-based signatures to protect
software update distribution, perhaps using the format described in
[FWPROT], will allow the deployment of software that implements new
cryptosystems.
7. 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 to the registry: document.
Also, add the following note to 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".
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, assign a new value for id-alg-hss-lms-hashsig-with-sha256 registry, assign a new value for id-alg-hss-lms-hashsig-with-sha256
with a reference to this document. with a reference to this 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, assign a new value for id-alg-hss-lms-hashsig-with-sha384 registry, assign a new value for id-alg-hss-lms-hashsig-with-sha384
with a reference to this document. with a reference to this 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, assign a new value for id-alg-hss-lms-hashsig-with-sha512 registry, assign a new value for id-alg-hss-lms-hashsig-with-sha512
with a reference to this document. with a reference to this document.
8. Acknowledgements 8. Acknowledgements
Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, Jim
Van Geest for their careful review and comments. Schaad, Sean Turner, and Daniel Van Geest for their careful review
and comments.
9. References 9. References
9.1. Normative 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:
skipping to change at page 11, line 35 skipping to change at page 12, line 5
(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., 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 [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,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 13, line 15 skipping to change at page 13, line 29
[PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, <http://www.rfc- DOI 10.17487/RFC5912, June 2010, <http://www.rfc-
editor.org/info/rfc5912>. editor.org/info/rfc5912>.
[PQC] Bernstein, D., "Introduction to post-quantum [PQC] Bernstein, D., "Introduction to post-quantum
cryptography", 2009. cryptography", 2009.
<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>
[RANDOM] 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
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) }
skipping to change at page 14, line 10 skipping to change at page 14, line 32
FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1] FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1]
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) } ; id-mod-pkix1-rsa-pkalgs-02(54) } ;
-- --
-- Object Identifiers -- Object Identifiers
-- --
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 }
id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig
id-alg-hss-lms-hashsig-with-sha256 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) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) TBD } smime(16) alg(3) TBD }
id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1) id-alg-hss-lms-hashsig-with-sha384 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) TBD } smime(16) alg(3) TBD }
id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1) id-alg-hss-lms-hashsig-with-sha512 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) TBD } smime(16) alg(3) TBD }
-- --
-- Signature Algorithm and Public Key -- Signature Algorithm and Public Key
-- --
sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= { sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig-with-sha256 IDENTIFIER id-alg-hss-lms-hashsig-with-sha256
PARAMS ARE absent PARAMS ARE absent
HASHES { mda-sha256 } HASHES { mda-sha256 }
PUBLIC-KEYS { pk-HSS-LMS-HashSig } PUBLIC-KEYS { pk-HSS-LMS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } } SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } }
sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= { sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig-with-sha384 IDENTIFIER id-alg-hss-lms-hashsig-with-sha384
PARAMS ARE absent PARAMS ARE absent
HASHES { mda-sha384 } HASHES { mda-sha384 }
PUBLIC-KEYS { pk-HSS-LMS-HashSig } PUBLIC-KEYS { pk-HSS-LMS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } } SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } }
sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= { sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig-with-sha512 IDENTIFIER id-alg-hss-lms-hashsig-with-sha512
PARAMS ARE absent PARAMS ARE absent
HASHES { mda-sha512 } HASHES { mda-sha512 }
PUBLIC-KEYS { pk-HSS-LMS-HashSig } PUBLIC-KEYS { pk-HSS-LMS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } } SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } }
pk-HSS-LMS-HashSig PUBLIC-KEY ::= { pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-hss-lms-hashsig IDENTIFIER id-alg-hss-lms-hashsig
KEY HSS-LMS-HashSig-PublicKey KEY HSS-LMS-HashSig-PublicKey
PARAMS ARE absent PARAMS ARE absent
CERT-KEY-USAGE CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } } { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSS-LMS-HashSig-PublicKey ::= OCTET STRING HSS-LMS-HashSig-PublicKey ::= OCTET STRING
skipping to change at page 16, line 9 skipping to change at page 16, line 20
{ sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps | { sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps |
sa-HSS-LMS-HashSig-with-SHA384.&smimeCaps | sa-HSS-LMS-HashSig-with-SHA384.&smimeCaps |
sa-HSS-LMS-HashSig-with-SHA512.&smimeCaps, ... } sa-HSS-LMS-HashSig-with-SHA512.&smimeCaps, ... }
END END
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 32 change blocks. 
94 lines changed or deleted 115 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/