< draft-housley-cms-mts-hash-sig-05.txt		draft-housley-cms-mts-hash-sig-06.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Intended Status: Proposed Standard Vigil Security		Intended Status: Proposed Standard Vigil Security
	Expires: 22 June 2017 19 December 2016		Expires: 2 September 2017 2 March 2017
	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-05>		<draft-housley-cms-mts-hash-sig-06>
	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 7 ¶		skipping to change at page 2, line 7 ¶
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	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", "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. MTS Digital Signature Algorithm Overview		2. MTS Digital 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. An MTS		signature method and a collision-resistant hash function.
	system is an N-time signature system, meaning that the private key
	can be used to generate at most N signatures.
	This specification makes use of the MTS algorithm specified in		This specification makes use of the MTS 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]. It makes use of the LM-OTS one-time		[M1979][M1987][M1989a][M1989b]. It makes use of the LM-OTS one-time
	signature scheme and the SHA-256 one-way hash function [SHS].		signature scheme and the SHA-256 one-way hash function [SHS].
	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 they are needed by the signer. Otherwise,		to be generated when needed by the signer. Otherwise, generation of
	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 specified in [HASHSIG] carries the
	number of levels minus one, followed by that number of signed public		number of signed public keys (Nspk), followed by that number of
	keys, followed by the LMS signature as described in Section 2.2.		signed public keys, followed by the LMS signature as described in
	Each signed public key is represented by the hash value at the root		Section 2.2. Each signed public key is represented by the hash value
	of the tree, and the signature over that public key is an LMS		at the root of the tree, and the signature over that public key is an
	signature as described in Section 2.2.		LMS signature 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 can be
	summarized as:		summarized as:
	u32str(0) ||		u32str(0) ||
	lms_signature_on_message		lms_signature_on_message
	The elements of the HSS signature value for a tree with L levels can		The elements of the HSS signature value for a tree with Nspk levels
	be summarized as:		can be summarized as:
	u32str(L-1) ||		u32str(Nspk) ||
	lms_signature_on_public_key[0] || public_key[1] ||		lms_signature_on_public_key[0] || public_key[1] ||
	lms_signature_on_public_key[1] || public_key[2] ||		lms_signature_on_public_key[1] || public_key[2] ||
	...		...
	lms_signature_on_public_key[L-2] || public_key[L-1] ||		lms_signature_on_public_key[Nspk-2] || public_key[Nspk-1] ||
			lms_signature_on_public_key[Nspk-1] || public_key[Nspk] ||
	lms_signature_on_message		lms_signature_on_message
	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
	four values for this parameter: h=20; h=15; h=10; and h=5. Note that		five values for this parameter: h=5; h=10; h=15; h=20; and h=24.
	there are 2^h leaves in the tree. The second parameter is the number		Note that there are 2^h leaves in the tree. The second parameter is
	of bytes output by the hash function, n, which the amount of data		the number of bytes output by the hash function, n, which the amount
	associated with each node in the tree. The [HASHSIG] specification		of data associated with each node in the tree. The [HASHSIG]
	supports only the SHA-256 hash function [SHS], with n=32.		specification supports only the SHA-256 hash function [SHS], with
			n=32.
	Four tree sizes are specified in [HASHSIG]:		Five tree sizes are specified in [HASHSIG]:
	LMS_SHA256_M32_H20;		LMS_SHA256_M32_H5;
	LMS_SHA256_M32_H15		LMS_SHA256_M32_H10;
	LMS_SHA256_M32_H10; and		LMS_SHA256_M32_H15;
	LMS_SHA256_M32_H5.		LMS_SHA256_M32_H20; and
			LMS_SHA256_M32_H24.
	An LMS signature consists of four elements: a typecode indicating the		An LMS signature consists of four elements: a typecode indicating the
	particular LMS algorithm, the number of the leaf associated with the		particular LMS algorithm, the number of the leaf associated with the
	LM-OTS signature, an LM-OTS signature as described in Section 2.3,		LM-OTS signature, an LM-OTS signature as described in Section 2.3,
	and an array of values that is associated with the path through the		and an array of values that is associated with the path through the
	tree from the leaf associated with the LM-OTS signature to the root.		tree from the leaf associated with the LM-OTS signature to the root.
	The array of values contains the siblings of the nodes on the path		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 values. The		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		first value is the sibling of the leaf, the next value is the sibling
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	The four elements of the LMS signature value can be summarized as:		The four elements of the LMS signature value can be summarized as:
	u32str(type) ||		u32str(type) ||
	u32str(q) ||		u32str(q) ||
	ots_signature ||		ots_signature ||
	path[0] || path[1] || ... || path[h-1]		path[0] || path[1] || ... || path[h-1]
	2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)		2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)
	Merkle Tree Signatures (MTS) depend on a LM-OTS one-time signature		Merkle Tree Signatures (MTS) depend on a one-time signature method.
	method. An LM-OTS has four parameters.		[HASHSIG] specifies the use of the LM-OTS. An LM-OTS has five
			parameters.
	n - The number of bytes associated with the hash function, which		n - The number of bytes associated with the hash function, which
	is the same as the LMS parameter. The [HASHSIG]		is the same as the LMS parameter. [HASHSIG] supports only
	specification supports only one hash function: SHA-256 [SHS],		SHA-256 [SHS], with n=32.
	with n=32.
	w - The width in bits of the Winternitz coefficients. The		H - A preimage-resistant hash function that accepts byte strings
	[HASHSIG] specification supports four values for this		of any length, and returns an n-byte string.
	parameter: w=1; w=2; w=4; and w=8.
			w - The width in bits of the Winternitz coefficients. [HASHSIG]
			supports four values for this parameter: w=1; w=2; w=4; and
			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.
	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 A of [HASHSIG].
	Four LM-OTS variants are defined in [HASHSIG]:		Four LM-OTS variants are defined in [HASHSIG]:
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	u32str(type) || C || y[0] || ... || y[p-1]		u32str(type) || C || y[0] || ... || y[p-1]
	3. Algorithm Identifiers and Parameters		3. 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:
	id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 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
			(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. The first 4		needed to parse the value during signature validation. The first 4
	octets of the signature value contains a count of levels minus one in		octets of the signature value contains the number of signed public
	the HSS. The first 4 octets of each LMS signature value contains		keys (Nspk) in the HSS. The first 4 octets of each LMS signature
	type code, which tells how to parse the remaining parts of the		value contains type code, which tells how to parse the remaining
	signature value. The first 4 octets of each LM-OTS signature value		parts of the signature value. The first 4 octets of each LM-OTS
	contains type code, which tells how to parse the remaining parts of		signature value contains type code, which tells how to parse the
	the signature value.		remaining parts of the signature value.
	4. Signed-data Conventions		4. Signed-data Conventions
	digestAlgorithms SHOULD contain the one-way hash function used to		As specified in [CMS], the digital signature is produced from the
	compute the message digest on the eContent value. Since the hash-		message digest and the signer's private key. If signed attributes
	based signature algorithms all depend on SHA-256, it is strongly		are absent, then the message digest is the hash of the content. If
	RECOMMENDED that SHA-256 also be used to compute the message digest		signed attributes are present, then the hash of the content is placed
	on the content.		in the message-digest attribute, the set of signed attributes is DER
			encoded, and the message digest is the hash of the encoded
			attributes. In summary:
	Further, the same one-way hash function SHOULD be used to compute the		IF (signed attributes are absent)
	message digest on both the eContent and the signedAttributes value if		THEN md = Hash(content)
	signedAttributes are present. Again, since the hash-based signature		ELSE message-digest attribute = Hash(content);
	algorithms all depend on SHA-256, it is strongly RECOMMENDED that		md = Hash(DER(SignedAttributes))
	SHA-256 be used.
	signatureAlgorithm MUST contain id-alg-mts-hashsig. The algorithm		Sign(md)
	parameters field MUST be absent.
	signature contains the single HSS signature value resulting from the		When using [HASHSIG], the fields in the SignerInfo are used as
	signing operation as specified in [HASHSIG].		follows:
			digestAlgorithms SHOULD contain the one-way hash function used to
			compute the message digest on the eContent value. Since the
			hash-based signature algorithms all depend on SHA-256, it is
			strongly RECOMMENDED that SHA-256 also be used to compute the
			message digest on the content.
			Further, the same one-way hash function SHOULD be used to
			compute the message digest on both the eContent and the
			signedAttributes value if signedAttributes are present. Again,
			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-mts-hashsig. The algorithm
			parameters field MUST be absent.
			signature contains the single HSS signature value resulting from
			the signing operation as specified in [HASHSIG].
	5. Security Considerations		5. Security Considerations
	5.1. Implementation Security Considerations		5.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.
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 26 ¶
	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.
	6. IANA Considerations		6. IANA Considerations
	{{ RFC Editor: Please remove this section prior to publication. }}
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Normative References		7. Acknowledgements
			Many thanks to Panos Kampanakis, Jim Schaad, and Sean Turner for
			their careful review and comments.
			8. Normative References
	[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation		[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, 2015.		Recommendation X.680, 2015.
	[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:		[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 2015.
	skipping to change at page 8, line 39 ¶		skipping to change at page 9, line 14 ¶
	[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, 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>.
	[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.
	8. Informative References		9. Informative References
	[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The		[BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The
	Factoring Dead: Preparing for the Cryptopocalypse", August		Factoring Dead: Preparing for the Cryptopocalypse", August
	2013. <https://media.blackhat.com/us-13/us-13-Stamos-The-		2013. <https://media.blackhat.com/us-13/us-13-Stamos-The-
	Factoring-Dead.pdf>		Factoring-Dead.pdf>
	[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for		[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,		Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	DOI 10.17487/RFC5911, June 2010, <http://www.rfc-		DOI 10.17487/RFC5911, June 2010, <http://www.rfc-
	editor.org/info/rfc5911>.		editor.org/info/rfc5911>.
			[CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
			for the Cryptographic Message Syntax (CMS) and the Public
			Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI
			10.17487/RFC6268, July 2011, <http://www.rfc-
			editor.org/info/rfc6268>.
	[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to		[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to
	Protect Firmware Packages", RFC 4108, DOI		Protect Firmware Packages", RFC 4108, DOI
	10.17487/RFC4108, August 2005, <http://www.rfc-		10.17487/RFC4108, August 2005, <http://www.rfc-
	editor.org/info/rfc4108>.		editor.org/info/rfc4108>.
	[LM] Leighton, T. and S. Micali, "Large provably fast and		[LM] Leighton, T. and S. Micali, "Large provably fast and
	secure digital signature schemes from secure hash		secure digital signature schemes from secure hash
	functions", U.S. Patent 5,432,852, July 1995.		functions", U.S. Patent 5,432,852, July 1995.
	[M1979] Merkle, R., "Secrecy, Authentication, and Public Key		[M1979] Merkle, R., "Secrecy, Authentication, and Public Key
	skipping to change at page 10, line 16 ¶		skipping to change at page 11, line 16 ¶
	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 IMPLICIT TAGS ::= BEGIN		DEFINITIONS IMPLICIT TAGS ::= BEGIN
	EXPORTS ALL;		EXPORTS ALL;
	IMPORTS		IMPORTS
	SIGNATURE-ALGORITHM PUBLIC-KEY		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
	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) } ;
	skipping to change at page 10, line 40 ¶		skipping to change at page 11, line 40 ¶
	id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-alg-mts-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 }
	--		--
	-- Signature Algorithm and Public Key		-- Signature Algorithm and Public Key
	--		--
	sa-MTS-HashSig SIGNATURE-ALGORITHM ::= {		sa-MTS-HashSig SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-alg-mts-hashsig		IDENTIFIER id-alg-mts-hashsig
	HASHES { mda-sha256, ... }		PARAMS ARE absent
	PUBLIC-KEYS { pk-MTS-HashSig } }		HASHES { mda-sha256 }
			PUBLIC-KEYS { pk-MTS-HashSig }
			SMIME-CAPS { IDENTIFIED BY id-alg-mts-hashsig } }
	pk-MTS-HashSig PUBLIC-KEY ::= {		pk-MTS-HashSig PUBLIC-KEY ::= {
	IDENTIFIER id-alg-mts-hashsig		IDENTIFIER id-alg-mts-hashsig
	KEY MTS-HashSig-PublicKey }		KEY MTS-HashSig-PublicKey
			PARAMS ARE absent
			CERT-KEY-USAGE
			{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
	MTS-HashSig-PublicKey ::= OCTET STRING		MTS-HashSig-PublicKey ::= OCTET STRING
			--
			-- Expand the signature algorithm set used by CMS [CMSASN1U]
			--
	HashSignatureAlgs SIGNATURE-ALGORITHM ::= {		SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
	sa-MTS-HashSig, ... }		{ sa-MTS-HashSig, ... }
			--
			-- Expand the S/MIME capabilities set used by CMS [CMSASN1]
			--
			SMimeCaps SMIME-CAPS ::= { sa-MTS-HashSig.&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. 30 change blocks.
	66 lines changed or deleted		113 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/