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/