draft-ietf-lamps-cms-hash-sig-01.txt   draft-ietf-lamps-cms-hash-sig-02.txt 
Internet Engineering Task Force (IETF) R. Housley INTERNET-DRAFT R. Housley
Intended Status: Proposed Standard Vigil Security Internet Engineering Task Force (IETF) Vigil Security
Expires: 27 March 2019 23 September 2018 Intended Status: Proposed Standard
Expires: 17 April 2019 17 October 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-01> <draft-ietf-lamps-cms-hash-sig-02>
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 31 skipping to change at page 2, line 31
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. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7
5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Implementation Security Considerations . . . . . . . . . . 8 6.1. Implementation Security Considerations . . . . . . . . . . 9
6.2. Algorithm Security Considerations . . . . . . . . . . . . 9 6.2. Algorithm Security Considerations . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 12 Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
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). The Hierarchical Signature System
built on top of the LMS system to efficiently scale for a larger (HSS) is built on top of the LMS system to efficiently scale for a
numbers of signatures. The HSS/LMS algorithm is one form of hash- larger numbers of signatures. The HSS/LMS algorithm is one form of
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 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].
skipping to change at page 4, line 12 skipping to change at page 4, line 12
permit the registration of additional one-way hash functions in the permit the registration of additional one-way hash functions in the
future. future.
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 specified in [HASHSIG] carries the An HSS signature as specified in [HASHSIG] carries the number of
number of signed public keys (Nspk), followed by that number of signed public keys (Nspk), followed by that number of signed public
signed public keys, followed by the LMS signature as described in keys, followed by the LMS signature as described in Section 2.2.
Section 2.2. Each signed public key is represented by the hash value Each signed public key is represented by the hash value at the root
at the root of the tree, and it also contains information about the of the tree, and it also contains information about the tree
tree structure. The signature over the public key is an LMS structure. The signature over the public key is an LMS signature as
signature as described in Section 2.2. 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 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 signed
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_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 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. 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
first parameter is the height of the tree, h, which is the number of first parameter is the height of the tree, h, which is the number of
levels in the tree minus one. The [HASHSIG] specification supports 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. 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 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 the number of bytes output by the hash function, m, which is the
of data associated with each node in the tree. The [HASHSIG] amount of data associated with each node in the tree. The [HASHSIG]
specification supports only the SHA-256 hash function [SHS], with specification supports only the SHA-256 hash function [SHS], with
m=32. m=32.
Currently, the [HASHSIG] specification supports five tree sizes: Currently, 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.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
of any length, and returns an n-byte string. of any length, and returns an n-byte string.
w - The width in bits of the Winternitz coefficients. [HASHSIG] w - The width in bits of the Winternitz coefficients. [HASHSIG]
supports four values for this parameter: w=1; w=2; w=4; and supports four values for this parameter: w=1; w=2; w=4; and
w=8. w=8.
p - The number of n-byte string elements that make up the LM-OTS p - The number of n-byte string elements that make up the LM-OTS
signature. signature.
ls - The number of left-shift bits used in the checksum function, ls - The number of left-shift 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 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 LM-OTS variants: Currently, the [HASHSIG] specification supports four LM-OTS variants:
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:
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 when
solely the id-alg-hss-lms-hashsig object identifier: 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 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) 17 } smime(16) alg(3) TBD }
When the id-alg-hss-lms-hashsig object identifier is used for a The algorithm identifier for an HSS/LMS hash-based signature when
signature, the AlgorithmIdentifier parameters field MUST be absent SHA-384 [SHS] is used to hash the content is the
(that is, the parameters are not present; the parameters are not set id-alg-hss-lms-hashsig-with-sha384 object identifier:
to NULL).
Note that the id-alg-hss-lms-hashsig algorithm identifier is also id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1)
referred to as id-alg-mts-hashsig. This synonym is based on the member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
terminology used in an early draft of the document that became smime(16) alg(3) TBD }
[HASHSIG].
The algorithm identifier for an HSS/LMS hash-based signature when
SHA-512 [SHS] is used to hash the content is the
id-alg-hss-lms-hashsig-with-sha512 object identifier:
id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1)
member-body(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 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
When using [HASHSIG], the algorithm identifier that is used to The AlgorithmIdentifier for an HHS/LMS public key uses the id-alg-
identify the signature value is also used to identify the HSS/LMS hss-lms-hashsig object identifier, and the parameters field MUST be
public key. The algorithm 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 identifier appears. In this situation, the one place where this algorithm identifier appears. In this
certificate key usage extension MAY contain digitalSignature, situation, the certificate key usage extension MAY contain
nonRepudiation, keyCertSign, and cRLSign; however, it MUST NOT digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however,
contain other values. it MUST NOT contain other values.
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
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
terminology used in an early draft of the document that became
[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 a length, L, followed it is designed for easy parsing. The value is the number of levels
by the public key itself. 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
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
skipping to change at page 8, line 9 skipping to change at page 8, line 31
THEN md = Hash(content) THEN md = Hash(content)
ELSE message-digest attribute = Hash(content); ELSE message-digest attribute = Hash(content);
md = Hash(DER(SignedAttributes)) md = Hash(DER(SignedAttributes))
Sign(md) Sign(md)
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. Since the compute the message digest on the eContent value. In
hash-based signature algorithms all depend on SHA-256, it is [HASHSIG], SHA-256 is used throughout the hash tree, and the
strongly RECOMMENDED that SHA-256 also be used to compute the hash computation includes a random string. This random data
message digest on the content. makes it harder for an attacker to find collisions. The signer
SHOULD use SHA-256 or a stronger hash function to compute the
message digest on the content. For
this purpose, Algorithm identifiers for SHA-256, SHA-384, and
SHA-512 are provided in 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. Again, signedAttributes value if signedAttributes are present.
since the hash-based signature algorithms all depend on
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-with-
algorithm parameters field MUST be absent. sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms-
hashsig-with-sha512. The 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].
6. Security Considerations 6. Security Considerations
6.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
skipping to change at page 9, line 9 skipping to change at page 9, line 37
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. RFC 4086 [RANDOM] offers important
guidance in this area. guidance 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 for When computing signatures, the same hash function SHOULD be used to
all operations. In this specification, only SHA-256 is used. Using compute the message digest of the content and the signed attributes,
only SHA-256 reduces the number of possible failure points in the if they are present.
signature process.
6.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.
skipping to change at page 10, line 14 skipping to change at page 10, line 35
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 at the top of 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)
registry, assign a new value for id-alg-hss-lms-hashsig-with-sha256
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 id-alg-hss-lms-hashsig-with-sha384
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 id-alg-hss-lms-hashsig-with-sha512
with a reference to this document.
8. Acknowledgements 8. Acknowledgements
Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel
Van Geest for their careful review and comments. 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
skipping to change at page 12, line 46 skipping to change at page 13, line 36
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
FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } id-mod-algorithmInformation-02(58) }
mda-sha256 mda-sha256, mda-sha384, mda-sha512
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) member-body(2) id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 17 }
id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) TBD }
id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) TBD }
id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) TBD }
-- --
-- Signature Algorithm and Public Key -- Signature Algorithm and Public Key
-- --
sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= { sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig 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 } } SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } }
sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig-with-sha384
PARAMS ARE absent
HASHES { mda-sha384 }
PUBLIC-KEYS { pk-HSS-LMS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } }
sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-hss-lms-hashsig-with-sha512
PARAMS ARE absent
HASHES { mda-sha512 }
PUBLIC-KEYS { pk-HSS-LMS-HashSig }
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
-- --
-- Expand the signature algorithm set used by CMS [CMSASN1U] -- Expand the signature algorithm set used by CMS [CMSASN1U]
-- --
SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
{ sa-HSS-LMS-HashSig, ... } { sa-HSS-LMS-HashSig-with-SHA256 |
sa-HSS-LMS-HashSig-with-SHA384 |
sa-HSS-LMS-HashSig-with-SHA512, ... }
-- --
-- Expand the S/MIME capabilities set used by CMS [CMSASN1] -- Expand the S/MIME capabilities set used by CMS [CMSASN1]
-- --
SMimeCaps SMIME-CAPS ::= { sa-HSS-LMS-HashSig.&smimeCaps, ... } SMimeCaps SMIME-CAPS ::=
{ sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps |
sa-HSS-LMS-HashSig-with-SHA384.&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 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
 End of changes. 35 change blocks. 
75 lines changed or deleted 140 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/