< draft-ietf-smime-3278bis-04.txt		draft-ietf-smime-3278bis-05.txt >
	S/MIME WG Sean Turner, IECA		S/MIME WG Sean Turner, IECA
	Internet Draft Dan Brown, Certicom		Internet Draft Dan Brown, Certicom
	Intended Status: Informational December 11, 2008		Intended Status: Informational January 5, 2009
	Obsoletes: 3278 (once approved)		Obsoletes: 3278 (once approved)
	Expires: June 11, 2009		Expires: July 5, 2009
	Use of Elliptic Curve Cryptography (ECC) Algorithms		Use of Elliptic Curve Cryptography (ECC) Algorithms
	in Cryptographic Message Syntax (CMS)		in Cryptographic Message Syntax (CMS)
	draft-ietf-smime-3278bis-04.txt		draft-ietf-smime-3278bis-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of 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.
	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		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 June 11, 2008.		This Internet-Draft will expire on June 5, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	Abstract		Abstract
	This document describes how to use Elliptic Curve Cryptography (ECC)		This document describes how to use Elliptic Curve Cryptography (ECC)
	public-key algorithms in the Cryptographic Message Syntax (CMS). The		public-key algorithms in the Cryptographic Message Syntax (CMS). The
	ECC algorithms support the creation of digital signatures and the		ECC algorithms support the creation of digital signatures and the
	exchange of keys to encrypt or authenticate content. The definition		exchange of keys to encrypt or authenticate content. The definition
	of the algorithm processing is based on the NIST FIPS 186-3 for		of the algorithm processing is based on the NIST FIPS 186-3 for
	digital signature, NIST SP800-56A and SEC1 for key agreement, RFC		digital signature, NIST SP800-56A and SEC1 for key agreement, RFC
	3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-		3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 30 ¶
	This draft is being discussed on the 'ietf-smime' mailing list. To		This draft is being discussed on the 'ietf-smime' mailing list. To
	subscribe, send a message to ietf-smime-request@imc.org with the		subscribe, send a message to ietf-smime-request@imc.org with the
	single word subscribe in the body of the message. There is a Web site		single word subscribe in the body of the message. There is a Web site
	for the mailing list at <http://www.imc.org/ietf-smime/>.		for the mailing list at <http://www.imc.org/ietf-smime/>.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1. Requirements Terminology..................................3		1.1. Requirements Terminology..................................3
	2. SignedData using ECC...........................................3		2. SignedData using ECC...........................................3
	2.1. SignedData using ECDSA....................................3		2.1. SignedData using ECDSA....................................4
	3. EnvelopedData using ECC Algorithms.............................5		3. EnvelopedData using ECC Algorithms.............................5
	3.1. EnvelopedData using (ephemeral-static) ECDH...............5		3.1. EnvelopedData using (ephemeral-static) ECDH...............5
	3.2. EnvelopedData using 1-Pass ECMQV..........................7		3.2. EnvelopedData using 1-Pass ECMQV..........................7
	4. AuthenticatedData and AuthEnvelopedData using ECC.............10		4. AuthenticatedData and AuthEnvelopedData using ECC.............10
	4.1. AuthenticatedData using 1-pass ECMQV.....................10		4.1. AuthenticatedData using 1-pass ECMQV.....................10
	4.2. AuthEnvelopedData using 1-pass ECMQV.....................11		4.2. AuthEnvelopedData using 1-pass ECMQV.....................11
	5. Certificates using ECC........................................12		5. Certificates using ECC........................................12
	6. SMIMECapabilities Attribute and ECC...........................12		6. SMIMECapabilities Attribute and ECC...........................12
	7. ASN.1 Syntax..................................................20		7. ASN.1 Syntax..................................................20
	7.1. Algorithm Identifiers....................................20		7.1. Algorithm Identifiers....................................20
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 34 ¶
	static-static DH, which is specified in [CMS-ALG]. Ephemeral-static		static-static DH, which is specified in [CMS-ALG]. Ephemeral-static
	ECDH and 1-Pass ECMQV were specified because they provide better		ECDH and 1-Pass ECMQV were specified because they provide better
	security due to the originator's ephemeral contribution to the key		security due to the originator's ephemeral contribution to the key
	agreement scheme.		agreement scheme.
	3.1. EnvelopedData using (ephemeral-static) ECDH		3.1. EnvelopedData using (ephemeral-static) ECDH
	This section describes how to use the ephemeral-static Elliptic Curve		This section describes how to use the ephemeral-static Elliptic Curve
	Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData,		Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData,
	method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard		method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard
	primitive from Section 3.3.1 [SEC1]. Ephemeral-static ECDH is the		primitive from Section 3.3.1 of [SEC1]. Ephemeral-static ECDH is the
	elliptic curve analog of the ephemeral-static Diffie-Hellman key		elliptic curve analog of the ephemeral-static Diffie-Hellman key
	agreement algorithm specified jointly in the documents [CMS-ALG] and		agreement algorithm specified jointly in the documents [CMS-ALG] and
	[CMS-DH].		[CMS-DH].
	If an implementation uses ECDH with CMS EnvelopedData, then the		If an implementation uses ECDH with CMS EnvelopedData, then the
	following techniques and formats MUST be used.		following techniques and formats MUST be used.
	The fields of EnvelopedData are as in [CMS], as ECDH is a key		The fields of EnvelopedData are as in [CMS]; as ECDH is a key
	agreement algorithm the RecipientInfo kari choice is used.		agreement algorithm, the RecipientInfo kari choice is used.
	3.1.1. Fields of KeyAgreeRecipientInfo		3.1.1. Fields of KeyAgreeRecipientInfo
	When using ephemeral-static ECDH with EnvelopedData, the fields of		When using ephemeral-static ECDH with EnvelopedData, the fields of
	KeyAgreeRecipientInfo are as follows:		KeyAgreeRecipientInfo are as follows:
	- version MUST be 3.		- version MUST be 3.
	- originator MUST be the alternative originatorKey. The		- originator MUST be the alternative originatorKey. The
	originatorKey algorithm field MUST contain the id-ecPublicKey		originatorKey algorithm field MUST contain the id-ecPublicKey
	object identifier (see Section 7.1.3). The parameters		object identifier (see Section 7.1.3). The parameters
	associated with id-ecPublicKey MUST be absent or ECParameters.		associated with id-ecPublicKey MUST be absent or ECParameters.
	NOTE: The previous version of this document required NULL to be		NOTE: The previous version of this document required NULL to be
	present, support for this legacy form is OPTIONAL. The		present; support for this legacy form is OPTIONAL. The
	originatorKey publicKey field MUST contain the value of the		originatorKey publicKey field MUST contain the value of the
	ASN.1 type ECPoint (see Section 7.2), which represents the		ASN.1 type ECPoint (see Section 7.2), which represents the
	sending agent's ephemeral EC public key. The ECPoint in		sending agent's ephemeral EC public key. The ECPoint in
	uncompressed form MUST be supported.		uncompressed form MUST be supported.
	- ukm MAY be present or absent. However, message originators		- ukm MAY be present or absent. However, message originators
	SHOULD include the ukm. As specified in RFC 3852 [CMS],		SHOULD include the ukm. As specified in RFC 3852 [CMS],
	implementations MUST support ukm message recipient processing,		implementations MUST support ukm message recipient processing,
	so interoperability is not a concern if the ukm is present or		so interoperability is not a concern if the ukm is present or
	absent. The ukm is placed in the entityUInfo field of the ECC-		absent. The ukm is placed in the entityUInfo field of the ECC-
	CMS-SharedInfo structure. When present, the ukm is used to		CMS-SharedInfo structure. When present, the ukm is used to
	ensure that a different key-encryption key is generated, even		ensure that a different key-encryption key is generated, even
	when the ephemeral private key is improperly used more than		when the ephemeral private key is improperly used more than
	once, by using the ECC-CMS-SharedInfo as an input to the key		once, by using the ECC-CMS-SharedInfo as an input to the key
	derivation function (see Section 7.2).		derivation function (see Section 7.2).
	- keyEncryptionAlgorithm MUST contain the key encryption algorithm,		- keyEncryptionAlgorithm MUST contain the object identifier of the
	which in this case is a key agreement algorithm, object		key encryption algorithm, which in this case is a key agreement
	identifier (see Section 7.1.4). The parameters field contains		algorithm (see Section 7.1.4). The parameters field contains
	KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm		KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm
	identifier that indicates the symmetric encryption algorithm		identifier that indicates the symmetric encryption algorithm
	used to encrypt the content-encryption key (CEK) with the key-		used to encrypt the content-encryption key (CEK) with the key-
	encryption key (KEK) and any associated parameters (see Section		encryption key (KEK) and any associated parameters (see Section
	7.1.5). Algorithm requirements are found in Section 8.		7.1.5). Algorithm requirements are found in Section 8.
	- recipientEncryptedKeys contains an identifier and an encrypted		- recipientEncryptedKeys contains an identifier and an encrypted
	key for each recipient. The RecipientEncryptedKey		key for each recipient. The RecipientEncryptedKey
	KeyAgreeRecipientIdentifier MUST contain either the		KeyAgreeRecipientIdentifier MUST contain either the
	issuerAndSerialNumber identifying the recipient's certificate or		issuerAndSerialNumber identifying the recipient's certificate or
	skipping to change at page 6, line 50 ¶		skipping to change at page 7, line 11 ¶
	When using ephemeral-static ECDH with EnvelopedData, the sending		When using ephemeral-static ECDH with EnvelopedData, the sending
	agent first obtains the recipient's EC public key and domain		agent first obtains the recipient's EC public key and domain
	parameters (e.g. from the recipient's certificate). The sending		parameters (e.g. from the recipient's certificate). The sending
	agent then determines an integer "keydatalen", which is the		agent then determines an integer "keydatalen", which is the
	KeyWrapAlgorithm symmetric key-size in bits, and also a bit string		KeyWrapAlgorithm symmetric key-size in bits, and also a bit string
	"SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see		"SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see
	Section 7.2). The sending agent then performs the key deployment and		Section 7.2). The sending agent then performs the key deployment and
	the key agreement operation of the Elliptic Curve Diffie-Hellman		the key agreement operation of the Elliptic Curve Diffie-Hellman
	Scheme specified in [SP800-56A] or [SEC1]; in either case, use the		Scheme specified in [SP800-56A] or [SEC1]; in either case, use the
	KDF defined in Section 3.6.1 of [SEC1] with the has algorithm		KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm
	identified in the key agreement algorithm. As a result the sending		identified in the key agreement algorithm. As a result the sending
	agent obtains:		agent obtains:
	- an ephemeral public key, which is represented as a value of the		- an ephemeral public key, which is represented as a value of the
	type ECPoint (see Section 7.2), encapsulated in a bit string and		type ECPoint (see Section 7.2), encapsulated in a bit string and
	placed in the KeyAgreeRecipientInfo originator field, and		placed in the KeyAgreeRecipientInfo originator field, and
	- a shared secret bit string "K", which is used as the pairwise		- a shared secret bit string "K", which is used as the pairwise
	key-encryption key for that recipient, as specified in [CMS].		key-encryption key for that recipient, as specified in [CMS].
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 13 ¶
	agent. Using an algorithm with the sender static key pair allows for		agent. Using an algorithm with the sender static key pair allows for
	knowledge of the message creator, this means that authentication can,		knowledge of the message creator, this means that authentication can,
	in some circumstances, be obtained for AuthEnvelopedData and		in some circumstances, be obtained for AuthEnvelopedData and
	AuthenticatedData. This means that 1-Pass ECMQV can be a common		AuthenticatedData. This means that 1-Pass ECMQV can be a common
	algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData,		algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData,
	while ECDH can only be used in EnvelopedData.		while ECDH can only be used in EnvelopedData.
	If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then		If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then
	the following techniques and formats MUST be used.		the following techniques and formats MUST be used.
	The fields of EnvelopedData are as in [CMS], as 1-Pass ECMQV is a key		The fields of EnvelopedData are as in [CMS]; as 1-Pass ECMQV is a key
	agreement algorithm the RecipientInfo kari choice is used. When		agreement algorithm, the RecipientInfo kari choice is used. When
	using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY		using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY
	include the certificate(s) for the EC public key(s) used in the		include the certificate(s) for the EC public key(s) used in the
	formation of the pairwise key. ECC certificates are discussed in		formation of the pairwise key. ECC certificates are discussed in
	Section 5.		Section 5.
	3.2.1. Fields of KeyAgreeRecipientInfo		3.2.1. Fields of KeyAgreeRecipientInfo
	When using 1-Pass ECMQV with EnvelopedData, the fields of		When using 1-Pass ECMQV with EnvelopedData, the fields of
	KeyAgreeRecipientInfo are:		KeyAgreeRecipientInfo are:
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 38 ¶
	SHOULD be one of the alternatives, issuerAndSerialNumber or		SHOULD be one of the alternatives, issuerAndSerialNumber or
	subjectKeyIdentifier, and point to one of the sending agent's		subjectKeyIdentifier, and point to one of the sending agent's
	certificates.		certificates.
	- ukm MUST be present. The ukm field is an octet string which MUST		- ukm MUST be present. The ukm field is an octet string which MUST
	contain the DER encoding of the type MQVuserKeyingMaterial (see		contain the DER encoding of the type MQVuserKeyingMaterial (see
	Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey		Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey
	algorithm field MUST contain the id-ecPublicKey object		algorithm field MUST contain the id-ecPublicKey object
	identifier (see Section 7.1.3). The parameters associated with		identifier (see Section 7.1.3). The parameters associated with
	id-ecPublicKey MUST be absent or ECParameters. NOTE: The		id-ecPublicKey MUST be absent or ECParameters. NOTE: The
	previous version of this document required NULL to be present,		previous version of this document required NULL to be present;
	support for this legacy form is OPTIONAL. The		support for this legacy form is OPTIONAL. The
	MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST		MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
	contain the DER-encoding of the ASN.1 type ECPoint (see Section		contain the DER-encoding of the ASN.1 type ECPoint (see Section
	7.2) representing the sending agent's ephemeral EC public key.		7.2) representing the sending agent's ephemeral EC public key.
	The MQVuserKeyingMaterial addedukm field, if present, contains		The MQVuserKeyingMaterial addedukm field, if present, contains
	additional user keying material from the sending agent.		additional user keying material from the sending agent.
	- keyEncryptionAlgorithm MUST contain the key encryption algorithm,		- keyEncryptionAlgorithm MUST contain the object identifier of the
	which in this case is a key agreement algorithm, object		key encryption algorithm, which in this case is a key agreement
	identifier (see Section 7.1.4). The parameters field contains		algorithm (see Section 7.1.4). The parameters field contains
	KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric		KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
	encryption algorithm used to encrypt the CEK with the KEK		encryption algorithm used to encrypt the CEK with the KEK
	generated using the 1-Pass ECMQV algorithm and any associated		generated using the 1-Pass ECMQV algorithm and any associated
	parameters (see Section 7.1.5). Algorithm requirements are		parameters (see Section 7.1.5). Algorithm requirements are
	found in Section 8.		found in Section 8.
	- recipientEncryptedKeys contains an identifier and an encrypted		- recipientEncryptedKeys contains an identifier and an encrypted
	key for each recipient. The RecipientEncryptedKey		key for each recipient. The RecipientEncryptedKey
	KeyAgreeRecipientIdentifier MUST contain either the		KeyAgreeRecipientIdentifier MUST contain either the
	issuerAndSerialNumber identifying the recipient's certificate or		issuerAndSerialNumber identifying the recipient's certificate or
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 12 ¶
	determines the bit string "SharedInfo", which is the DER encoding of		determines the bit string "SharedInfo", which is the DER encoding of
	ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen"		ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen"
	from the key-size, in bits, of the KeyWrapAlgorithm. The receiving		from the key-size, in bits, of the KeyWrapAlgorithm. The receiving
	agent then retrieves the static and ephemeral EC public keys of the		agent then retrieves the static and ephemeral EC public keys of the
	originator, from the originator and ukm fields as described in		originator, from the originator and ukm fields as described in
	Section 3.2.1, and its static EC public key identified in the rid		Section 3.2.1, and its static EC public key identified in the rid
	field and checks that the originator's domain parameters are the same		field and checks that the originator's domain parameters are the same
	as the recipient's domain parameters. The receiving agent then		as the recipient's domain parameters. The receiving agent then
	performs the key agreement operation of the Elliptic Curve MQV Scheme		performs the key agreement operation of the Elliptic Curve MQV Scheme
	[SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As		[SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As
	a result, the receiving agent obtains a shared secret bit string "K"		a result, the receiving agent obtains a shared secret bit string "K",
	which is used as the pairwise key-encryption key to unwrap the CEK.		which is used as the pairwise key-encryption key to unwrap the CEK.
	4. AuthenticatedData and AuthEnvelopedData using ECC		4. AuthenticatedData and AuthEnvelopedData using ECC
	This section describes how to use ECC algorithms with the CMS		This section describes how to use ECC algorithms with the CMS
	AuthenticatedData format. AuthenticatedData lacks non-repudiation,		AuthenticatedData format. AuthenticatedData lacks non-repudiation,
	and so in some instances is preferable to SignedData. (For example,		and so in some instances is preferable to SignedData. (For example,
	the sending agent might not want the message to be authenticated when		the sending agent might not want the message to be authenticated when
	forwarded.)		forwarded.)
	skipping to change at page 13, line 8 ¶		skipping to change at page 13, line 4 ¶
	6. SMIMECapabilities Attribute and ECC		6. SMIMECapabilities Attribute and ECC
	A sending agent MAY announce to receiving agents that it supports one		A sending agent MAY announce to receiving agents that it supports one
	or more of the ECC algorithms specified in this document by using the		or more of the ECC algorithms specified in this document by using the
	SMIMECapabilities signed attribute [MSG] in either a signed message		SMIMECapabilities signed attribute [MSG] in either a signed message
	or a certificate [CERTCAP].		or a certificate [CERTCAP].
	The SMIMECapabilities attribute value indicates support for one of		The SMIMECapabilities attribute value indicates support for one of
	the ECDSA signature algorithms in a SEQUENCE with the capabilityID		the ECDSA signature algorithms in a SEQUENCE with the capabilityID
	field containing the object identifier ecdsa-with-SHA1 with NULL		field containing the object identifier ecdsa-with-SHA1 with NULL
	parameters and ecdsa-with-SHA1* (where * is 224, 256, 384, or 512)		parameters and ecdsa-with-SHA* (where * is 224, 256, 384, or 512)
	with absent parameters. The DER encodings are:		with absent parameters. The DER encodings are:
	ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00		ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
	ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01		ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01
	ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02		ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02
	ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03		ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03
	ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04		ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04
	NOTE: The S/MIMECapabilities attribute indicates that parameters for		NOTE: The SMIMECapabilities attribute indicates that parameters for
	ECDSA with SHA-1 are NULL, however, the parameters are absent when		ECDSA with SHA-1 are NULL, however, the parameters are absent when
	used to generate a digital signature.		used to generate a digital signature.
	The SMIMECapabilities attribute value indicates support for		The SMIMECapabilities attribute value indicates support for
	a) the standard ECDH key agreement algorithm,		a) the standard ECDH key agreement algorithm,
	b) the cofactor ECDH key agreement algorithm, or		b) the cofactor ECDH key agreement algorithm, or
	c) the 1-Pass ECMQV key agreement algorithm		c) the 1-Pass ECMQV key agreement algorithm
	is a SEQUENCE with the capabilityID field containing the object		is a SEQUENCE with the capabilityID field containing the object
	identifier		identifier
	a) dhSinglePass-stdDH-sha*kdf-scheme,		a) dhSinglePass-stdDH-sha*kdf-scheme,
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 9 ¶
	Digest algorithm object identifiers are used in the SignedData		Digest algorithm object identifiers are used in the SignedData
	digestAlgorithms and digestAlgorithm fields and the AuthenticatedData		digestAlgorithms and digestAlgorithm fields and the AuthenticatedData
	digestAlgorithm field. The digest algorithms used in this document		digestAlgorithm field. The digest algorithms used in this document
	are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object		are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object
	identifiers and parameters associated with these algorithms are found		identifiers and parameters associated with these algorithms are found
	in [CMS-ALG] and [CMS-SHA2].		in [CMS-ALG] and [CMS-SHA2].
	7.1.2. Originator Public Key		7.1.2. Originator Public Key
	The KeyAgreeRecipientInfo originator field use the following object		The KeyAgreeRecipientInfo originator field uses the following object
	identifier to indicate an elliptic curve public key:		identifier to indicate an elliptic curve public key:
	id-ecPublicKey OBJECT IDENTIFIER ::= {		id-ecPublicKey OBJECT IDENTIFIER ::= {
	ansi-x9-62 keyType(2) 1 }		ansi-x9-62 keyType(2) 1 }
	where		where
	ansi-x9-62 OBJECT IDENTIFIER ::= {		ansi-x9-62 OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) 10045 }		iso(1) member-body(2) us(840) 10045 }
	skipping to change at page 21, line 40 ¶		skipping to change at page 21, line 40 ¶
	7.1.3. Signature Algorithms		7.1.3. Signature Algorithms
	Signature algorithm identifiers are used in the SignedData		Signature algorithm identifiers are used in the SignedData
	signatureAlgorithm and signature fields. The signature algorithms		signatureAlgorithm and signature fields. The signature algorithms
	used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA		used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA
	with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object		with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object
	identifiers and parameters associated with these algorithms are found		identifiers and parameters associated with these algorithms are found
	in [PKI-ALG].		in [PKI-ALG].
	NOTE: [CMS-ECC] indicated the parameters were NULL. Support for NULL		NOTE: [CMS-ECC] indicated the parameters were NULL. Support for this
	parameters is OPTIONAL.		legacy form is OPTIONAL.
	7.1.4. Key Agreement Algorithms		7.1.4. Key Agreement Algorithms
	Key agreement algorithms are used in EnvelopedData,		Key agreement algorithms are used in EnvelopedData,
	AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo		AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo
	keyEncryptionAlgorithm field. The following object identifiers		keyEncryptionAlgorithm field. The following object identifiers
	indicate the key agreement algorithms used in this document:		indicate the key agreement algorithms used in this document:
	dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
	x9-63-scheme 2 }		x9-63-scheme 2 }
	skipping to change at page 25, line 6 ¶		skipping to change at page 25, line 6 ¶
	When using ECMQV with EnvelopedData, AuthenticatedData, and		When using ECMQV with EnvelopedData, AuthenticatedData, and
	AuthEnvelopedData, the sending agent's ephemeral public key and		AuthEnvelopedData, the sending agent's ephemeral public key and
	additional keying material are encoded using the type:		additional keying material are encoded using the type:
	MQVuserKeyingMaterial ::= SEQUENCE {		MQVuserKeyingMaterial ::= SEQUENCE {
	ephemeralPublicKey OriginatorPublicKey,		ephemeralPublicKey OriginatorPublicKey,
	addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }		addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
	The ECPoint syntax is used to represent the ephemeral public key and		The ECPoint syntax is used to represent the ephemeral public key and
	is placed in the ephemeralPublicKey.publicKey field. The additional		is placed in the ephemeralPublicKey publicKey field. The additional
	user keying material is placed in the addedukm field. Then the		user keying material is placed in the addedukm field. Then the
	MQVuserKeyingMaterial value is DER-encoded and placed within the ukm		MQVuserKeyingMaterial value is DER-encoded and placed within the ukm
	field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData.		field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData.
	When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or		When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or
	AuthEnvelopedData, the key-encryption keys are derived by using the		AuthEnvelopedData, the key-encryption keys are derived by using the
	type:		type:
	ECC-CMS-SharedInfo ::= SEQUENCE {		ECC-CMS-SharedInfo ::= SEQUENCE {
	keyInfo AlgorithmIdentifier,		keyInfo AlgorithmIdentifier,
	skipping to change at page 28, line 45 ¶		skipping to change at page 28, line 45 ¶
	This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS-		This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS-
	ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3],		ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3],
	[HMAC-SHA1], and [HMAC-SHA2], and the appropriate security		[HMAC-SHA1], and [HMAC-SHA2], and the appropriate security
	considerations of those documents apply.		considerations of those documents apply.
	In addition, implementers of AuthenticatedData and AuthEnvelopedData		In addition, implementers of AuthenticatedData and AuthEnvelopedData
	should be aware of the concerns expressed in [BON] when using		should be aware of the concerns expressed in [BON] when using
	AuthenticatedData and AuthEnvelopedData to send messages to more than		AuthenticatedData and AuthEnvelopedData to send messages to more than
	one recipient. Also, users of MQV should be aware of the		one recipient. Also, users of MQV should be aware of the
	vulnerability in [K].		vulnerability described in [K].
	When implementing EnvelopedData, AuthenticatedData, and		When implementing EnvelopedData, AuthenticatedData, and
	AuthEnvelopedData, there are five algorithm related choices that need		AuthEnvelopedData, there are five algorithm related choices that need
	to be made:		to be made:
	1) What is the public key size?		1) What is the public key size?
	2) What is the KDF?		2) What is the KDF?
	3) What is the key wrap algorithm?		3) What is the key wrap algorithm?
	4) What is the content encryption algorithm?		4) What is the content encryption algorithm?
	5) What is the curve?		5) What is the curve?
	skipping to change at page 36, line 18 ¶		skipping to change at page 36, line 18 ¶
	structures described in this specification using ASN.1 as defined in		structures described in this specification using ASN.1 as defined in
	[X.680] for compilers that support the 1988 ASN.1.		[X.680] for compilers that support the 1988 ASN.1.
	Appendix A.2 provides an informative ASN.1 definitions for the		Appendix A.2 provides an informative ASN.1 definitions for the
	structures described in this specification using ASN.1 as defined in		structures described in this specification using ASN.1 as defined in
	[X.680], [X.681], [X.682], and [X.683] for compilers that support the		[X.680], [X.681], [X.682], and [X.683] for compilers that support the
	2002 ASN.1. This appendix contains the same information as Appendix		2002 ASN.1. This appendix contains the same information as Appendix
	A.1 in a more recent (and precise) ASN.1 notation, however Appendix		A.1 in a more recent (and precise) ASN.1 notation, however Appendix
	A.1 takes precedence in case of conflict.		A.1 takes precedence in case of conflict.
			NOTE: The values for the TBAs will be included during AUTH48.
			//** RFC Editor: Remove this note prior to publication **//
	Appendix A.1 1988 ASN.1 Module		Appendix A.1 1988 ASN.1 Module
	SMIMEECCAlgs-1988		SMIMEECCAlgs-1988
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) TBA1 }		smime(16) modules(0) TBA1 }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	skipping to change at page 37, line 12 ¶		skipping to change at page 37, line 20 ¶
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-rsa-pkalgs(33) }		id-mod-pkix1-rsa-pkalgs(33) }
	-- From [PKI-ALG]		-- From [PKI-ALG]
	id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,		id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,
	ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,		ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,
	id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters		id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters
	FROM PKIXAlgIDs-2008		FROM PKIXAlgIDs-2008
	{ 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) TBA1 }		security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 }
	-- From [CMS]		-- From [CMS]
	OriginatorPublicKey, UserKeyingMaterial		OriginatorPublicKey, UserKeyingMaterial
	FROM CryptographicMessageSyntax2004		FROM CryptographicMessageSyntax2004
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) cms-2004(24) }		smime(16) modules(0) cms-2004(24) }
	-- From [CMS-ALG]		-- From [CMS-ALG]
	hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384,		hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384,
	id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter		id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter
	FROM CryptographicMessageSyntaxAlgorithms		FROM CryptographicMessageSyntaxAlgorithms
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) cmsalg-2008(TBD) }		smime(16) modules(0) cmsalg-2008(TBA3) }
	-- From [CMS-AES]		-- From [CMS-AES]
	id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,		id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,
	id-aes128-wrap, id-aes192-wrap, id-aes256-wrap		id-aes128-wrap, id-aes192-wrap, id-aes256-wrap
	FROM CMSAesRsaesOaep		FROM CMSAesRsaesOaep
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) id-mod-cms-aes(19) }		smime(16) modules(0) id-mod-cms-aes(19) }
	-- From [CMS-AESCG]		-- From [CMS-AESCG]
	skipping to change at page 43, line 20 ¶		skipping to change at page 43, line 20 ¶
	-- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm		-- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm
	-- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm		-- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm
	-- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm		-- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm
	END		END
	Appendix A.2 2004 ASN.1 Module		Appendix A.2 2004 ASN.1 Module
	SMIMEECCAlgs-2008		SMIMEECCAlgs-2008
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) TBA2 }		smime(16) modules(0) TBA4 }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL		-- EXPORTS ALL
	IMPORTS		IMPORTS
	-- From [PKI-ALG]		-- From [PKI-ALG]
	mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,		mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,
	sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,		sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,
	ECDSA-Sig-Value, ECPoint, ECParameters		ECDSA-Sig-Value, ECPoint, ECParameters
	FROM PKIXAlgIDs-2008		FROM PKIXAlgIDs-2008
	{ 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) TBA2 }		security(5) mechanisms(5) pkix(7) id-mod(0) TBA5 }
	-- FROM [PKI-ASN]		-- FROM [PKI-ASN]
	KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,		KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,
	PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE		PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE
	FROM AlgorithmInformation		FROM AlgorithmInformation
	{ 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(TBA5) }		id-mod-algorithmInformation(TBA6) }
	-- From [PKI-ASN]		-- From [PKI-ASN]
	mda-sha224, mda-sha256, mda-sha384, mda-sha512		mda-sha224, mda-sha256, mda-sha384, mda-sha512
	FROM PKIX1-PSS-OAEP-Algorithms		FROM PKIX1-PSS-OAEP-Algorithms
	{ 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) TBA7 }		security(5) mechanisms(5) pkix(7) id-mod(0) TBA7 }
	-- From [CMS]		-- From [CMS]
	skipping to change at page 45, line 41 ¶		skipping to change at page 45, line 41 ¶
	-- ECDSA-Sig-Value ::= SEQUENCE {		-- ECDSA-Sig-Value ::= SEQUENCE {
	-- r INTEGER,		-- r INTEGER,
	-- s INTEGER		-- s INTEGER
	-- }		-- }
	--		--
	-- Key Agreement Algorithms		-- Key Agreement Algorithms
	--		--
	-- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo		-- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
	-- keyEncryption Algorithm field		-- keyEncryption Algorithm field
	-- Constrains the AuthenticatedData RecipientInfo		-- Constrains the AuthenticatedData RecipientInfo
	-- KeyAgreeRecipientInfo keyEncryption Algorithm field		-- KeyAgreeRecipientInfo keyEncryption Algorithm field
	-- Constrains the AuthEnvelopedData RecipientInfo		-- Constrains the AuthEnvelopedData RecipientInfo
	-- KeyAgreeRecipientInfo keyEncryption Algorithm field		-- KeyAgreeRecipientInfo keyEncryption Algorithm field
	-- DH variants are not used with AuthenticatedData or		-- DH variants are not used with AuthenticatedData or
	-- AuthEnvelopedData		-- AuthEnvelopedData
	KeyAgreementAlgs KEY-AGREE ::= {		KeyAgreementAlgs KEY-AGREE ::= {
	kaa-dhSinglePass-stdDH-sha1kdf-scheme |		kaa-dhSinglePass-stdDH-sha1kdf-scheme |
	kaa-dhSinglePass-stdDH-sha224kdf-scheme |		kaa-dhSinglePass-stdDH-sha224kdf-scheme |
	kaa-dhSinglePass-stdDH-sha256kdf-scheme |		kaa-dhSinglePass-stdDH-sha256kdf-scheme |
	kaa-dhSinglePass-stdDH-sha384kdf-scheme |		kaa-dhSinglePass-stdDH-sha384kdf-scheme |
	kaa-dhSinglePass-stdDH-sha512kdf-scheme |		kaa-dhSinglePass-stdDH-sha512kdf-scheme |
	kaa-dhSinglePass-cofactorDH-sha1kdf-scheme |		kaa-dhSinglePass-cofactorDH-sha1kdf-scheme |
	skipping to change at page 46, line 39 ¶		skipping to change at page 46, line 39 ¶
	--		--
	-- Diffie-Hellman Single Pass, Standard, with KDFs		-- Diffie-Hellman Single Pass, Standard, with KDFs
	--		--
	-- Parameters are always present and indicate the Key Wrap Algorithm		-- Parameters are always present and indicate the Key Wrap Algorithm
	kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme		IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme }		IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme }
	}		}
	dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
	x9-63-scheme 2 }		x9-63-scheme 2 }
	kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme		IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme }		IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme }
	}		}
	dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 11 0 }		secg-scheme 11 0 }
	kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme		IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme }		IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme }
	}		}
	dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 11 1 }		secg-scheme 11 1 }
	kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme		IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme }		IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme }
	}		}
	dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 11 2 }		secg-scheme 11 2 }
	kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme		IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme }		IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme }
	}		}
	dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 11 3 }		secg-scheme 11 3 }
	--		--
	-- Diffie-Hellman Single Pass, Cofactor, with KDFs		-- Diffie-Hellman Single Pass, Cofactor, with KDFs
	--		--
	kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme		IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme }		IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme }
	}		}
	dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
	x9-63-scheme 3 }		x9-63-scheme 3 }
	kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme		IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY		IDENTIFIED BY
	dhSinglePass-cofactorDH-sha224kdf-scheme }		dhSinglePass-cofactorDH-sha224kdf-scheme }
	}		}
	dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 14 0 }		secg-scheme 14 0 }
	kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme		IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY		IDENTIFIED BY
	dhSinglePass-cofactorDH-sha256kdf-scheme }		dhSinglePass-cofactorDH-sha256kdf-scheme }
	}		}
	dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 14 1 }		secg-scheme 14 1 }
	kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme		IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY		IDENTIFIED BY
	dhSinglePass-cofactorDH-sha384kdf-scheme }		dhSinglePass-cofactorDH-sha384kdf-scheme }
	}		}
	dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 14 2 }		secg-scheme 14 2 }
	kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {		kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {
	IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme		IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY		IDENTIFIED BY
	dhSinglePass-cofactorDH-sha512kdf-scheme }		dhSinglePass-cofactorDH-sha512kdf-scheme }
	}		}
	dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {		dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 14 3 }		secg-scheme 14 3 }
	--		--
	-- MQV Single Pass, Cofactor, with KDFs		-- MQV Single Pass, Cofactor, with KDFs
	--		--
	kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {		kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {
	IDENTIFIER mqvSinglePass-sha1kdf-scheme		IDENTIFIER mqvSinglePass-sha1kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY mqvSinglePass-sha1kdf-scheme }		IDENTIFIED BY mqvSinglePass-sha1kdf-scheme }
	}		}
	mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {		mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
	x9-63-scheme 16 }		x9-63-scheme 16 }
	kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {		kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {
	IDENTIFIER mqvSinglePass-sha224kdf-scheme		IDENTIFIER mqvSinglePass-sha224kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY mqvSinglePass-sha224kdf-scheme }		IDENTIFIED BY mqvSinglePass-sha224kdf-scheme }
	}		}
	mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {		mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 15 0 }		secg-scheme 15 0 }
	kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {		kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {
	IDENTIFIER mqvSinglePass-sha256kdf-scheme		IDENTIFIER mqvSinglePass-sha256kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY mqvSinglePass-sha256kdf-scheme }		IDENTIFIED BY mqvSinglePass-sha256kdf-scheme }
	}		}
	mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {		mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 15 1 }		secg-scheme 15 1 }
	kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {		kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {
	IDENTIFIER mqvSinglePass-sha384kdf-scheme		IDENTIFIER mqvSinglePass-sha384kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY mqvSinglePass-sha384kdf-scheme }		IDENTIFIED BY mqvSinglePass-sha384kdf-scheme }
	}		}
	mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {		mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 15 2 }		secg-scheme 15 2 }
	kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {		kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {
	IDENTIFIER mqvSinglePass-sha512kdf-scheme		IDENTIFIER mqvSinglePass-sha512kdf-scheme
	PARAMS TYPE KeyWrapAlgorithm ARE required		PARAMS TYPE KeyWrapAlgorithm ARE required
	UKM TYPE -- unecndoded data -- IS preferredPresent		UKM TYPE -- unencoded data -- IS preferredPresent
	SMIME CAPS { TYPE KeyWrapAlgorithm		SMIME CAPS { TYPE KeyWrapAlgorithm
	IDENTIFIED BY mqvSinglePass-sha512kdf-scheme }		IDENTIFIED BY mqvSinglePass-sha512kdf-scheme }
	}		}
	mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {		mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
	secg-scheme 15 3 }		secg-scheme 15 3 }
	--		--
	-- Key Wrap Algorithms		-- Key Wrap Algorithms
	--		--
	skipping to change at page 51, line 41 ¶		skipping to change at page 51, line 41 ¶
	--		--
	-- Message Authentication Code Algorithms		-- Message Authentication Code Algorithms
	--		--
	-- Constrains the AuthenticatedData		-- Constrains the AuthenticatedData
	-- MessageAuthenticationCodeAlgorithm field		-- MessageAuthenticationCodeAlgorithm field
	--		--
	-- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= {		-- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= {
	-- maca-sha1 |		-- maca-hMAC-SHA1 |
	-- maca-sha224 |		-- maca-hMAC-SHA224 |
	-- maca-sha256 |		-- maca-hMAC-SHA256 |
	-- maca-sha384 |		-- maca-hMAC-SHA384 |
	-- maca-sha512,		-- maca-hMAC-SHA512,
	-- ... -- Extensible		-- ... -- Extensible
	-- }		-- }
	--		--
	-- Originator Public Key Algorithms		-- Originator Public Key Algorithms
	--		--
	-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey		-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey
	-- OriginatorPublicKey algorithm field		-- OriginatorPublicKey algorithm field
	-- PARAMS are NULL		-- PARAMS are NULL
	skipping to change at page 53, line 21 ¶		skipping to change at page 53, line 21 ¶
	}		}
	END		END
	Appendix B Changes since RFC 3278		Appendix B Changes since RFC 3278
	The following summarizes the changes:		The following summarizes the changes:
	- Abstract: The basis of the document was changed to refer to NIST		- Abstract: The basis of the document was changed to refer to NIST
	FIPS 186-3 and SP800-56A. However, to maintain backwards		FIPS 186-3 and SP800-56A. However, to maintain backwards
	capability the Key Derivation Function from ANSI/SEC1 is		compatibility the Key Derivation Function from ANSI/SEC1 is
	retained.		retained.
	- Section 1: A bullet was added to address AuthEnvelopedData.		- Section 1: A bullet was added to address AuthEnvelopedData.
	- Section 2.1: A sentence was added to indicate FIPS180-3 is used		- Section 2.1: A sentence was added to indicate FIPS180-3 is used
	with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3.		with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3.
	- Section 2.1.1: The permitted digest algorithms were expanded from		- Section 2.1.1: The permitted digest algorithms were expanded from
	SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.		SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
	- Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was		- Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was
	deleted.		deleted.
	- Section 3: Added explanation of why static-static ECDH is not		- Section 3: Added explanation of why static-static ECDH is not
	included.		included.
	- Section 3.1: The reference for DH was changed from CMS to CMS-		- Section 3.1: The reference for DH was changed from RFC 3852 to
	ALG. Provided text to indicate fields of EnvelopedData are as		RFC 3370. Provided text to indicate fields of EnvelopedData are
	in CMS.		as in CMS.
	- Section 3.1.1: The text was updated to include description of all		- Section 3.1.1: The text was updated to include description of all
	KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey		KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey
	field changed from NULL to absent or ECParameter. Additional		field changed from NULL to absent or ECParameter. Additional
	information about ukm was added.		information about ukm was added.
	- Section 3.2: The sentence describing the advantages of 1-Pass		- Section 3.2: The sentence describing the advantages of 1-Pass
	ECMQV was rewritten.		ECMQV was rewritten.
	- Section 3.2.1: The text was updated to include description of all		- Section 3.2.1: The text was updated to include description of all
	skipping to change at page 54, line 46 ¶		skipping to change at page 54, line 46 ¶
	224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF.		224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF.
	- Section 7.1 (formerly 8.1): Added sub-sections for digest,		- Section 7.1 (formerly 8.1): Added sub-sections for digest,
	signature, originator public key, key agreement, content		signature, originator public key, key agreement, content
	encryption, key wrap, and message authentication code		encryption, key wrap, and message authentication code
	algorithms. Pointed to algorithms and parameters in appropriate		algorithms. Pointed to algorithms and parameters in appropriate
	documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as		documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as
	SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added		SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added
	algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV		algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV
	with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the		with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the
	KDF. Changed id-ecPublicKey parameters to be absent, NULL, and		KDF. Changed id-ecPublicKey parameters to be absent, NULL, or
	ECParameters and if present the originator's ECParameters must		ECParameters, and if present the originator's ECParameters must
	match the recipient's ECParameters.		match the recipient's ECParameters.
	- Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData.		- Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData.
	Also, added text to address support requirement for compressed,		Also, added text to address support requirement for compressed,
	uncompressed, and hybrid keys, changed pointers from ANSI X9.61		uncompressed, and hybrid keys, changed pointers from ANSI X9.61
	to PKIX (where ECDSA-Sig-Value is imported), changed pointers		to PKIX (where ECDSA-Sig-Value is imported), changed pointers
	from SECG to NIST specs, and updated example of suppPubInfo to		from SECG to NIST specs, and updated example of suppPubInfo to
	be AES-256. keyInfo's parameters changed from NULL to any		be AES-256. keyInfo's parameters changed from NULL to any
	associated parameters (AES wraps have absent parameters).		associated parameters (AES wraps have absent parameters).
	skipping to change at page 57, line 4 ¶		skipping to change at line 2421 ¶
	Email: turners@ieca.com		Email: turners@ieca.com
	Daniel R. L. Brown		Daniel R. L. Brown
	Certicom Corp		Certicom Corp
	5520 Explorer Drive #400		5520 Explorer Drive #400
	Mississauga, ON L4W 5L1		Mississauga, ON L4W 5L1
	CANADA		CANADA
	Email: dbrown@certicom.com		Email: dbrown@certicom.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 51 change blocks.
	66 lines changed or deleted		76 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/