draft-ietf-lamps-cms-shakes-07.txt		draft-ietf-lamps-cms-shakes-08.txt
	LAMPS WG P. Kampanakis		LAMPS WG P. Kampanakis
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track Q. Dang		Intended status: Standards Track Q. Dang
	Expires: August 4, 2019 NIST		Expires: September 9, 2019 NIST
	January 31, 2019		March 8, 2019
	Use of the SHAKE One-way Hash Functions in the Cryptographic Message		Use of the SHAKE One-way Hash Functions in the Cryptographic Message
	Syntax (CMS)		Syntax (CMS)
	draft-ietf-lamps-cms-shakes-07		draft-ietf-lamps-cms-shakes-08
	Abstract		Abstract
	This document describes the conventions for using the SHAKE family of		This document describes the conventions for using the SHAKE family of
	hash functions with the Cryptographic Message Syntax (CMS) as one-way		hash functions with the Cryptographic Message Syntax (CMS) as one-way
	hash functions with the RSA Probabilistic signature and ECDSA		hash functions with the RSA Probabilistic signature and ECDSA
	signature algorithms, as message digests and message authentication		signature algorithms, as message digests and message authentication
	codes. The conventions for the associated signer public keys in CMS		codes. The conventions for the associated signer public keys in CMS
	are also described.		are also described.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 4, 2019.		This Internet-Draft will expire on September 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6		4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7		4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7
	4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7		4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8
	4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Message Authentication Codes . . . . . . . . . . . . . . 8		4.4. Message Authentication Codes . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Change Log		1. Change Log
	[ EDNOTE: Remove this section before publication. ]		[ EDNOTE: Remove this section before publication. ]
			o draft-ietf-lamps-cms-shake-08:
			* id-shake128-len and id-shake256-len were replaced with id-
			sha128 with 32 bytes output length and id-shake256 with 64
			bytes output length.
			* Fixed a discrepancy between section 3 and 4.4 about the KMAC
			OIDs that have parameters as optional.
	o draft-ietf-lamps-cms-shake-07:		o draft-ietf-lamps-cms-shake-07:
	* Small nit from Russ while in WGLC.		* Small nit from Russ while in WGLC.
	o draft-ietf-lamps-cms-shake-06:		o draft-ietf-lamps-cms-shake-06:
	* Incorporated Eric's suggestion from WGLC.		* Incorporated Eric's suggestion from WGLC.
	o draft-ietf-lamps-cms-shake-05:		o draft-ietf-lamps-cms-shake-05:
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 17 ¶
	This section defines six new object identifiers (OIDs) for using		This section defines six new object identifiers (OIDs) for using
	SHAKE128 and SHAKE256 in CMS.		SHAKE128 and SHAKE256 in CMS.
	EDNOTE: If PKIX draft is standardized first maybe we should not say		EDNOTE: If PKIX draft is standardized first maybe we should not say
	the identifiers are new for the RSASSA-PSS and ECDSA.		the identifiers are new for the RSASSA-PSS and ECDSA.
	Two object identifiers for SHAKE128 and SHAKE256 hash functions are		Two object identifiers for SHAKE128 and SHAKE256 hash functions are
	defined in [shake-nist-oids] and we include them here for		defined in [shake-nist-oids] and we include them here for
	convenience.		convenience.
	id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 17 }		nistAlgorithm(4) 2 11 }
	id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 18 }		nistAlgorithm(4) 2 12 }
	In this specification, when using the id-shake128-len or id-		In this specification, when using the id-shake128 or id-shake256
	shake256-len algorithm identifiers, the parameters MUST be absent.		algorithm identifiers, the parameters MUST be absent. That is, the
	That is, the identifier SHALL be a SEQUENCE of one component, the		identifier SHALL be a SEQUENCE of one component, the OID.
	OID.
	We define two new identifiers for RSASSA-PSS signatures using SHAKEs.		We define two new identifiers for RSASSA-PSS signatures using SHAKEs.
	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD }		id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD }
	id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD }		id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD }
	[ EDNOTE: "TBD" will be specified by NIST later. ]		[ EDNOTE: "TBD" will be specified by NIST later. ]
	The same RSASSA-PSS algorithm identifiers can be used for identifying		The same RSASSA-PSS algorithm identifiers can be used for identifying
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 20 ¶
	defined below.		defined below.
	id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 19 }		nistAlgorithm(4) 2 19 }
	id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 20 }		nistAlgorithm(4) 2 20 }
	The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST		The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 are
	be absent. That is, each identifier SHALL be a SEQUENCE of one		OPTIONAL.
	component, the OID.
	Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the		Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the
	required output length for each use of SHAKE128 or SHAKE256 in		required output length for each use of SHAKE128 or SHAKE256 in
	message digests, RSASSA-PSS, ECDSA and KMAC.		message digests, RSASSA-PSS, ECDSA and KMAC.
	4. Use in CMS		4. Use in CMS
	4.1. Message Digests		4.1. Message Digests
	The id-shake128-len and id-shake256-len OIDs (Section 3) can be used		The id-shake128 and id-shake256 OIDs (Section 3) can be used as the
	as the digest algorithm identifiers located in the SignedData,		digest algorithm identifiers located in the SignedData, SignerInfo,
	SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm		DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS
	fields in CMS [RFC5652]. The encoding MUST omit the parameters field		[RFC5652]. The encoding MUST omit the parameters field and the
	and the output size, d, for the SHAKE128 or SHAKE256 message digest		output size, d, for the SHAKE128 or SHAKE256 message digest MUST be
	MUST be 256 or 512 bits respectively.		256 or 512 bits respectively.
	The digest values are located in the DigestedData field and the		The digest values are located in the DigestedData field and the
	Message Digest authenticated attribute included in the		Message Digest authenticated attribute included in the
	signedAttributes of the SignedData signerInfo. In addition, digest		signedAttributes of the SignedData signerInfo. In addition, digest
	values are input to signature algorithms. The digest algorithm MUST		values are input to signature algorithms. The digest algorithm MUST
	be the same as the message hash algorithms used in signatures.		be the same as the message hash algorithms used in signatures.
	4.2. Signatures		4.2. Signatures
	In CMS, signature algorithm identifiers are located in the SignerInfo		In CMS, signature algorithm identifiers are located in the SignerInfo
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 12 ¶
	The identifier parameters, as explained in Section 3, MUST be absent.		The identifier parameters, as explained in Section 3, MUST be absent.
	4.4. Message Authentication Codes		4.4. Message Authentication Codes
	KMAC message authentication code (KMAC) is specified in [SP800-185].		KMAC message authentication code (KMAC) is specified in [SP800-185].
	In CMS, KMAC algorithm identifiers are located in the		In CMS, KMAC algorithm identifiers are located in the
	AuthenticatedData macAlgorithm field. The KMAC values are located in		AuthenticatedData macAlgorithm field. The KMAC values are located in
	the AuthenticatedData mac field.		the AuthenticatedData mac field.
	When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm		When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID is used as
	identifier is used as the MAC algorithm identifier, the parameters		the MAC algorithm identifier, the parameters field is optional
	field is optional (absent or present). If absent, the SHAKE256		(absent or present). If absent, the SHAKE256 output length used in
	output length used in KMAC is 256 or 512 bits respectively and the		KMAC is 256 or 512 bits respectively and the customization string is
	customization string is an empty string by default.		an empty string by default.
	Conforming implementations that process KMACs with the SHAKEs when		Conforming implementations that process KMACs with the SHAKEs when
	processing CMS data MUST recognize these identifiers.		processing CMS data MUST recognize these identifiers.
	When calculating the KMAC output, the variable N is 0xD2B282C2, S is		When calculating the KMAC output, the variable N is 0xD2B282C2, S is
	an empty string, and L, the integer representing the requested output		an empty string, and L, the integer representing the requested output
	length in bits, is 256 or 512 for KmacWithSHAKE128 or		length in bits, is 256 or 512 for KmacWithSHAKE128 or
	KmacWithSHAKE256 respectively in this specification.		KmacWithSHAKE256 respectively in this specification.
	5. IANA Considerations		5. IANA Considerations
End of changes. 15 change blocks.
	29 lines changed or deleted		36 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/