draft-ietf-lamps-cms-update-alg-id-protect-01.txt		draft-ietf-lamps-cms-update-alg-id-protect-02.txt
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Updates: 5652 (if approved) March 09, 2020		Updates: 5652 (if approved) May 28, 2020
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 10, 2020		Expires: November 29, 2020
	Update to the Cryptographic Message Syntax (CMS) for Algorithm		Update to the Cryptographic Message Syntax (CMS) for Algorithm
	Identifier Protection		Identifier Protection
	draft-ietf-lamps-cms-update-alg-id-protect-01		draft-ietf-lamps-cms-update-alg-id-protect-02
	Abstract		Abstract
	This document updates the Cryptographic Message Syntax (CMS)		This document updates the Cryptographic Message Syntax (CMS)
	specified in RFC 5652 to ensure that algorithm identifiers are		specified in RFC 5652 to ensure that algorithm identifiers in signed-
	adequately protected.		data and authenticated-data content types are adequately protected.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 10, 2020.		This Internet-Draft will expire on November 29, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Require use the same hash algorithm . . . . . . . . . . . . . 3		3. Require use the same hash algorithm . . . . . . . . . . . . . 3
	3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3		3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3
	3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4		3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4
	3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4		3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4
	3.4. Backward Compatibility Considerations . . . . . . . . . . 5		3.4. Backward Compatibility Considerations . . . . . . . . . . 5
	3.5. Timestamp Compatibility Considerations . . . . . . . . . 5		3.5. Timestamp Compatibility Considerations . . . . . . . . . 5
	4. Recommend inclusion of the CMSAlgorithmProtection attribute . 6		4. Recommend inclusion of the CMSAlgorithmProtection attribute . 5
	4.1. RFC 5652, Section 14 . . . . . . . . . . . . . . . . . . 6		4.1. RFC 5652, Section 14 . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	This document updates the Cryptographic Message Syntax (CMS)		This document updates the Cryptographic Message Syntax (CMS)
	[RFC5652] to ensure that algorithm identifiers are adequately		[RFC5652] to ensure that algorithm identifiers in signed-data and
	protected.		authenticated-data content types are adequately protected.
	The CMS Signed-data Content Type [RFC5652], unlike X.509 certificates		The CMS signed-data Content Type [RFC5652], unlike X.509 certificates
	[RFC5280], can be vulnerable to algorithm substitution attacks. In		[RFC5280], can be vulnerable to algorithm substitution attacks. In
	an algorithm substitution attack, the attacker changes either the		an algorithm substitution attack, the attacker changes either the
	algorithm identifier or the parameters associated with the algorithm		algorithm identifier or the parameters associated with the algorithm
	identifier to change the verification process used by the recipient.		identifier to change the verification process used by the recipient.
	The X.509 certificate structure protects the algorithm identifier and		The X.509 certificate structure protects the algorithm identifier and
	the associate parameters by signing them.		the associate parameters by signing them.
	In an algorithm substitution attack, the attacker looks for a		In an algorithm substitution attack, the attacker looks for a
	different algorithm that produces the same result as the algorithm		different algorithm that produces the same result as the algorithm
	used by the originator. As an example, if the signer of a message		used by the originator. As an example, if the signer of a message
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	The new requirement introduced above might lead to compatibility with		The new requirement introduced above might lead to compatibility with
	an implementation that allowed different digest algorithms to be used		an implementation that allowed different digest algorithms to be used
	to compute the digest of the message content and the digest of signed		to compute the digest of the message content and the digest of signed
	attributes. The signatures produced by such an implementation when		attributes. The signatures produced by such an implementation when
	two different digest algorithms are used will be considered invalid		two different digest algorithms are used will be considered invalid
	by an implementation that follows this specification. However, most,		by an implementation that follows this specification. However, most,
	if not all, implementations already require the originator to use the		if not all, implementations already require the originator to use the
	same digest algorithm for both operations.		same digest algorithm for both operations.
	READER:
	If you have an implementation that allows different digest
	algorithms to be used to compute the digest of the message content
	and the digest of signed attributes, please tell us on the
	spasm@ietf.org mail list.
	3.5. Timestamp Compatibility Considerations		3.5. Timestamp Compatibility Considerations
	The new requirement introduced above might lead to compatibility		The new requirement introduced above might lead to compatibility
	issues for timestamping systems when the originator does not wish to		issues for timestamping systems when the originator does not wish to
	share the message content with the Time Stamp Authority (TSA)		share the message content with the Time Stamp Authority (TSA)
	[RFC3161]. In this situation, the originator sends a TimeStampReq to		[RFC3161]. In this situation, the originator sends a TimeStampReq to
	the TSA that includes a MessageImprint, which consists of a digest		the TSA that includes a MessageImprint, which consists of a digest
	algorithm identifier and a digest value, then the TSA uses the		algorithm identifier and a digest value, then the TSA uses the
	originator-provided digest in the MessageImprint.		originator-provided digest in the MessageImprint.
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 15 ¶
	4.1. RFC 5652, Section 14		4.1. RFC 5652, Section 14
	Add the following paragraph as the eighth paragraph in Section 14:		Add the following paragraph as the eighth paragraph in Section 14:
	ADD:		ADD:
	While no known algorithm substitution attacks are known at this		While no known algorithm substitution attacks are known at this
	time, the inclusion of the algorithm identifiers used by the		time, the inclusion of the algorithm identifiers used by the
	originator as a signed attribute or an authenticated attribute		originator as a signed attribute or an authenticated attribute
	makes such an attack significantly more difficult. Therefore, the		makes such an attack significantly more difficult. Therefore, the
	originator of a Signed-data content type that includes signed		originator of a signed-data content type that includes signed
	attributes SHOULD include the CMSAlgorithmProtection attribute		attributes SHOULD include the CMSAlgorithmProtection attribute
	[RFC6211] as one of the signed attributes. Likewise, the		[RFC6211] as one of the signed attributes. Likewise, the
	originator of an Authenticated-data content type that includes		originator of an authenticated-data content type that includes
	authenticated attributes SHOULD include the CMSAlgorithmProtection		authenticated attributes SHOULD include the CMSAlgorithmProtection
	attribute [RFC6211] as one of the authenticated attributes.		attribute [RFC6211] as one of the authenticated attributes.
	5. IANA Considerations		5. IANA Considerations
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	6. Security Considerations		6. Security Considerations
	The security considerations of [RFC5652] are updated ensure that		The security considerations of [RFC5652] are updated ensure that
	algorithm identifiers are adequately protected, which makes algorithm		algorithm identifiers are adequately protected, which makes algorithm
	substitution attacks significantly more difficult.		substitution attacks significantly more difficult.
	The CMSAlgorithmProtection attribute [RFC6211] offers protection the		The CMSAlgorithmProtection attribute [RFC6211] offers protection for
	algorithm identifiers used in the signed-data and authenticated-data		the algorithm identifiers used in the signed-data and authenticated-
	content types. There is not currently protection mechanism for the		data content types. There is not currently protection mechanism for
	algorithm identifiers used in the enveloped-data, digested-data, or		the algorithm identifiers used in the enveloped-data, digested-data,
	encrypted-data content types. Likewise there us not currently		or encrypted-data content types. Likewise there is not currently a
	protection mechanism for the algorithm identifiers used in the		protection mechanism for the algorithm identifiers used in the
	authenticated-enveloped-data content type defined in [RFC5083].		authenticated-enveloped-data content type defined in [RFC5083].
	7. Acknowledgements		7. Acknowledgements
	Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they		Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they
	motivated me to write this document.		motivated me to write this document.
	8. References		8. References
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 8 ¶
	RFC 6210, DOI 10.17487/RFC6210, April 2011,		RFC 6210, DOI 10.17487/RFC6210, April 2011,
	<https://www.rfc-editor.org/info/rfc6210>.		<https://www.rfc-editor.org/info/rfc6210>.
	[SHS] National Institute of Standards and Technology (NIST),		[SHS] National Institute of Standards and Technology (NIST),
	"Secure Hash Standard", FIPS Publication 180-3, October		"Secure Hash Standard", FIPS Publication 180-3, October
	2008.		2008.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security		Vigil Security, LLC
	516 Dranesville Road		516 Dranesville Road
	Herndon, VA 20170		Herndon, VA 20170
	US		US
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 14 change blocks.
	27 lines changed or deleted		20 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/