< draft-ietf-smime-3278bis-05.txt		draft-ietf-smime-3278bis-06.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 January 5, 2009		Intended Status: Informational April 14, 2009
	Obsoletes: 3278 (once approved)		Obsoletes: 3278 (once approved)
	Expires: July 5, 2009		Expires: October 14, 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-05.txt		draft-ietf-smime-3278bis-06.txt
	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. This document may contain material
			from IETF Documents or IETF Contributions published or made publicly
			available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	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 5, 2008.		This Internet-Draft will expire on October 14, 2009.
	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		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	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 28 ¶		skipping to change at page 2, line 39 ¶
	Discussion		Discussion
	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..................................4
	2. SignedData using ECC...........................................3		2. SignedData using ECC...........................................4
	2.1. SignedData using ECDSA....................................4		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..........................8
	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.....................11
	4.2. AuthEnvelopedData using 1-pass ECMQV.....................11		4.2. AuthEnvelopedData using 1-pass ECMQV.....................12
	5. Certificates using ECC........................................12		5. Certificates using ECC........................................13
	6. SMIMECapabilities Attribute and ECC...........................12		6. SMIMECapabilities Attribute and ECC...........................13
	7. ASN.1 Syntax..................................................20		7. ASN.1 Syntax..................................................21
	7.1. Algorithm Identifiers....................................20		7.1. Algorithm Identifiers....................................21
	7.2. Other Syntax.............................................24		7.2. Other Syntax.............................................24
	8. Recommended Algorithms and Elliptic Curves....................25		8. Recommended Algorithms and Elliptic Curves....................26
	9. Security Considerations.......................................28		9. Security Considerations.......................................28
	10. IANA Considerations..........................................33		10. IANA Considerations..........................................33
	11. References...................................................33		11. References...................................................33
	11.1. Normative...............................................33		11.1. Normative...............................................33
	11.2. Informative.............................................35		11.2. Informative.............................................35
	Appendix A ASN.1 Modules.........................................36		Appendix A ASN.1 Modules.........................................36
	Appendix A.1 1988 ASN.1 Module................................36		Appendix A.1 1988 ASN.1 Module................................36
	Appendix A.2 2004 ASN.1 Module................................43		Appendix A.2 2004 ASN.1 Module................................43
	Appendix B Changes since RFC 3278................................53		Appendix B Changes since RFC 3278................................53
	Acknowledgements.................................................56		Acknowledgements.................................................56
	Author's Addresses...............................................56		Authors' Addresses...............................................56
	1. Introduction		1. Introduction
	The Cryptographic Message Syntax (CMS) is cryptographic algorithm		The Cryptographic Message Syntax (CMS) is cryptographic algorithm
	independent. This specification defines a profile for the use of		independent. This specification defines a profile for the use of
	Elliptic Curve Cryptography (ECC) public key algorithms in the CMS.		Elliptic Curve Cryptography (ECC) public key algorithms in the CMS.
	The ECC algorithms are incorporated into the following CMS content		The ECC algorithms are incorporated into the following CMS content
	types:		types:
	- 'SignedData' to support ECC-based digital signature methods		- 'SignedData' to support ECC-based digital signature methods
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 39 ¶
	When using ECDSA with SignedData, the fields of SignerInfo are as in		When using ECDSA with SignedData, the fields of SignerInfo are as in
	[CMS], but with the following restrictions:		[CMS], but with the following restrictions:
	- digestAlgorithm MUST contain the algorithm identifier of the hash		- digestAlgorithm MUST contain the algorithm identifier of the hash
	algorithm (see Section 7.1.1) which MUST be one of the		algorithm (see Section 7.1.1) which MUST be one of the
	following: id-sha1, id-sha224, id-sha256, id-sha384, or id-		following: id-sha1, id-sha224, id-sha256, id-sha384, or id-
	sha512.		sha512.
	- signatureAlgorithm contains the signature algorithm identifier		- signatureAlgorithm contains the signature algorithm identifier
	(see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-		(see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-
	with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512.		with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. The hash
			algorithm identified in the name of the signature algorithm MUST
			be the same as the digestAlgorithm (e.g., digestAlgorithm is id-
			sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).
	- signature MUST contain the DER encoding (as an octet string) of a		- signature MUST contain the DER encoding (as an octet string) of a
	value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).		value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).
	When using ECDSA, the SignedData certificates field MAY include the		When using ECDSA, the SignedData certificates field MAY include the
	certificate(s) for the EC public key(s) used in the generation of the		certificate(s) for the EC public key(s) used in the generation of the
	ECDSA signatures in SignedData. ECC certificates are discussed in		ECDSA signatures in SignedData. ECC certificates are discussed in
	Section 5.		Section 5.
	2.1.2. Actions of the sending agent		2.1.2. Actions of the sending agent
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 17 ¶
	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.2). The parameters
	associated with id-ecPublicKey MUST be absent or ECParameters.		associated with id-ecPublicKey MUST be absent, ECParameters, or
	NOTE: The previous version of this document required NULL to be		NULL. The parameters associated with id-ecPublicKey SHOULD be
	present; support for this legacy form is OPTIONAL. The		absent or ECParameters, and NULL is allowed to support legacy
	originatorKey publicKey field MUST contain the value of the		implementations. The previous version of this document required
	ASN.1 type ECPoint (see Section 7.2), which represents the		NULL to be present. If the parameters are ECParameters, then
	sending agent's ephemeral EC public key. The ECPoint in		they MUST be namedCurve. The originatorKey publicKey field MUST
	uncompressed form MUST be supported.		contain the value of the ASN.1 type ECPoint (see Section 7.2),
			which represents the sending agent's ephemeral EC public key.
			The ECPoint in 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
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 29 ¶
	"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 hash 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 originatorKey
			publicKey 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].
	In a single message, if there are multiple layers for a recipient,		In a single message, if there are multiple layers for a recipient,
	then the ephemeral public key can be reused by the originator for		then the ephemeral public key can be reused by the originator for
	that recipient in each of the different layers.		that recipient in each of the different layers.
	3.1.3. Actions of the receiving agent		3.1.3. Actions of the receiving agent
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 49 ¶
	- originator identifies the static EC public key of the sender. It		- originator identifies the static EC public key of the sender. It
	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.2). The parameters associated with
	id-ecPublicKey MUST be absent or ECParameters. NOTE: The		id-ecPublicKey MUST be absent, ECParameters, or NULL. The
	previous version of this document required NULL to be present;		parameters associated with id-ecPublicKey SHOULD be absent or
	support for this legacy form is OPTIONAL. The		ECParameters, as NULL is allowed to support legacy
	MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST		implementations. The previous version of this document required
	contain the DER-encoding of the ASN.1 type ECPoint (see Section		NULL to be present. If the parameters are ECParameters, then
	7.2) representing the sending agent's ephemeral EC public key.		they MUST be namedCurve. The MQVuserKeyingMaterial
	The MQVuserKeyingMaterial addedukm field, if present, contains		ephemeralPublicKey publicKey field MUST contain the DER-encoding
			of the ASN.1 type ECPoint (see Section 7.2) representing the
			sending agent's ephemeral EC public key. 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 object identifier of the		- keyEncryptionAlgorithm MUST contain the object identifier of the
	key encryption algorithm, which in this case is a key agreement		key encryption algorithm, which in this case is a key agreement
	algorithm (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.
	skipping to change at page 12, line 6 ¶		skipping to change at page 12, line 34 ¶
	The receiving agent uses the same actions as for EnvelopedData with		The receiving agent uses the same actions as for EnvelopedData with
	1-Pass ECMQV, as specified in Section 3.2.3 of this document.		1-Pass ECMQV, as specified in Section 3.2.3 of this document.
	4.2. AuthEnvelopedData using 1-pass ECMQV		4.2. AuthEnvelopedData using 1-pass ECMQV
	This section describes how to use the 1-Pass elliptic curve MQV		This section describes how to use the 1-Pass elliptic curve MQV
	(ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is		(ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is
	method C(1, 2, ECC MQV) from [SP800-56A].		method C(1, 2, ECC MQV) from [SP800-56A].
	When using ECMQV with AuthEnvelopedData, the fields of		When using ECMQV with AuthEnvelopedData, the fields of
	AuthenticatedData are as in [CMS-AUTHENV].		AuthEnvelopedData are as in [CMS-AUTHENV].
	As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari		As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari
	choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData		choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData
	originatorInfo field MAY include the certificate(s) for the EC public		originatorInfo field MAY include the certificate(s) for the EC public
	key used in the formation of the pairwise key. ECC certificates are		key used in the formation of the pairwise key. ECC certificates are
	discussed in Section 5.		discussed in Section 5.
	4.2.1. Fields of the KeyAgreeRecipientInfo		4.2.1. Fields of the KeyAgreeRecipientInfo
	The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the		The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the
	skipping to change at page 13, line 18 ¶		skipping to change at page 14, line 6 ¶
	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 SMIMECapabilities 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 and
	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,
	b) dhSinglePass-cofactorDH-sha*kdf-scheme, or		b) dhSinglePass-cofactorDH-sha*kdf-scheme, or
	c) mqvSinglePass-sha*kdf-scheme		c) mqvSinglePass-sha*kdf-scheme
	respectively (where * is 1, 224, 256, 384, or 512) with the		respectively (where * is 1, 224, 256, 384, or 512) with the
	parameters present. The parameters indicate the supported key-		parameters present. The parameters indicate the supported key-
	encryption algorithm with the KeyWrapAlgorithm algorithm identifier.		encryption algorithm with the KeyWrapAlgorithm algorithm identifier.
	The DER encodings that indicate capabilities are as follows (KA is		The DER encodings that indicate capabilities are as follows (KA is
	skipping to change at page 14, line 22 ¶		skipping to change at page 15, line 7 ¶
	30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES		KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES
	30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECDH standard KDF=SHA-1 Wrap=AES-128		KA=ECDH standard KDF=SHA-1 Wrap=AES-128
	30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
	65 03 04 01 05 05 00		65 03 04 01 05
	KA=ECDH standard KDF=SHA-224 Wrap=AES-128		KA=ECDH standard KDF=SHA-224 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH standard KDF=SHA-256 Wrap=AES-128		KA=ECDH standard KDF=SHA-256 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH standard KDF=SHA-384 Wrap=AES-128		KA=ECDH standard KDF=SHA-384 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH standard KDF=SHA-512 Wrap=AES-128		KA=ECDH standard KDF=SHA-512 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH standard KDF=SHA-1 Wrap=AES-192		KA=ECDH standard KDF=SHA-1 Wrap=AES-192
	30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
	65 03 04 01 2D 05 00		65 03 04 01 19
	KA=ECDH standard KDF=SHA-224 Wrap=AES-192		KA=ECDH standard KDF=SHA-224 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 19
	KA=ECDH standard KDF=SHA-256 Wrap=AES-192		KA=ECDH standard KDF=SHA-256 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 19
	KA=ECDH standard KDF=SHA-384 Wrap=AES-192		KA=ECDH standard KDF=SHA-384 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 19
	KA=ECDH standard KDF=SHA-512 Wrap=AES-192		KA=ECDH standard KDF=SHA-512 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 19
	KA=ECDH standard KDF=SHA-1 Wrap=AES-256		KA=ECDH standard KDF=SHA-1 Wrap=AES-256
	30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
	65 03 04 01 2D 05 00		65 03 04 01 2D
	KA=ECDH standard KDF=SHA-224 Wrap=AES-256		KA=ECDH standard KDF=SHA-224 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH standard KDF=SHA-256 Wrap=AES-256		KA=ECDH standard KDF=SHA-256 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH standard KDF=SHA-384 Wrap=AES-256		KA=ECDH standard KDF=SHA-384 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D 05 00
	KA=ECDH standard KDF=SHA-512 Wrap=AES-256		KA=ECDH standard KDF=SHA-512 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES		KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES
	30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86		30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86
	f7 0d 01 09 10 03 06 05 00		f7 0d 01 09 10 03 06 05 00
	KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES		KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES
	30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	skipping to change at page 16, line 32 ¶		skipping to change at page 17, line 17 ¶
	30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES		KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES
	30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128		KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128
	30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
	65 03 04 01 05 05 00		65 03 04 01 05
	KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128		KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128		KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128		KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128		KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04		30 17 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192		KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192
	30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
	65 03 04 01 19 05 00		65 03 04 01 19
	KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192		KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192		KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192		KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192		KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256		KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256
	30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01		30 15 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
	65 03 04 01 2D 05 00		65 03 04 01 2D
	KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256		KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256		KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256		KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256		KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES		KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES
	30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86		30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86
	f7 0d 01 09 10 03 06 05 00		f7 0d 01 09 10 03 06 05 00
	KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES		KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES
	30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	skipping to change at page 18, line 42 ¶		skipping to change at page 19, line 27 ¶
	30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES		KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES
	30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01		30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
	09 10 03 06 05 00		09 10 03 06 05 00
	KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128		KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128
	30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
	65 03 04 01 05 05 00		65 03 04 01 05
	KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128		KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128		KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05
	KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128		KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05 05 00
	KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128		KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128
	30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04
	01 05 05 00		01 05 05 00
	KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192		KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192
	30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
	65 03 04 01 2D 05 00		65 03 04 01 19
	KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192		KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192		KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192		KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192		KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192
	30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
	01 19 05 00		01 19
	KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256		KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256
	30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01		30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
	65 03 04 01 2D 05 00		65 03 04 01 2D
	KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256		KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256		KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256		KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256		KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256
	30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04		30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
	01 2D 05 00		01 2D
	NOTE: The S/MIME Capabilities indicate that parameters for the key		NOTE: The S/MIME Capabilities indicate that parameters for the key
	wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however,		wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however,
	the parameters are absent when used to encrypt/decrypt a content		the parameters are absent when used to encrypt/decrypt a content
	encryption key.		encryption key.
	NOTE: The S/MIME Capabilities for the supported AES content		NOTE: The S/MIME Capabilities for the supported AES content
	encryption key sizes are defined in [CMS-AES].		encryption key sizes are defined in [CMS-AES].
	NOTE: The S/MIME Capabilities for the supported MAC algorithms are		NOTE: The S/MIME Capabilities for the supported MAC algorithms are
	skipping to change at page 24, line 12 ¶		skipping to change at page 24, line 29 ¶
	The object identifiers and parameters associated with these		The object identifiers and parameters associated with these
	algorithms are found in [CMS-AESCG].		algorithms are found in [CMS-AESCG].
	7.1.7. Message Authentication Code Algorithms		7.1.7. Message Authentication Code Algorithms
	Message authentication code algorithms are used in AuthenticatedData		Message authentication code algorithms are used in AuthenticatedData
	in the macAlgorithm field. The message authentication code		in the macAlgorithm field. The message authentication code
	algorithms used in this document are HMAC with SHA-1, HMAC with SHA-		algorithms used in this document are HMAC with SHA-1, HMAC with SHA-
	224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512.		224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512.
	The object identifiers and parameters associated with these		The object identifiers and parameters associated with these
	algorithms are found in [HMAC-SHA1] and [HMAC-SHA2].		algorithms are found in [CMS-ALG] and [HMAC-SHA2].
	7.1.8. Key Derivation Algorithm		7.1.8. Key Derivation Algorithm
	The KDF used in this document is as specified in 3.6.1 of [SEC1].		The KDF used in this document is as specified in 3.6.1 of [SEC1].
	The hash algorithm is identified in key agreement algorithm. For		The hash algorithm is identified in key agreement algorithm. For
	example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1]		example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1]
	but uses SHA-256 instead of SHA-1.		but uses SHA-256 instead of SHA-1.
	7.2. Other Syntax		7.2. Other Syntax
	skipping to change at page 27, line 46 ¶		skipping to change at page 28, line 17 ¶
	Implementations that support AuthEnvelopedData with 1-Pass ECMQV:		Implementations that support AuthEnvelopedData with 1-Pass ECMQV:
	- MUST support the mqvSinglePass-sha256kdf-scheme key agreement,		- MUST support the mqvSinglePass-sha256kdf-scheme key agreement,
	the id-aes128-wrap key wrap, and the id-aes128-ccm		the id-aes128-wrap key wrap, and the id-aes128-ccm
	authenticated-content encryption; and,		authenticated-content encryption; and,
	- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-		- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-
	sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and		sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and
	mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id-		mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id-
	alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap		alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap
	algorithms, the id-aes192-ccm and id-aes256-ccm authenticated-		algorithms, the id-aes192-ccm, id-aes256-ccm, id-aes128-gcm, id-
	content encryption algorithms; other algorithms MAY also be		aes192-gcm, and id-aes256-ccm authenticated-content encryption
	supported.		algorithms; other algorithms MAY also be supported.
	9. Security Considerations		9. Security Considerations
	Cryptographic algorithms will be broken or weakened over time.		Cryptographic algorithms will be broken or weakened over time.
	Implementers and users need to check that the cryptographic		Implementers and users need to check that the cryptographic
	algorithms listed in this document continue to provide the expected		algorithms listed in this document continue to provide the expected
	level of security. The IETF from time to time may issue documents		level of security. The IETF from time to time may issue documents
	dealing with the current state of the art.		dealing with the current state of the art.
	Cryptographic algorithms rely on random numbers. See [RANDOM] for		Cryptographic algorithms rely on random numbers. See [RANDOM] for
	skipping to change at page 28, line 35 ¶		skipping to change at page 29, line 4 ¶
	sort of cryptographic resource management system to prevent such		sort of cryptographic resource management system to prevent such
	attacks.		attacks.
	Using secret keys of an appropriate size is crucial to the security		Using secret keys of an appropriate size is crucial to the security
	of a Diffie-Hellman exchange. For elliptic curve groups, the size of		of a Diffie-Hellman exchange. For elliptic curve groups, the size of
	the secret key must be equal to the size of n (the order of the group		the secret key must be equal to the size of n (the order of the group
	generated by the point g). Using larger secret keys provides		generated by the point g). Using larger secret keys provides
	absolutely no additional security, and using smaller secret keys is		absolutely no additional security, and using smaller secret keys is
	likely to result in dramatically less security. (See [SP800-56A] for		likely to result in dramatically less security. (See [SP800-56A] for
	more information on selecting secret keys.)		more information on selecting secret keys.)
	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		and [HMAC-SHA2], and the appropriate security considerations of those
	considerations of those documents apply.		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 described 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?
	Consideration must be given to strength of the security provided by		Consideration must be given to the strength of the security provided
	each of these choices. Security is measured in bits, where a strong		by each of these choices. Security is measured in bits, where a
	symmetric cipher with a key of X bits is said to provide X bits of		strong symmetric cipher with a key of X bits is said to provide X
	security. It is recommended that the bits of security provided by		bits of security. It is recommended that the bits of security
	each are roughly equivalent. The following table provides comparable		provided by each are roughly equivalent. The following table provides
	minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes,		comparable minimum bits of security [SP800-57] for the ECDH/ECMQV key
	KDFs, key wrapping algorithms, and content encryption algorithms. It		sizes, KDFs, key wrapping algorithms, and content encryption
	also lists curves [PKI-ALG] for the key sizes.		algorithms. It also lists curves [PKI-ALG] for the key sizes.
	Minimum | ECDH or | Key | Key | Content | Curves		Minimum | ECDH or | Key | Key | Content | Curves
	Bits of | ECQMV | Derivation | Wrap | Encryption |		Bits of | ECQMV | Derivation | Wrap | Encryption |
	Security | Key Size | Function | Alg. | Alg. |		Security | Key Size | Function | Alg. | Alg. |
	---------+----------+------------+----------+-------------+----------		---------+----------+------------+----------+-------------+----------
	80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1		80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1
	| | SHA-224 | AES-128 | AES-128 CBC | secp163r2		| | SHA-224 | AES-128 | AES-128 CBC | secp163r2
	| | SHA-256 | AES-192 | AES-192 CBC | secp192r1		| | SHA-256 | AES-192 | AES-192 CBC | secp192r1
	| | SHA-384 | AES-256 | AES-256 CBC |		| | SHA-384 | AES-256 | AES-256 CBC |
	| | SHA-512 | | |		| | SHA-512 | | |
	skipping to change at page 34, line 9 ¶		skipping to change at page 34, line 9 ¶
	progress.		progress.
	[FIPS180-3] National Institute of Standards and Technology		[FIPS180-3] National Institute of Standards and Technology
	(NIST), FIPS Publication 180-3: Secure Hash Standard,		(NIST), FIPS Publication 180-3: Secure Hash Standard,
	October 2008.		October 2008.
	[FIPS186-3] National Institute of Standards and Technology		[FIPS186-3] National Institute of Standards and Technology
	(NIST), FIPS Publication 186-3: Digital Signature		(NIST), FIPS Publication 186-3: Digital Signature
	Standard, (draft) November 2008.		Standard, (draft) November 2008.
	[HMAC-SHA1] Krawczyk, M., Bellare, M., and R. Canetti, "HMAC:
	Keyed-Hashing for Message Authentication", RFC 2104,
	February 1997.
	[HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC-		[HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC-
	SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-		SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-
	512", RFC 4231, December 2005.		512", RFC 4231, December 2005.
	[MUST] Bradner, S., "Key Words for Use in RFCs to Indicate		[MUST] Bradner, S., "Key Words for Use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2		[MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
	Message Specification", draft-ietf-smime-3851bis,		Message Specification", draft-ietf-smime-3851bis,
	work-in-progress.		work-in-progress.
	[PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.		[PKI] Cooper, D., Santesson, S., Farrell, 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		Infrastructure Certificate and Certificate Revocation
	List (CRL) Profile", RFC 5280, May 2008.		List (CRL) Profile", RFC 5280, May 2008.
	[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W.		[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W.
	Polk, "Elliptic Curve Cryptography Subject Public Key		Polk, "Elliptic Curve Cryptography Subject Public Key
	Information", draft-ietf-pkix-ecc-subpubkeyinfo,		Information", RFC 5480, March 2009.
	work-in-progress.
	[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,		[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
	"Randomness Recommendations for Security", RFC 4086,		"Randomness Recommendations for Security", RFC 4086,
	June 2005.		June 2005.
	[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for		Algorithms and Identifiers for RSA Cryptography for
	use in the Internet X.509 Public Key Infrastructure		use in the Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL)		Certificate and Certificate Revocation List (CRL)
	Profile", RFC 4055, June 2005.		Profile", RFC 4055, June 2005.
	skipping to change at page 37, line 20 ¶		skipping to change at page 37, line 12 ¶
	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) TBA2 }		security(5) mechanisms(5) pkix(7) id-mod(0) TBA1 }
	-- 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(TBA3) }		smime(16) modules(0) cmsalg-2008(TBD) }
	-- 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) TBA4 }		smime(16) modules(0) TBA2 }
	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) TBA5 }		security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 }
	-- 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(TBA6) }		id-mod-algorithmInformation(TBA5) }
	-- 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 48, line 14 ¶		skipping to change at page 48, line 14 ¶
	--		--
	-- 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 -- unencoded 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 -- unencoded 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 -- unencoded 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 -- unencoded 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 -- unencoded 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 ::= {
	skipping to change at page 56, line 20 ¶		skipping to change at page 56, line 20 ¶
	de Rooij for his patient assistance. The technical comments of		de Rooij for his patient assistance. The technical comments of
	Francois Rousseau were valuable contributions.		Francois Rousseau were valuable contributions.
	Many thanks go out to the other authors of RFC 3278: Simon Blake-		Many thanks go out to the other authors of RFC 3278: Simon Blake-
	Wilson and Paul Lambert. Without RFC 3278 this version wouldn't		Wilson and Paul Lambert. Without RFC 3278 this version wouldn't
	exist.		exist.
	The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ		The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ
	Housley, and Jim Schaad for their valuable input.		Housley, and Jim Schaad for their valuable input.
	Author's Addresses		Authors' Addresses
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	3057 Nutley Street, Suite 106		3057 Nutley Street, Suite 106
	Fairfax, VA 22031		Fairfax, VA 22031
	USA		USA
	Email: turners@ieca.com		Email: turners@ieca.com
End of changes. 84 change blocks.
	163 lines changed or deleted		176 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/