< draft-housley-cms-mts-hash-sig-02.txt		draft-housley-cms-mts-hash-sig-03.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Intended Status: Proposed Standard Vigil Security		Intended Status: Proposed Standard Vigil Security
	Expires: 30 September 2015 31 March 2015		Expires: 20 April 2016 18 October 2015
	Use of the Hash-based Merkle Tree Signature (MTS) Algorithm		Use of the Hash-based Merkle Tree Signature (MTS) Algorithm
	in the Cryptographic Message Syntax (CMS)		in the Cryptographic Message Syntax (CMS)
	<draft-housley-cms-mts-hash-sig-02>		<draft-housley-cms-mts-hash-sig-03>
	Abstract		Abstract
	This document specifies the conventions for using the Merkle Tree		This document specifies the conventions for using the Merkle Tree
	Signatures (MTS) digital signature algorithm with the Cryptographic		Signatures (MTS) digital signature algorithm with the Cryptographic
	Message Syntax (CMS). The MTS algorithm is one form of hash-based		Message Syntax (CMS). The MTS algorithm is one form of hash-based
	digital signature.		digital signature.
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. MTS Digital Signature Algorithm . . . . . . . . . . . . . 3		1.1. MTS Digital Signature Algorithm . . . . . . . . . . . . . 3
	1.2. LDWM One-time Signature Algorithm . . . . . . . . . . . . 4		1.2. LM-OTS One-time Signature Algorithm . . . . . . . . . . . 4
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 5		2. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 4
	3. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 6		3. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	4.1. Implementation Security Considerations . . . . . . . . . . 6		4.1. Implementation Security Considerations . . . . . . . . . . 6
	4.2. Algorithm Security Considerations . . . . . . . . . . . . 6		4.2. Algorithm Security Considerations . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 7		7. Informative References . . . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 8		Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	This document specifies the conventions for using the for using the		This document specifies the conventions for using the Merkle Tree
	Merkle Tree Signatures (MTS) digital signature algorithm with the		Signatures (MTS) digital signature algorithm with the Cryptographic
	Cryptographic Message Syntax (CMS) [CMS] signed-data content type.		Message Syntax (CMS) [CMS] signed-data content type. The MTS
	The MTS algorithm is one form of hash-based digital signature that		algorithm is one form of hash-based digital signature that can only
	can only be used for a specific number of signatures. The MTS		be used for a fixed number of signatures. The MTS algorithm is
	algorithm is described in [HASHSIG]. The MTS algorithm uses small		described in [HASHSIG]. The MTS algorithm uses small private and
	private and public keys, and it has low computational cost; however,		public keys, and it has low computational cost; however, the
	the signatures are quite large.		signatures are quite large.
	CMS values are generated using ASN.1 [ASN1-02], using the Basic		CMS values are generated using ASN.1 [ASN1-02], using the Basic
	Encoding Rules (BER) and the Distinguished Encoding Rules (DER).		Encoding Rules (BER) and the Distinguished Encoding Rules (DER).
	1.1. MTS Digital Signature Algorithm		1.1. MTS Digital Signature Algorithm
	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 uses two cryptographic		fixed number of messages. An MTS system is an N-time signature
	components: a one-time signature method and a collision-resistant		system, meaning that the private key can be used to generate at most
	hash function. Each MTS public/private key pair is associated with a		N signatures.
	k-way tree with each node containing an n-byte value. Each leaf of
	the tree contains the value of the public key of an Lamport, Diffie,
	Winternitz, and Merkle (LDWM) public/private key pair [HASHSIG]. The
	LDWM algorithm requires a robust one-way function to underpin the
	signature generation and verification. The algorithms in this
	document all make use of the SHA-256 [SHS] one-way hash function,
	which produces a 32 byte result.
	The value at the root of the tree is the MTS public key. Each
	interior node is computed by applying the hash function to the
	concatenation of the values of its children nodes. Once again, the
	algorithms in this document all make use of the SHA-256 [SHS] one-way
	hash function.
	An MTS signature consists of an LDWM signature, a node number that
	identifies the leaf node associated with the signature, and an array
	of values associated with the path through the tree from the LDWM
	signature leaf to the root. The array of values contains contains
	the siblings of 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 branching number k and height h will have (k-1)*h values. The
	first (k-1) values are the siblings of the leaf, the next (k-1)
	values are the siblings of the parent of the leaf, and so on.
	Four tree sizes are specified in [HASHSIG]:
	MTS_SHA256_K2_H20:
	o k = 2 (2 child nodes for each interior node),
	o h = 20 (20 levels in the tree),
	o n = 32 (32 bytes associated with each node), and
	o mts_algorithm_type = 0x00000001.
	MTS_SHA256_K4_H10:
	o k = 4 (4 child nodes for each interior node),
	o h = 10 (10 levels in the tree),
	o n = 32 (32 bytes associated with each node), and
	o mts_algorithm_type = 0x00000002.
	MTS_SHA256_K8_H7:
	o n = 8 (8 child nodes for each interior node),
	o h = 7 (7 levels in the tree), and
	o n = 32 (32 bytes associated with each node), and
	o mts_algorithm_type = 0x00000003.
	MTS_SHA256_K16_H5:
	o k = 16 (16 child nodes for each interior node),
	o h = 5 (5 levels in the tree),
	o n = 32 (32 bytes associated with each node), and
	o mts_algorithm_type = 0x00000004.
	There are k^h leaves in the tree.		An MTS system uses two cryptographic components: a one-time signature
			method and a collision-resistant hash function. Each MTS
			public/private key pair is associated with a k-way tree. Each leaf
			of the tree can be used to generate a one-time signature (OTS), which
			can be used to securely sign exactly one message, but cannot securely
			sign more than one.
	1.2. LDWM One-time Signature Algorithm		This specification makes use of the MTS algorithm specified in
			[HASHSIG], which is the Leighton and Micali adaptation [LM] of the
			original Lamport-Diffie-Winternitz-Merkle one-time signature system
			[M1979][M1987][M1989a][M1989b]. It makes use of the LM-OTS one-time
			signature scheme and the SHA-256 [SHS] one-way hash function.
	Merkle Tree Signatures (MTS) depend on a LDWM one-time signature		An LMS system has two parameters. The height of the tree, h, which
	method. The four variants described in [HASHSIG] depend on SHA-256		is the number of levels in the tree minus one. The [HASHSIG]
	[SHS] and SHA-256-20, which is the same as SHA-256, except that the		specification supports three values for this parameter: h=20; h=10;
	hash result is truncated to 20 bytes.		and h=5. The number of bytes associated with each node in the tree,
			n, is defined by the hash function. The [HASHSIG] specification
			supports two hash functions: SHA-256 [SHS], with n=32; and
			SHA-256-16, which is the same as SHA-256, except that the hash result
			is truncated to 16 bytes, with n=16. Note that there are 2^h leaves
			in the tree.
	Four LDWN one-time signature algorithms are defined in [HASHSIG]:		Six tree sizes are specified in [HASHSIG]:
			lms_sha256_n32_h20;
			lms_sha256_n32_h10;
			lms_sha256_n32_h5;
			lms_sha256_n16_h20;
			lms_sha256_n16_h10; and
			lms_sha256_n16_h5.
	LDWM_SHA256_M20_W1:		An LMS signature consists of three things: a typecode indicating the
	o ldwm_algorithm_type = 0x00000001; and		particular LMS algorithm, an LM-OTS signature, and an array of values
	o the signature value is the 4-byte ldwm_algorithm_type		that is associated with the path through the tree from the leaf
	followed by 265 20-byte values.		associated with the LM-OTS signature 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 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 is the sibling of the
			parent of the leaf, and so on up the path to the root.
	LDWM_SHA256_M20_W2:		1.2. LM-OTS One-time Signature Algorithm
	o ldwm_algorithm_type = 0x00000002; and
	o the signature value is the 4-byte ldwm_algorithm_type
	followed by 133 20-byte values.
	LDWM_SHA256_M20_W4:		Merkle Tree Signatures (MTS) depend on a LM-OTS one-time signature
	o ldwm_algorithm_type = 0x00000003; and		method. An LM-OTS has four parameters. The number of bytes
	o the signature value is the 4-byte ldwm_algorithm_type		associated with the has function, n, which is the same as the LMS
	followed by 67 20-byte values.		parameter. Again, the [HASHSIG] specification supports two hash
			functions: SHA-256 [SHS], with n=32; and SHA-256-16, with n=16. The
			the Winternitz parameter, w. The [HASHSIG] specification supports
			four values for this parameter: w=1; w=2; w=4; and w=8. The number
			of n-byte string elements that make up the LM-OTS signature, p. The
			number of left-shift bits used in the checksum function, ls. The
			values of p and ls are dependent on the choices of the parameters n
			and w, as described in Appendix A of [HASHSIG].
	LDWM_SHA256_M20_W8:		Eight LM-OTS variants are defined in [HASHSIG]:
	o ldwm_algorithm_type = 0x00000004; and		LMOTS_SHA256_N32_W1;
	o the signature value is the 4-byte ldwm_algorithm_type		LMOTS_SHA256_N32_W2;
	followed by 32 20-byte values.		LMOTS_SHA256_N32_W4;
			LMOTS_SHA256_N32_W8;
			LMOTS_SHA256_N16_W1;
			LMOTS_SHA256_N16_W2;
			LMOTS_SHA256_N16_W4; and
			LMOTS_SHA256_N16_W8.
	1.3. Terminology		1.3. 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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [KEYWORDS].		document are to be interpreted as described in RFC 2119 [KEYWORDS].
	2. Algorithm Identifiers and Parameters		2. Algorithm Identifiers and Parameters
	The algorithm identifier for an MTS signature is id-alg-mts-hashsig:		The algorithm identifier for an MTS signature is id-alg-mts-hashsig:
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 20 ¶
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
	id-alg OBJECT IDENTIFIER ::= { id-smime 3 }		id-alg OBJECT IDENTIFIER ::= { id-smime 3 }
	id-alg-mts-hashsig OBJECT IDENTIFIER ::= { id-alg 17 }		id-alg-mts-hashsig OBJECT IDENTIFIER ::= { id-alg 17 }
	When the id-alg-mts-hashsig algorithm identifier is used for a		When the id-alg-mts-hashsig algorithm identifier is used for a
	signature, the AlgorithmIdentifier parameters field MUST be absent.		signature, the AlgorithmIdentifier parameters field MUST be absent.
	The first 4 bytes of the signature value contains the		The first 4 bytes of the signature value contains the
	mts_algorithm_type as defined in Section 4.5 of [HASHSIG]. For		mls_algorithm_type as defined in Section 5.5 of [HASHSIG]. This type
	convenience, these values are repeated in above in Section 1.1 of		tells how to parse the remaining parts of the signature value, which
	this document. This value tells how to parse the remaining parts of		is composed of an LM-OTS signature and an array of values that is
	the signature value, which is composed of an LDWM signature value, a		associated with the path through the tree from the leaf associated
	4-byte signature leaf number, and the MTS path.		with the LM-OTS signature to the root.
	The first 4 bytes of the LDWM signature value contains the		The first 4 bytes of the LM-OTS signature value contains the
	ldwm_algorithm_type as defined in Section 3.10 of [HASHSIG]. For		ots_algorithm_type as defined in Section 4.10 of [HASHSIG]. This
	convenience, these values are repeated in above in Section 1.2 of		type is followed by n*p bytes of signature value.
	this document.
	The signature format is designed for easy parsing. Each format		The signature format is designed for easy parsing. Each format
	starts with a 4-byte enumeration value that indicates all of the		starts with a 4-byte enumeration value that indicates all of the
	details of the signature algorithm, indirectly providing all of the		details of the signature algorithm, indirectly providing all of the
	information that is needed to parse the value during signature		information that is needed to parse the value during signature
	validation.		validation.
	3. Signed-data Conventions		3. Signed-data Conventions
	digestAlgorithms SHOULD contain the one-way hash function used to		digestAlgorithms SHOULD contain the one-way hash function used to
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 6 ¶
	Further, the same one-way hash function SHOULD be used to compute the		Further, the same one-way hash function SHOULD be used to compute the
	message digest on both the eContent and the signedAttributes value if		message digest on both the eContent and the signedAttributes value if
	signedAttributes exist. Again, since the hash-based signature		signedAttributes exist. Again, since the hash-based signature
	algorithms all depend on SHA-256, it is strongly RECOMMENDED that		algorithms all depend on SHA-256, it is strongly RECOMMENDED that
	SHA-256 be used.		SHA-256 be used.
	signatureAlgorithm MUST contain id-alg-mts-hashsig. The algorithm		signatureAlgorithm MUST contain id-alg-mts-hashsig. The algorithm
	parameters field MUST be absent.		parameters field MUST be absent.
	signature contains the single value resulting from the signing		signature contains the single value resulting from the signing
	operation.		operation as specified in [HASHSIG].
	4. Security Considerations		4. Security Considerations
	4.1. Implementation Security Considerations		4.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. Further,		private keys may result in the ability to forge signatures. Along
	a LDWM private key MUST be used only one time, and the LDWM private		with the private key, the implementation must maintain a counter
	key MUST NOT be used for any other purpose.		value that indicates which leaf nodes in the tree have been used.
			Loss of integrity of this counter can cause an one-time key to be
			used more than once. As a result, when a private key and an
			associated counter value are stored on non-volatile media or stored
			in a virtual machine environment, care must be taken to preserve
			these properties.
			An implementation must ensure that a LDWM private key is used only
			one time, and ensure that the LDWM private key cannot be used 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. RFC 4086 [RANDOM] offers important
	guidance in this area.		guidance in this area.
	skipping to change at page 7, line 4 ¶		skipping to change at page 6, line 45 ¶
	When computing signatures, the same hash function SHOULD be used for		When computing signatures, the same hash function SHOULD be used for
	all operations. This reduces the number of failure points in the		all operations. This reduces the number of failure points in the
	signature process.		signature process.
	4.2. Algorithm Security Considerations		4.2. Algorithm Security Considerations
	At Black Hat USA 2013, some researchers gave a presentation on the		At Black Hat USA 2013, some researchers gave a presentation on the
	current sate of public key cryptography. They said: "Current		current sate of public key cryptography. They said: "Current
	cryptosystems depend on discrete logarithm and factoring which has		cryptosystems depend on discrete logarithm and factoring which has
	seen some major new developments in the past 6 months" [BH2013].		seen some major new developments in the past 6 months" [BH2013].
	They encouraged preparation for a day when RSA and DSA cannot be		They encouraged preparation for a day when RSA and DSA cannot be
	depended upon.		depended upon.
	A post-quantum cryptosystem is a system that is secure against		A post-quantum cryptosystem is a system that is secure against
	quantum computers that have more than a trivial number of quantum		quantum computers that have more than a trivial number of quantum
	bits. It is open to conjecture whether it is feasible to build such		bits. It is open to conjecture whether it is feasible to build such
	a machine. RSA, DSA, and ECDSA are not post-quantum secure.		a machine. RSA, DSA, and ECDSA are not post-quantum secure.
	The LDWM one-time signature and MTS system do not depend on discrete		The LM-OTP one-time signature and LMS do not depend on discrete
	logarithm or factoring, and these algorithms are considered to be		logarithm or factoring, and these algorithms are considered to be
	post-quantum secure.		post-quantum secure.
	Today, RSA is often used to digitally sign software updates. This		Today, RSA is often used to digitally sign software updates. This
	means that the distribution of software updates could be compromised		means that the distribution of software updates could be compromised
	if a significant advance is made in factoring or a quantum computer		if a significant advance is made in factoring or a quantum computer
	is invented. The use of MTS signatures to protect software update		is invented. The use of MTS signatures to protect software update
	distribution, perhaps using the format described in [FWPROT], will		distribution, perhaps using the format described in [FWPROT], will
	allow the deployment of software that implements new cryptosystems.		allow the deployment of software that implements new cryptosystems.
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 28 ¶
	{{ RFC Editor: Please remove this section prior to publication. }}		{{ RFC Editor: Please remove this section prior to publication. }}
	This document has no actions for IANA.		This document has no actions for IANA.
	6. Normative References		6. Normative References
	[ASN1-02] ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and		[ASN1-02] ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and
	X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.		X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, September 2009.		RFC 5652, DOI 10.17487/RFC5652, September 2009,
			<http://www.rfc-editor.org/info/rfc5652>.
	[HASHSIG] McGrew, D., and M. Curcio, "Hash-Based Signatures", Work		[HASHSIG] McGrew, D., and M. Curcio, "Hash-Based Signatures", Work
	in progress. <draft-mcgrew-hash-sigs-01>		in progress. <draft-mcgrew-hash-sigs-03>
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI
			10.17487/RFC2119, March 1997, <http://www.rfc-
			editor.org/info/rfc2119>.
	[SHS] National Institute of Standards and Technology (NIST),		[SHS] National Institute of Standards and Technology (NIST),
	FIPS Publication 180-3: Secure Hash Standard, October		FIPS Publication 180-3: Secure Hash Standard, October
	2008.		2008.
	7. Informative References		7. Informative References
	[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The		[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The
	Factoring Dead: Preparing for the Cryptopocalypse", August		Factoring Dead: Preparing for the Cryptopocalypse", August
	2013.		2013. <https://media.blackhat.com/us-13/us-13-Stamos-The-
	[https://media.blackhat.com/us-13/us-13-Stamos-The-		Factoring-Dead.pdf>
	Factoring-Dead.pdf]
	[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for		[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,		Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	June 2010.		DOI 10.17487/RFC5911, June 2010, <http://www.rfc-
			editor.org/info/rfc5911>.
	[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to		[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to
	Protect Firmware Packages", RFC 4108, August 2005.		Protect Firmware Packages", RFC 4108, DOI
			10.17487/RFC4108, August 2005, <http://www.rfc-
			editor.org/info/rfc4108>.
			[LM] Leighton, T. and S. Micali, "Large provably fast and
			secure digital signature schemes from secure hash
			functions", U.S. Patent 5,432,852, July 1995.
			[M1979] Merkle, R., "Secrecy, Authentication, and Public Key
			Systems", Stanford University Information Systems
			Laboratory Technical Report 1979-1, 1979.
			[M1987] Merkle, R., "A Digital Signature Based on a Conventional
			Encryption Function", Lecture Notes in Computer Science
			crypto87, 1988.
			[M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes
			in Computer Science crypto89, 1990.
			[M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes
			in Computer Science crypto89, 1990.
	[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,
	June 2010.		DOI 10.17487/RFC5912, June 2010, <http://www.rfc-
			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,		[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	June 2005.		DOI 10.17487/RFC4086, June 2005, <http://www.rfc-
			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) }
	DEFINITIONS EXPLICIT TAGS ::= BEGIN		DEFINITIONS EXPLICIT TAGS ::= BEGIN
	EXPORTS ALL;		EXPORTS ALL;
End of changes. 30 change blocks.
	121 lines changed or deleted		137 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/