< draft-schaad-smime-algorithm-attribute-00.txt		draft-schaad-smime-algorithm-attribute-01.txt >
	Network Working Group J. Schaad		Network Working Group J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Intended status: Standards Track May 5, 2009		Intended status: Standards Track December 17, 2009
	Expires: November 6, 2009		Expires: June 20, 2010
	Signer Info Algorithm Protection Attribute		Signer Info Algorithm Protection Attribute
	draft-schaad-smime-algorithm-attribute-00.txt		draft-schaad-smime-algorithm-attribute-01
			Abstract
			A new attribute is defined that allows for protection of the digest
			and signature algorithm structures in an authenticated data or a
			signer info structure. Using the attribute includes the algorithm
			defintion information in the integrity protection process.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 39 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	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.
	This Internet-Draft will expire on November 6, 2009.		This Internet-Draft will expire on June 20, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	A new signed attribute is defined that allows for protection of the		described in the BSD License.
	algorithm structures in an authenticated data or a signer info
	structure. By placing the information into a signed or authenticated
	attribute its value is then covered by the validation process.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5		2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5
	3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7		3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7		3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7
	3.2. Authenticated Data Verification Changes . . . . . . . . . 7		3.2. Authenticated Data Verification Changes . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. Normative References . . . . . . . . . . . . . . . . . . . . . 9		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
			5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
			5.2. Informational References . . . . . . . . . . . . . . . . . 9
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	In the current definition of [RFC3852] there are some fields that are		In the current definition of [RFC3852] there are some fields that are
	not protected in the process of doing either a signature validation		not protected in the process of doing either a signature validation
	or an authentication validation. In this document a new signed or		or an authentication validation. In this document a new signed or
	authenticated attribute is defined which permits these fields to be		authenticated attribute is defined which permits these fields to be
	validated.		validated.
	Taking the SignerInfo structure from CMS, lets look at each of the		Taking the SignerInfo structure from CMS, lets look at each of the
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	fields have been indirectly rather than explicity protected in the		fields have been indirectly rather than explicity protected in the
	past. With new algorithms that have been or are being defined this		past. With new algorithms that have been or are being defined this
	will no longer be the case. This document defines and describes a		will no longer be the case. This document defines and describes a
	new attribute that will explicitly protect these fields along with		new attribute that will explicitly protect these fields along with
	the macAlgorithm field of the AuthenticatedData structure.		the macAlgorithm field of the AuthenticatedData structure.
	1.1. Notation		1.1. Notation
	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[RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Attribute Structure		2. Attribute Structure
	The following defines the algorithm protection attribute:		The following defines the algorithm protection attribute:
	The algorithm-protection attribute has the ASN.1 type		The algorithm-protection attribute has the ASN.1 type
	AlgorithmProtection:		AlgorithmProtection:
	aa-CMSAlgorithmProtection ATTRIBUTE ::= {		aa-CMSAlgorithmProtection ATTRIBUTE ::= {
	TYPE CMSAlgorithmProtection		TYPE CMSAlgorithmProtection
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 37 ¶
	signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,		signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
	macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL		macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL
	}		}
	(WITH COMPONENTS { signatureAlgorithm PRESENT,		(WITH COMPONENTS { signatureAlgorithm PRESENT,
	macAlgorithm ABSENT } |		macAlgorithm ABSENT } |
	WITH COMPONENTS { signatureAlgorithm ABSENT,		WITH COMPONENTS { signatureAlgorithm ABSENT,
	macAlgorithm PRESENT })		macAlgorithm PRESENT })
	The fields are defined as follows:		The fields are defined as follows:
	digestAlg contains a copy of the digest algorithm identifier and any		digestAlg contains a copy of the SignerInfo.digestAlgorithm field or
			the AuthenticatedData.digestAlgorithm field including any
	parameters associated with it.		parameters associated with it.
	signatureAlg contains a copy of the signature algorithm identifier		signatureAlg contains a copy of the signature algorithm identifier
	and any parameters associated with it. This field is only		and any parameters associated with it. This field is only
	populated if the attribute is placed in a SignerInfo structure.		populated if the attribute is placed in a SignerInfo structure.
	authenticationAlg contains a copy of the message authentication code		authenticationAlg contains a copy of the message authentication code
	and any parameters associated with it. This field is only		and any parameters associated with it. This field is only
	populated if the attribute is placed in an authenticated data		populated if the attribute is placed in an authenticated data
	structure.		structure.
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	SET of Attributes. The SignedAttributes in a signerInfo MUST include		SET of Attributes. The SignedAttributes in a signerInfo MUST include
	only one instance of the algorithm protection attribute. Similarly,		only one instance of the algorithm protection attribute. Similarly,
	the AuthAttributes in an AuthenticatedData MUST include only one		the AuthAttributes in an AuthenticatedData MUST include only one
	instance of the algorithm protection attribute.		instance of the algorithm protection attribute.
	3. Verification Process		3. Verification Process
	The exact verification process depends on the structure being dealt		The exact verification process depends on the structure being dealt
	with.		with.
			When doing comparisions of the fields, a field whos value is a
			default value and one which is explicitly provided MUST compare as
			equivalent. It is not required that a field which is absent in one
			case and present in another case be compared as equivelent. (This
			mean that an algorithm identifier with absent parameters and one with
			NULL parameters need not compare as equivalent.)
	3.1. Signed Data Verification Changes		3.1. Signed Data Verification Changes
	If a CMS validator supports this attribute, the following additional		If a CMS validator supports this attribute, the following additional
	verification steps MUST be performed:		verification steps MUST be performed:
	1. The SignerInfo.digestAlgorithm field MUST be compared to the		1. The SignerInfo.digestAlgorithm field MUST be compared to the
	digestAlgorithm field in the attribute. If the fields are not same		digestAlgorithm field in the attribute. If the fields are not same
	(modulo encoding) then signature validation MUST fail.		(modulo encoding) then signature validation MUST fail.
	2. The SignerInfo.signatureAlgorithm field MUST be compared to the		2. The SignerInfo.signatureAlgorithm field MUST be compared to the
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	2. The AuthenticatedData.macAlgorithm field MUST be compared to the		2. The AuthenticatedData.macAlgorithm field MUST be compared to the
	macAlgorithm field in the attribute. If the fields are not the same		macAlgorithm field in the attribute. If the fields are not the same
	(modulo encoding) then the signature validation MUST fail.		(modulo encoding) then the signature validation MUST fail.
	4. Security Considerations		4. Security Considerations
	This document is designed to address the security issue of algorithm		This document is designed to address the security issue of algorithm
	substitutions of the algorithms used by the validator. At this time		substitutions of the algorithms used by the validator. At this time
	there is no known method to exploit this type of attack. If the		there is no known method to exploit this type of attack. If the
	attack could be successful, then a weaker algorithm could be		attack could be successful, then either a weaker algorithm could be
	substituted for a stronger algorithm.		substituted for a stronger algorithm or the parameters can be
			modified by an attacker to change the state of the hashing algorithm
			used. (One example would be changing the initial parmeter value for
			[I-D.schaad-smime-hash-experiment]
	The attributes defined in this document are to be placed in locations		The attributes defined in this document are to be placed in locations
	that are protected by the signature. This attribute does not provide		that are protected by the signature. This attribute does not provide
	any additional security if placed in an un-signed or un-authenticated		any additional security if placed in an un-signed or un-authenticated
	location.		location.
	5. Normative References		5. References
			5.1. Normative References
	[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",		[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
	RFC 2634, June 1999.		RFC 2634, June 1999.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, July 2004.		RFC 3852, July 2004.
	[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:		[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
	Adding CertID Algorithm Agility", RFC 5035, August 2007.		Adding CertID Algorithm Agility", RFC 5035, August 2007.
			[I-D.ietf-pkix-new-asn1]
			Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",
			draft-ietf-pkix-new-asn1-07 (work in progress),
			August 2009.
			5.2. Informational References
			[I-D.schaad-smime-hash-experiment]
			Schaad, J., "Experiment: Hash functions with parameters in
			CMS and S/MIME", draft-schaad-smime-hash-experiment-00
			(work in progress), May 2009.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	CMSAlgorithmAttribute		CMSAlgorithmAttribute
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0) TBD }		pkcs(1) pkcs-9(9) smime(16) modules(0) 989 }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	IMPORTS		IMPORTS
	-- Cryptographic Message Syntax (CMS) [RFC 3852]		-- Cryptographic Message Syntax (CMS) [RFC3852]
	ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier		DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
	FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840)		SignatureAlgorithmIdentifier
	rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)}		FROM CryptographicMessageSyntax-2009
	-- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module		{ iso(1) member-body(2) us(840) rsadsi(113549)
	-- 1988 Syntax [RFC 5280]		pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
	AlgorithmIdentifier, CertificateSerialNumber
	FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0) pkix1-explicit(18) }
	-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,		-- Common PKIX structures [I-D.ietf-pkix-new-asn1]
	-- 1988 Syntax [RFC 5280]		ATTRIBUTE
	PolicyInformation, CertificateSerialNumber, GeneralNames		FROM PKIX-CommonTypes-2009
	FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)		{iso(1) identified-organization(3) dod(6) internet(1) security(5)
	security(5) mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)};		mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)};
	--		--
	-- The CMS Algorithm Protection attribute is a Signed Attribute or		-- The CMS Algorithm Protection attribute is a Signed Attribute or
	-- an Authenticated Attribute.		-- an Authenticated Attribute.
	--		--
	-- Add this attribute to SignedAttributesSet in [CMS]		-- Add this attribute to SignedAttributesSet in [RFC3852]
	-- Add this attribute to AuthAttriuteSet in [CMS]		-- Add this attribute to AuthAttriuteSet in [RFC3852]
	--		--
	aa-CMSAlgorithmProtection ATTRIBUTE ::= {		aa-CMSAlgorithmProtection ATTRIBUTE ::= {
	TYPE CMSAlgorithmProtection		TYPE CMSAlgorithmProtection
	IDENTIFIED BY { id-aa-CMSAlgorithmProtection }		IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
	}		}
	id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) 989 }
	CMSAlgorithmProtection ::= SEQUENCE {		CMSAlgorithmProtection ::= SEQUENCE {
	digestAlgorithm DigestAlgorithmIdentifier,		digestAlgorithm DigestAlgorithmIdentifier,
	signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,		signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
	macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL		macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL
	}		}
	(WITH COMPONENTS { signatureAlgorithm PRESENT,		(WITH COMPONENTS { signatureAlgorithm PRESENT,
	macAlgorithm ABSENT } |		macAlgorithm ABSENT } |
	WITH COMPONENTS { signatureAlgorithm ABSENT,		WITH COMPONENTS { signatureAlgorithm ABSENT,
	macAlgorithm PRESENT })		macAlgorithm PRESENT })
			END
	Author's Address		Author's Address
	Jim Schaad		Jim Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	PO Box 675		PO Box 675
	Gold Bar, WA 98251		Gold Bar, WA 98251
	Email: jimsch@exmsft.com		Email: ietf@augustcellars.com
End of changes. 19 change blocks.
	40 lines changed or deleted		69 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/