< draft-schaad-smime-algorithm-attribute-01.txt		draft-schaad-smime-algorithm-attribute-02.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 December 17, 2009		Intended status: Standards Track November 22, 2010
	Expires: June 20, 2010		Expires: May 26, 2011
	Signer Info Algorithm Protection Attribute		Signer Info Algorithm Protection Attribute
	draft-schaad-smime-algorithm-attribute-01		draft-schaad-smime-algorithm-attribute-02
	Abstract		Abstract
	A new attribute is defined that allows for protection of the digest		A new attribute is defined that allows for protection of the digest
	and signature algorithm structures in an authenticated data or a		and signature algorithm structures in an authenticated data or a
	signer info structure. Using the attribute includes the algorithm		signer info structure. Using the attribute includes the algorithm
	defintion information in the integrity protection process.		definition 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 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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on May 26, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	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) 2010 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
	described in the BSD License.		described in the Simplified BSD License.
	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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 9		5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	5.2. Informational References . . . . . . . . . . . . . . . . . 9		5.2. Informational References . . . . . . . . . . . . . . . . . 9
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	In the current definition of [RFC3852] there are some fields that are		In the current definition of [CMS], 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, let's look at each of the
	fields for and discuss what is and is not protected by the signature.		fields and discuss what is and is not protected by the signature.
	The ASN.1 is included here for convience. (The analysis of		The ASN.1 is included here for convenience. (The analysis of
	AuthenticedData is similar.)		AuthenticatedData is similar.)
	SignerInfo ::= SEQUENCE {		SignerInfo ::= SEQUENCE {
	version CMSVersion,		version CMSVersion,
	sid SignerIdentifier,		sid SignerIdentifier,
	digestAlgorithm DigestAlgorithmIdentifier,		digestAlgorithm DigestAlgorithmIdentifier,
	signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,		signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
	signatureAlgorithm SignatureAlgorithmIdentifier,		signatureAlgorithm SignatureAlgorithmIdentifier,
	signature SignatureValue,		signature SignatureValue,
	unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }		unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
	version is not protected by the signature. Many implementations of		version is not protected by the signature. Many implementations of
	CMS today actually ignore the value of this field. If the		CMS today actually ignore the value of this field. If the
	structure decodes then this is considered sufficient to continue		structure decodes then this is considered sufficient to continue
	processing. Using most decoders on the market the value of this		processing. Using most decoders on the market the value of this
	field does not control how the decoding is actually processed.		field does not control how the decoding is actually processed.
	sid can be protected by the use of either signing certificate		sid can be protected by the use of either version of the signing
	authenticated attribute. SigningCertificateV2 is defined in		certificate authenticated attribute. SigningCertificateV2 is
	[RFC5035]. SigningCertificate is defined in [RFC2634]. In		defined in [RFC5035]. SigningCertificate is defined in [RFC2634].
	addition to allowing for the protection of the signer identifier,		In addition to allowing for the protection of the signer
	the specific certificate is protected by including a hash of the		identifier, the specific certificate is protected by including a
	certificate to be used for validation.		hash of the certificate to be used for validation.
	digestAlgorithm the digest algorithm used has been implicitly		digestAlgorithm the digest algorithm used has been implicitly
	protected by the fact that CMS has only defined one digest		protected by the fact that CMS has only defined one digest
	algorithm for each hash value length. (The algorithm RIPEM-160		algorithm for each hash value length. (The algorithm RIPEM-160
	was never standardized). If newer digest algorithms are defined		was never standardized). If newer digest algorithms are defined
	where there are multiple algorthms for a given hash length, or		where there are multiple algorithms for a given hash length, or
	where parameters are defined for a specific algorithm, this		where parameters are defined for a specific algorithm, this
	implicit protection will no longer exist.		implicit protection will no longer exist.
	signedAttributes are directly protected by the signature when they		signedAttributes are directly protected by the signature when they
	are present. The DER encoding of this value is what is actually		are present. The DER encoding of this value is what is actually
	hashed for the signature computation.		hashed for the signature computation.
	signatureAlgorithm has been protected by implication in the past.		signatureAlgorithm has been protected by implication in the past.
	For RSA v 1.5 signatures, the fact that the RSA algorithm was		The use of an RSA public key implied that the RSA v 1.5 signature
	known from the public key and the digest algorithm used is		algorithm was being used. The hash algorithm and this fact could
	included in the formatted value over which the RSA computation is		be checked by the internal padding defined. This is no longer
	done. For DSA signature, the fact that a DSA public key was		true with the addition of the RSA-PSS signature algorithms. The
	sufficient to know that SHA-1 was the digest algorithm as it was		use of a DSA public key implied the SHA-1 hash algorithm as that
	the only acceptable digest algorithm. With the advent of newer		was the only possible hash algorithm and the DSA was the public
	signature algorithms, especially those such as RSA-PSS which have		signature algorithm. This is longer true with the addition of the
	parameters, this implicit protection of the signature algorithm is		SHA2 signature algorithms.
	no longer possible.
	signature is not directly protected by any other value unless a		signature is not directly protected by any other value unless a
	counter signature is present. However this represents the		counter signature is present. However this represents the
	crytographically computed value to protected the rest of the		cryptographically computed value that protects the rest of the
	signature information.		signature information.
	unsignedAttrs is not protected by the signature value. It is also		unsignedAttrs is not protected by the signature value. It is also
	explicitly designed not to be protected by the signature value.		explicitly designed not to be protected by the signature value.
	As can be seen above, the digestAlgorithm and signatureAlgorithm		As can be seen above, the digestAlgorithm and signatureAlgorithm
	fields have been indirectly rather than explicity protected in the		fields have been indirectly rather than explicitly 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:		CMSAlgorithmProtection:
	aa-CMSAlgorithmProtection ATTRIBUTE ::= {		aa-cmsAlgorithmProtection ATTRIBUTE ::= {
	TYPE CMSAlgorithmProtection		TYPE CMSAlgorithmProtection
	IDENTIFIED BY { id-aa-CMSAlgorithmProtection }		IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
	}		}
	The following object identifier identifies the algorithm-protection		The following object identifier identifies the algorithm-protection
	attribute:		attribute:
	id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA }		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 }
	The algorithm-protection attribute uses the following ASN.1 type:		The algorithm-protection attribute uses the following ASN.1 type:
	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,		}
	macAlgorithm ABSENT } |		(WITH COMPONENTS { signatureAlgorithm PRESENT,
	WITH COMPONENTS { signatureAlgorithm ABSENT,		macAlgorithm ABSENT } |
	macAlgorithm PRESENT })		WITH COMPONENTS { signatureAlgorithm ABSENT,
			macAlgorithm PRESENT })
	The fields are defined as follows:		The fields are defined as follows:
	digestAlg contains a copy of the SignerInfo.digestAlgorithm field or		digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm
	the AuthenticatedData.digestAlgorithm field including any		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		signatureAlgorithm contains a copy of the signature algorithm
	and any parameters associated with it. This field is only		identifier and any parameters associated with it. This field is
	populated if the attribute is placed in a SignerInfo structure.		only populated if the attribute is placed in a
			SignerInfo.signedAttrs sequence.
	authenticationAlg contains a copy of the message authentication code		macAlgorithm contains a copy of the message authentication code
	and any parameters associated with it. This field is only		algorithm identifier and any parameters associated with it. This
	populated if the attribute is placed in an authenticated data		field is only populated if the attribute is placed in an
	structure.		AuthenticatedData.authAttrs sequence.
	Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.		Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.
	An algorithm protection MUST have a single attribute value, even		An algorithm-protection attribute MUST have a single attribute value,
	though the syntax is defined as a SET OF AttributeValue. There MUST		even though the syntax is defined as a SET OF AttributeValue. There
	not be zero or multiple instances of AttributeValue present.		MUST NOT be zero or multiple instances of AttributeValue present.
	The authentication protection attribute MUST be a signed attribute or		The algorithm-protection attribute MUST be a signed attribute or an
	an authenticated attribute; it MUST NOT be an unsigned attribute, an		authenticated attribute; it MUST NOT be an unsigned attribute, an
	unauthenticated attribute or an unprotected attribute.		unauthenticated attribute or an unprotected attribute.
	The SignedAttributes and AuthAttributes syntax are each defined as a		The SignedAttributes and AuthAttributes syntax are each defined as a
	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		When doing comparisons of the fields, a field whose value is a
	default value and one which is explicitly provided MUST compare as		default value and one which is explicitly provided MUST compare as
	equivalent. It is not required that a field which is absent in one		equivalent. It is not required that a field which is absent in one
	case and present in another case be compared as equivelent. (This		case and present in another case be compared as equivalent. (This
	mean that an algorithm identifier with absent parameters and one with		means that an algorithm identifier with absent parameters and one
	NULL parameters need not compare as equivalent.)		with NULL parameters are not expected to 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 the
	(modulo encoding) then signature validation MUST fail.		same (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
	signatureAlgorithm field in the attribute. If the fields are not the		signatureAlgorithm field in the attribute. If the fields are not the
	same (modulo encoding) then the signature validation MUST fail.		same (modulo encoding) then the signature validation MUST fail.
	3.2. Authenticated Data Verification Changes		3.2. Authenticated 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:
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	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 either a weaker algorithm could be		attack could be successful, then either a weaker algorithm could be
	substituted for a stronger algorithm or the parameters can be		substituted for a stronger algorithm or the parameters could be
	modified by an attacker to change the state of the hashing algorithm		modified by an attacker to change the behavior of the hashing
	used. (One example would be changing the initial parmeter value for		algorithm used. (One example would be changing the initial parameter
	[I-D.schaad-smime-hash-experiment]		value for [I-D.schaad-smime-hash-experiment].)
	The attributes defined in this document are to be placed in locations		The attribute defined in this document is to be placed in a location
	that are protected by the signature. This attribute does not provide		that is protected by the signature or message authentication code.
	any additional security if placed in an un-signed or un-authenticated		This attribute does not provide any additional security if placed in
	location.		an un-signed or un-authenticated location.
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
	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", BCP 14, RFC 2119, March 1997.
	[RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
	RFC 3852, July 2004.		RFC 2634, June 1999.
	[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]		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
	Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",		RFC 5652, September 2009.
	draft-ietf-pkix-new-asn1-07 (work in progress),
	August 2009.		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
			Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
			June 2010.
	5.2. Informational References		5.2. Informational References
	[I-D.schaad-smime-hash-experiment]		[I-D.schaad-smime-hash-experiment]
	Schaad, J., "Experiment: Hash functions with parameters in		Schaad, J., "Experiment: Hash functions with parameters in
	CMS and S/MIME", draft-schaad-smime-hash-experiment-00		CMS and S/MIME", draft-schaad-smime-hash-experiment-01
	(work in progress), May 2009.		(work in progress), December 2009.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	CMSAlgorithmAttribute		CMSAlgorithmProtectionAttribute
	{ 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) 989 }		pkcs(1) pkcs-9(9) smime(16) modules(0)
	DEFINITIONS IMPLICIT TAGS ::=		id-mod-cms-algorithmProtect(52) }
	BEGIN		DEFINITIONS IMPLICIT TAGS ::=
	IMPORTS		BEGIN
	-- Cryptographic Message Syntax (CMS) [RFC3852]		IMPORTS
			-- Cryptographic Message Syntax (CMS) [RFC5652]
	DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,		DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
	SignatureAlgorithmIdentifier		SignatureAlgorithmIdentifier
	FROM CryptographicMessageSyntax-2009		FROM CryptographicMessageSyntax-2009
	{ 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) id-mod-cms-2004-02(41) }		pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
	-- Common PKIX structures [I-D.ietf-pkix-new-asn1]		-- Common PKIX structures [RFC5912]
	ATTRIBUTE
	FROM PKIX-CommonTypes-2009
	{iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)};
	--		ATTRIBUTE
	-- The CMS Algorithm Protection attribute is a Signed Attribute or		FROM PKIX-CommonTypes-2009
	-- an Authenticated Attribute.		{ iso(1) identified-organization(3) dod(6) internet(1)
	--		security(5) mechanisms(5) pkix(7) id-mod(0)
	-- Add this attribute to SignedAttributesSet in [RFC3852]		id-mod-pkixCommon-02(57)};
	-- Add this attribute to AuthAttriuteSet in [RFC3852]
	--
	aa-CMSAlgorithmProtection ATTRIBUTE ::= {		--
			-- The CMS Algorithm Protection attribute is a Signed Attribute or
			-- an Authenticated Attribute.
			--
			-- Add this attribute to SignedAttributesSet in [RFC5652]
			-- Add this attribute to AuthAttriuteSet in [RFC5652]
			--
			aa-cmsAlgorithmProtection ATTRIBUTE ::= {
	TYPE CMSAlgorithmProtection		TYPE CMSAlgorithmProtection
	IDENTIFIED BY { id-aa-CMSAlgorithmProtection }		IDENTIFIED BY { id-aa-cmsAlgorithmProtect }
	}		}
	id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= {
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) 989 }		iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
			pkcs9(9) 52 }
	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,
	macAlgorithm ABSENT } |		}
	WITH COMPONENTS { signatureAlgorithm ABSENT,		(WITH COMPONENTS { signatureAlgorithm PRESENT,
	macAlgorithm PRESENT })		macAlgorithm ABSENT } |
			WITH COMPONENTS { signatureAlgorithm ABSENT,
			macAlgorithm PRESENT })
	END		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: ietf@augustcellars.com		Email: ietf@augustcellars.com
End of changes. 44 change blocks.
	133 lines changed or deleted		131 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/