< draft-turner-cmc-serverkeygeneration-00.txt		draft-turner-cmc-serverkeygeneration-01.txt >
	NETWORK WORKING GROUP J. Schaad		NETWORK WORKING GROUP J. Schaad
	Internet-Draft Soaring Hawk Consulting		Internet-Draft Soaring Hawk Consulting
	Intended Status: Proposed Standard S. Turner		Intended Status: Proposed Standard S. Turner
	Expires: January 31, 2014 IECA		Expires: September 28, 2014 IECA
	P. Timmel		P. Timmel
	National Security Agency		National Security Agency
	July 30, 2013		March 27, 2014
	CMC (Certificate Management over Cryptographic Message Syntax)		CMC (Certificate Management over Cryptographic Message Syntax)
	Extensions: Server Key Generation		Extensions: Server Side Key Generation
	draft-turner-cmc-serverkeygeneration-00.txt		draft-turner-cmc-serverkeygeneration-01.txt
	Abstract		Abstract
	This document defines a set of extensions to the Certificate		This document defines a set of extensions to the Certificate
	Management over Cryptographic Message Syntax (CMC) protocol that		Management over Cryptographic Message Syntax (CMC) protocol that
	addresses the desire to support server-side generation of keys. This		addresses the desire to support server-side generation of keys for
	service is provided by the definition of additional control		certificates. This service is provided by the definition of
	statements within the CMC architecture. Additional CMC errors are		additional control statements within the CMC architecture.
	also defined.		Additional CMC errors are also defined.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	I-D CMC Extensions: Server Key Generation July 30, 2013
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Protocol Flows for Supported Scenarios . . . . . . . . . . . . 5		2. Protocol Flows for Supported Scenarios . . . . . . . . . . . . 5
	2.1. Shared Secret for Authentication and Key Protection . . . 7		2.1. Shared Secret for Authentication and Key Protection . . . 9
	2.2 Shared Secret for Authentication and Ephemeral Key for		2.2 Shared Secret for Authentication and Ephemeral Key for
	Protection . . . . . . . . . . . . . . . . . . . . . . . . 9		Protection . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3. Certificate for Authentication and Ephemeral Key for		2.3. Certificate for Authentication and Ephemeral Key for
	Protection . . . . . . . . . . . . . . . . . . . . . . . . 10		Protection . . . . . . . . . . . . . . . . . . . . . . . . 12
	2.4. Certificate for Authentication and Key Protection . . . . . 12		2.4. Certificate for Authentication and Key Protection . . . . . 13
	2.4.1. Same Certificate for Authentication and Key		2.4.1. Same Certificate for Authentication and Key
	Protection . . . . . . . . . . . . . . . . . . . . . . 12		Protection . . . . . . . . . . . . . . . . . . . . . . 14
	2.4.2. Different Certificates for Authentication and Key		2.4.2. Different Certificates for Authentication and Key
	Protection . . . . . . . . . . . . . . . . . . . . . . 12		Protection . . . . . . . . . . . . . . . . . . . . . . 14
	2.5. RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 12		2.5. RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 14
	2.5.1. RA-Generated Key Scenarios . . . . . . . . . . . . . . 14		2.5.1. RA-Generated Key Scenarios . . . . . . . . . . . . . . 16
	2.5.2. RA-Involved Scenarios . . . . . . . . . . . . . . . . 17		2.5.2. RA-Involved Scenarios . . . . . . . . . . . . . . . . 19
	3. Generating PKIData and PKIResponse . . . . . . . . . . . . . . 18		3. Generating PKIData and PKIResponse . . . . . . . . . . . . . . 20
	3.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 19		3.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 21
	3.2. RA Processing of Client Requests . . . . . . . . . . . . . 19		3.2. RA Processing of Client Requests . . . . . . . . . . . . . 21
	3.3. CA Processing . . . . . . . . . . . . . . . . . . . . . . 21		3.3. CA Processing . . . . . . . . . . . . . . . . . . . . . . 23
	3.4. RA Processing of CA Responses . . . . . . . . . . . . . . 23		3.4. RA Processing of CA Responses . . . . . . . . . . . . . . 25
	3.4. Client Processing of Responses . . . . . . . . . . . . . . 25		3.5. Client Processing of Responses . . . . . . . . . . . . . . 27
	4. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 25		4. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 27
	4.1. Shroud With a Public Key . . . . . . . . . . . . . . . . . 26		4.1. Shroud with a Public Key . . . . . . . . . . . . . . . . . 28
	4.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 27		4.2. Shroud with a Shared-Secret Key . . . . . . . . . . . . . . 29
	5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 28		5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 30
	6. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 29		6. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 31
	6.1. Server-Side Key Generation Request Attribute . . . . . . . 29		6.1. Server-Side Key Generation Request Attribute . . . . . . . 31
	6.2. Server-side Key Generation Response . . . . . . . . . . . . 31		6.2. Server-side Key Generation Response . . . . . . . . . . . . 33
	7. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 32		7. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 34
			8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 35
			9. Security Considerations . . . . . . . . . . . . . . . . . . . . 35
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
			11.1 Normative References . . . . . . . . . . . . . . . . . . . 38
			12.2 Informative References . . . . . . . . . . . . . . . . . . 38
			Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 39
			Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 40
			Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 43
			B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 43
			B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 43
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 33		B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 43
	9. Security Considerations . . . . . . . . . . . . . . . . . . . . 33		B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 43
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 43
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 43
	11.1 Normative References . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
	12.2 Informative References . . . . . . . . . . . . . . . . . . 36
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 37
	Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 37
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 41
	B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 41
	B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 41
	B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 41
	B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 41
	B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 41
	B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
	1 Introduction		1 Introduction
	This document defines a set of extensions to and errors for		This document defines a set of extensions to and errors for
	Certificate Management over Cryptographic Message Syntax (CMC)		Certificate Management over Cryptographic Message Syntax (CMC)
	[RFC5272] that allows for server-side generation of key material.		[RFC5272] that allows for server-side generation of key material for
	There are strong reasons for providing this service:		certificates [RFC5280]. There are strong reasons for providing this
			service:
	o Clients may have poor, unknown, or non-existent key generation		o Clients may have poor, unknown, or non-existent key generation
	capabilities. The creation of private keys relies on the use of		capabilities. The creation of private keys relies on the use of
	good key generation algorithms and a robust random number		good key generation algorithms and a robust random number
	generator. Server key generation can use specialized hardware		generator. Server key generation can use specialized hardware
	that may not always be available on clients.		that may not always be available on clients.
	o Central storage of keys may be desired in some environments to		o Central storage of keys may be desired in some environments to
	permit key recovery. This document only addresses a request to		permit key recovery. This document only addresses a request to
	archive server-generated keys; archival of locally generated keys		archive server-generated keys; archival of locally generated keys
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 44 ¶
	device [RFC4949] because the clients are not able to connect to		device [RFC4949] because the clients are not able to connect to
	the server due to an air gap).		the server due to an air gap).
	These extensions to the CMC protocol are designed to provide server		These extensions to the CMC protocol are designed to provide server
	key generation without adding any additional round trips to the		key generation without adding any additional round trips to the
	enrollment process; however, additional round trips may be required		enrollment process; however, additional round trips may be required
	based on the mechanism chosen to protect the returned key.		based on the mechanism chosen to protect the returned key.
	Section 2 describes the enrollment scenarios supported. Section 3		Section 2 describes the enrollment scenarios supported. Section 3
	provides CMC requirements. Sections 4 and 5 describe the concepts and		provides CMC requirements. Sections 4 and 5 describe the concepts and
	I-D CMC Extensions: Server Key Generation July 30, 2013
	structures used in transporting private keys between the server and		structures used in transporting private keys between the server and
	client applications. Section 6 describes the structure and processes		client applications. Section 6 describes the structure and processes
	for server-side key generation. Section 7 describes additional CMC		for server-side key generation. Section 7 describes additional CMC
	error codes. Section 8 describes additional exchanges when the		error codes. Section 8 describes additional exchanges when the
	server requires the client provide Proof-of-Possession (POP).		server requires the client provide Proof-of-Possession (POP).
	Appendix A provides the ASN.1 module for the CMC controls and errors.		Appendix A provides the ASN.1 module for the CMC controls and errors.
	Appendix B provides example encodings.		Appendix B provides example encodings.
	1.1. Terminology		1.1. Terminology
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	The terminology in [RFC5272] and in [RFC6402] apply to this profile.		The terminology in [RFC5272] and in [RFC6402] apply to this profile.
	Additionally, familiarity with CMS's (Cryptographic Message Syntax)		Additionally, familiarity with CMS's (Cryptographic Message Syntax)
	SignedData, AuthenticatedData, and EnvelopedData content types is		[RFC5652] SignedData, AuthenticatedData, and EnvelopedData content
	assumed [rfc5652].		types is assumed.
	1.2. Definitions		1.2. Definitions
	This section defines some of the terms that are used in this		This section defines some of the terms that are used in this
	document:		document:
	o Dual-use: Applies to certificates or keys. Certificates that can		o Dual-use: Applies to certificates or keys. Certificates that can
	be used to verify both digital signatures and to perform key		be used to verify both digital signatures and to perform key
	management, when the Key Usage extension is set to		management, when the Key Usage extension is set to
	digitalSignature and either keyAgreement or keyEncipherment, and		digitalSignature and either keyAgreement or keyEncipherment, and
	skipping to change at page 5, line 4 ¶		skipping to change at page 4, line 44 ¶
	o Encryption-only: Applies to certificates or keys. Certificates		o Encryption-only: Applies to certificates or keys. Certificates
	that can only be used for key management, when the Key Usage		that can only be used for key management, when the Key Usage
	extension is set to either keyAgreement or keyEncipherment, and		extension is set to either keyAgreement or keyEncipherment, and
	keys whose only intended use is keyAgreement or keyEncipherment.		keys whose only intended use is keyAgreement or keyEncipherment.
	o Ephemeral key [SP-800-57]: A cryptographic key that is generated		o Ephemeral key [SP-800-57]: A cryptographic key that is generated
	for each execution of a key establishment process and that meets		for each execution of a key establishment process and that meets
	other requirements of the key type (e.g., unique to each message		other requirements of the key type (e.g., unique to each message
	or session). Often, ephemeral keys are linked to key agreement		or session). Often, ephemeral keys are linked to key agreement
	algorithms; however, this document uses the term ephemeral keys		algorithms; however, this document uses the term ephemeral keys
	I-D CMC Extensions: Server Key Generation July 30, 2013
	to apply to both key transport and key agreement keys. The		to apply to both key transport and key agreement keys. The
	ephemeral key has two parts: the private part and the public		ephemeral key has two parts: the private part and the public
	part. The client provides the public part to the server to allow		part. The client provides the public part to the server to allow
	the server to protect the server-generated keys. Note that an		the server to protect the server-generated keys. Note that an
	ephemeral key has a security advantage by being unique to the		ephemeral key has a security advantage by being unique to the
	session; it SHOULD be freshly generated when possible, but MAY be		session; it SHOULD be freshly generated when possible, but MAY be
	pre-placed when local key generation is of poor or unknown		pre-placed when local key generation is of poor or unknown
	quality (see Section 9). An ephemeral key is innately		quality (see Section 9). An ephemeral key is innately
	unauthenticated, and so must be carried in a suitably		unauthenticated, and so must be carried in a suitably
	authenticated protocol.		authenticated protocol.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	o Identification: A generic term for a process by which a name,		o Identification: A generic term for a process by which a name,
	generally assigned by a server, is used to match a request		generally assigned by a server, is used to match a request
	against a known entity. Identification can be either		against a known entity. Identification can be either
	authenticated (a subject name in a certificate) or		authenticated (a subject name in a certificate) or
	unauthenticated (a text string).		unauthenticated (a text string).
			o Perfect Forward Secrecy (PFS): For this protocol, it is the
			property that the compromise of long-term keying material does
			not lead to the compromise of the new long-term keying material
			carried in the protocol.
	o Shared Secret: A value known to two or more entities in advance		o Shared Secret: A value known to two or more entities in advance
	of a protocol session in which it will be used, and intended to		of a protocol session in which it will be used, and intended to
	be unknown to any others. In this document, the value must be a		be unknown to any others. In this document, the value must be a
	suitable basis for derivation of a MAC (Message Authentication		suitable basis for derivation of a MAC (Message Authentication
	Code) or encryption key. Pass phrases that are used as a shared		Code) or encryption key. Pass phrases that are used as a shared
	secret must be treated as confidential by the holders of the		secret must be treated as confidential by the holders of the
	secret.		secret.
	o Shrouding: A generic term to cover methods of masking the content		o Shrouding: A generic term to cover methods of masking the content
	of an object from unauthorized viewers. The most common method		of an object from unauthorized viewers, taken from RSA's PKCS
	of shrouding used is encryption of the data at the application		specifications. The most common method of shrouding used is
	layer. This document defines two shroud methods that employ		encryption of the data at the application layer. This document
	encryption at the application layer but other shrouding methods		defines two shrouding methods that employ encryption at the
	can be defined that don't employ encryption at the application		application layer but other shrouding methods can be defined that
	layer.		don't employ encryption at the application layer.
	o Signature-capable: Applies to certificates or keys. Certificates		o Signature-capable: Applies to certificates or keys. Certificates
	that can be used to verify signatures and keys that can be used		that can be used to verify signatures and keys that can be used
	to generate digital signatures. This refers to either dual-use		to generate digital signatures. This refers to either dual-use
	or signature-only certificates/keys.		or signature-only certificates/keys.
	o Signature-only: Applies to certificate or keys. Certificates		o Signature-only: Applies to certificate or keys. Certificates
	that can only be used to verify digital signatures, when the Key		that can only be used to verify digital signatures, when the Key
	Usage extension is set to digitalSignature, and keys whose only		Usage extension is set to digitalSignature, and keys whose only
	intended key usage is digital signature.		intended key usage is digital signature.
			In this document the server is the entity that generates the key.
			This can be either the RA or CA.
	2. Protocol Flows for Supported Scenarios		2. Protocol Flows for Supported Scenarios
	This section describes five scenarios, and specifies the CMC requests		This section describes the supported scenarios, and specifies the CMC
	and responses to support them:		requests and responses to support them:
	I-D CMC Extensions: Server Key Generation July 30, 2013		1. Clients use a shared secret (e.g., password) (see Section 1.2) to
			provide authentication and request that the server use the same
			shared secret to encrypt the server-generated keys.
	1. In the first scenario (see Section 2.1), clients use a shared		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	secret (e.g., password) (see Section 1.2) to provide
	authentication and request that the server use the same shared
	secret to encrypt the server-generated keys. Obviously the
	security in this scenario, and any scenario in which a shared
	secret is used, is predicated on keeping the shared secret
	secret. Here, the client need only know a shared secret to
	request a certificate, but the client needs to maintain secrecy
	of the shared secret, which is often difficult for clients, for
	the lifetime of the key (see Section 9). Further, using the same
	secret for authentication and encryption potentially increases
	exposure of the server-generated private key among the entities
	comprising the RA and CA. Note that the use of split-shared
	secret (i.e., one for authentication and one for encryption)
	would alleviate the last concern, but this is beyond the scope of
	this document.
	2. In the second scenario (see Section 2.2), clients use a shared		2. Clients use a shared secret to provide authentication and request
	secret to provide authentication and request that the server use		that the server use an ephemeral key (see Section 1.2) to encrypt
	an ephemeral key (see Section 1.2) to encrypt the server-		the server-generated keys.
	generated keys. Here, the client can still use their shared
	secret to request the certificate but now once encrypted the
	private key can only become known to the client. Also, the key
	that protects the response is ephemeral even if the
	authentication shared secret is not.
	3. In the third scenario (see Section 2.3), clients use a		3. Clients use a key pair previously certified by a CA (i.e., a
	certificate to support digital signature authentication and		private key and a certificate) to support digital signature
	request that the server use an ephemeral key to encrypt the		authentication and request that the server use an ephemeral key
	server-generated keys. Here, the primary motivation is that use		to encrypt the server-generated keys.
	of the ephemeral key mitigates the risk of compromise of a pre-
	existing certificate and key while in the supply chain (see
	Section 9).
	4. In the fourth scenario (see Section 2.4), clients use a		4. Clients use a key pair previously certified by a CA (i.e., a
	certificate to support digital signature authentication and		private key and a certificate) to support digital signature
	request that the server use a certificate to encrypt the server-		authentication and request that the server use a certificate to
	generated keys. Here, clients can request a certificate with a		encrypt the server-generated keys. Some additional details:
	certificate or certificates that the client already has. There
	are still security requirements for protecting the private key(s)
	associated with the certificate(s) (see Section 9). If two
	certificates are used (i.e., one for encryption and one for
	digital signatures), the separation between signing and key
	exchange functions is preserved, and supports a broader range of
	algorithms. Some additional details:
	o If the client's authentication certificate is signature-only,		* If the client's authentication certificate is signature-only,
	then the client also needs an encryption-capable certificate		then the client also needs an encryption-capable certificate
			that the server will use to protect the private key.
	I-D CMC Extensions: Server Key Generation July 30, 2013		* If the client's certificate is dual-use, then the client only
	(i.e. having the Key Usage extension set to either keyAgreement
	or keyEncipherment) that the server will use to protect the
	private key.
	o If the client's certificate is dual-use, then the client only
	needs the one certified key pair to generate the SignedData		needs the one certified key pair to generate the SignedData
	that encapsulates the certificate request and to decrypt the		that encapsulates the certificate request and to decrypt the
	EnvelopedData that encapsulates the server-generated key.		EnvelopedData that encapsulates the server-generated key.
	5. The first four scenarios assume that the keys are generated at		The characteristics of the four scenarios are as follows:
	the Certification Authority (CA) and that the interactions do not
	involve a Registration Authority (RA) [RFC5280]. But, key		o Scenarios that employ shared secrets (Scenarios 1 and 2) are
	generation by an RA is also supported as well as scenarios when		consider by some to be more human friendly than scenarios that
	the RA verifies the client's identity (see Section 2.5).		employ certificates because there is less initial overhead
			because a CA is not initially and clients do not need to find
			their smartcard, remember their PIN, etc. Also, shared secrets
			can be used for rekey but this requires distributing a new shared
			secret with the newly created private key; this behavior is not
			described in this document.
			o For scenarios that use a shared secret for key protection (i.e.,
			Scenario 1), the client needs to maintain secrecy of the shared
			secret, which is often difficult for clients, for the lifetime of
			the key (see Section 9) to ensure that if the server-generated
			and encrypted private key is intercepted and the shared secret is
			later disclosed/discovered that the encrypted private key private
			key can not be decrypted. In other words, no PFS is provided if
			a shared secret is used to protect the returned encrypted private
			key.
			o For scenarios that use a shared secret for client authentication
			(i.e., Scenarios 1 and 2), the client needs to maintain secrecy
			of the shared secret for as long as it is needed for
			authentication. Servers can mitigate this issue by limiting the
			lifetime of the shared secret to one-time-use.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
			o For scenarios that use ephemeral keys to protect the returned
			private key (i.e., Scenarios 2 and 3):
			* PFS is provided presuming the ephemeral key is forgotten as
			well as any other information necessary to generate the
			ephemeral key after the certificate request is successfully
			processed by the client.
			* Client use of the ephemeral key mitigates the risk of
			compromise of a pre-existing certificate and key while in the
			supply chain (see Section 9).
			o For scenarios that only use certificates (i.e., Scenario 4), PFS
			is not provided because the the client uses a long-term private
			key for private key protection and if compromised the next key
			can also be compromised.
			Note that there are existing CP-based (Certificate Policy)
			requirements for protecting the private key(s) associated with
			the certificate(s) (see Section 9).
			In the scenarios above, the entity generating the key pair can be the
			Certification Authority (CA) or the Registration Authority (RA), in
			fact the RA or CA can use a separate key generator device (e.g. a
			hardware security module) but interactions with that device is out of
			scope. Sections 2.1-2.4 depict protocol flows for scenarios with a
			client and CA only where the CA generates the keys. Section 2.5
			depicts protocol flows for scenarios that involve the client, RA, and
			CA where the RA generates the keys. Section 2.5 also depicts
			protocol flows for so-called "RA-involved" scenarios where the CA
			generates the keys but the RA performs identity checks.
			All scenarios described herein require the server to have some a
			priori knowledge of the client. How this knowledge is obtained is
			out of scope, but the scenarios offer different
			opportunities/constraints for obtaining the information:
			o In the shared secret cases, the method for prior knowledge has to
			cope with securely delivering and storing the shared secret.
			o In the certificate cases, there are two alternatives:
			* The key pair was generated by the server, so the certificate is
			evidence of that prior knowledge.
			* The certificate was issued from another CA. Even when there
			are no grounds for cross-certification, the certificate can
			still be used as an artifact for registration/enrollment prior
			to the client making a certificate request, which is
			advantageous because the key pair bound to the identifier in
			the certificate enables the server to authenticate the source
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
			of the eventual certificate request and positively link it to
			the registration information.
			Note: The initial certificate key pairs could be considered a
			special case of the shared secret scenario that improves on the
			security of the shared secret mechanism and mitigates some of the
			management burden and cost. For example, the certificates could be
			special-purpose--issued by the manufacturer and recognized by the
			server solely for authentication against a registration list (i.e.,
			not usable for anything else). If a manufacturer initializes the
			device with a shared secret, then that shared secret has to be
			distributed securely to the eventual enrolling CA via the device
			owner, but independently of the device. If the manufacturer
			instead installs a key pair and generic certificate, the
			certificate can take the place of the shared secret that would
			otherwise have to be independently provided to the central key
			generation CA. The management process is roughly the same, but the
			information that has to be handled now longer has to be kept
			secret. That means there are many more options for how that
			information can be managed and distributed.
			Normally the client's identifier and the shared secret are generated
			by the server and then securely transported to the client, there is
			no practical reason why this cannot be done in the opposite
			direction. In this case, the client will generate an identifier,
			shared secret and an ephemeral key. When the server receives the CMC
			message, it recognizes that it does not correspond to an existing
			identifier/secret pair and puts the request on hold. The end-entity
			then communicates the identifier and secret to the server via an out-
			of-band means. The server then performs the necessary user
			management dealing with identity validation and certificate setup.
			If that passes and the ephemeral passes applicable public key
			validation tests, then the certificate will be issued and the
			response returned protected with ephemeral key. If it does not pass
			checking then the certificate will fail to issue. An ephemeral is
			generated by the client, to ensure PFS is provided as the client may
			not get the same degree of confidentiality because the client is
			unaware how the private key has been provided.
	Note that there is no scenario where the response is protected with a		Note that there is no scenario where the response is protected with a
	key/certificate that only supports digital signatures. This is		key/certificate that only supports digital signatures. This is
	because the "protection" afforded by digital signatures alone does		because the "protection" afforded by digital signatures alone does
	not include confidentiality, which is required to ensure that the		not include confidentiality, which is required to ensure that the
	server-generated private key is only disclosed to the client.		server-generated private key is only disclosed to the client.
	Note also that there is also no scenario where the client uses an		Note also that there is also no scenario where the client uses an
	encryption-only certificate and is unable to generate a digital		encryption-only certificate and is unable to generate a digital
	signature to provide authentication. This is because the		signature to provide authentication. This is because the
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	"protection" afforded by encryption-only certificates does not		"protection" afforded by encryption-only certificates does not
	include authentication. Technically, there are dual-service		include authentication. Technically, there are Authenticated
	algorithms that support both authentication and encryption but their		Encryption with Associated Data (AEAD) algorithms (i.e., dual-service
			algorithms) that support both authentication and encryption but their
	use is beyond the scope of this document.		use is beyond the scope of this document.
	In all of the scenarios, the client can validate that the response		In all of the scenarios, the client can validate that the response
	came from the CA or RA by validating the digital signature on the		came from the CA or RA by validating the digital signature on the
	SignedData to a Trust Anchor (TA). After the EnvelopedData is		SignedData to a Trust Anchor (TA). After the EnvelopedData is
	decrypted, the client can 1) verify that the private key is		decrypted, the client can 1) verify that the private key is
	associated with the public key in the returned certificate and/or 2)		associated with the public key in the returned certificate and/or 2)
	verify that the certificate validates back to an authorized TA.		verify that the certificate validates back to an authorized TA.
	The scenarios in the subsections assume that the transaction		The scenarios in the subsections assume that the transaction
	identifier and nonce controls are used for transaction processing and		identifier and nonce controls are used for transaction processing and
	replay protection, respectively, but they are optional, as specified		replay protection, respectively, but they are optional, as specified
	in [RFC5272]. Also, the scenarios assume the CMC Status Information		in [RFC5272]. Also, the scenarios assume the CMC Status Information
	v2 control is not included when the response is a success, as allowed		v2 control is not included when the response is a success, as allowed
	by [RFC5272]. See Appendix B for additional example scenarios.		by [RFC5272]. See Appendix B for additional example scenarios.
			A client requesting a certificate for a different name than one
			already issued, either based on the certificate being used in
			Scenarios 3 and 4 or the name associated with the shared secret in
			Scenarios 1 and 2, includes the Change Subject Name attribute to
			ensure the server will not reject the request because the name in the
			certificate used to sign the request does not match the name in the
			request. Note this is not depicted in the diagrams that follow
			because the attribute is included within the ServerKeyGenRequest.
	2.1. Shared Secret for Authentication and Key Protection		2.1. Shared Secret for Authentication and Key Protection
	The shared secret allows the server to authenticate the client and		The shared secret allows the server to authenticate the client and
	allows the server to encrypt the server-side generated key for the		allows the server to encrypt the server-side generated key for the
	client. The shared secret is distributed via an out-of-band		client. The shared secret is distributed via an out-of-band
	I-D CMC Extensions: Server Key Generation July 30, 2013
	mechanism that is out-of-scope of this document. Also note the		mechanism that is out-of-scope of this document. Also note the
	server and client need to share a non-secret identification string		server and client need to share a non-secret identification string
	that the client can assert in a request so that the server will know		that the client can assert in a request so that the server will know
	which shared secret is being used.		which shared secret is being used.
	When the client generates their request, the client includes the		When the client generates its request, the client includes the
	following control attributes in a PKIData content type [RFC5272]:		following control attributes in a PKIData content type [RFC5272]:
	Server Key Generation Request (see Section 6.1), Transaction		Server Key Generation Request (see Section 6.1), Transaction
	Identifier [RFC5272], Sender Nonce [RFC5272], and Identification		Identifier [RFC5272], Sender Nonce [RFC5272], and Identification
	[RFC5272]. The Server Key Generation Request control indicates that		[RFC5272]. The Server Key Generation Request control indicates that
	the shroudMethod is shroud with shared-secret key (see Section 4.2).		the shroudMethod is shroud with shared-secret key (see Section 4.2).
	The PKIData is encapsulated in a CMS AuthenticatedData content type		The PKIData is encapsulated in a CMS AuthenticatedData content type
	and the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652].		and the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652].
	Note that reqSequence, cmsSequence, and otherMsgSequence are not		Note that reqSequence, cmsSequence, and otherMsgSequence are not
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	included in the PKIData for the server-side key generation request.		included in the PKIData for the server-side key generation request.
	The following depicts this:		The following depicts this:
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	|AuthenticatedData: ReceipientInfo: pwri |		|AuthenticatedData: RecipientInfo: pwri |
	|+--------------------------------------------------------------||		|+--------------------------------------------------------------||
	||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)||		||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)||
	|| control: TransationID ||		|| control: TransationID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|| control: Identification ||		|| control: Identification ||
	|+--------------------------------------------------------------+|		|+--------------------------------------------------------------+|
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	After the server authenticates the client, the server generates a		After the server authenticates the client and verified the request,
	response that includes the server-generated key and any associated		the server generates a response that includes the server-generated
	parameters in an Asymmetric Key Package content type [RFC5958]. The		key and any associated parameters in an Asymmetric Key Package
	Asymmetric Key Package is then encapsulated within a SignedData and		content type [RFC5958]. The Asymmetric Key Package is then
			encapsulated within a SignedData, which is signed by the server, and
	that is further encapsulated within an EnvelopedData using the		that is further encapsulated within an EnvelopedData using the
	password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData is		password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData, which
	then placed in a PKIResponse cmsSequence [RFC5272] and the following		is encrypted for the client, is then placed in a PKIResponse
	controls are included in the PKIResponse: Transaction Identifier,		cmsSequence [RFC5272] and the following controls are included in the
	Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation		PKIResponse: Transaction Identifier, Sender Nonce, Recipient Nonce
	Response (see Section 4.2). The PKIResponse is then encapsulated in		[RFC5272], and Server Key Generation Response (see Section 4.2). The
	a SignedData and the certificate associated with the server-generated		PKIResponse is then encapsulated in a SignedData, which is signed by
	key is placed in the outer-most SignedData's certificate field		the server, and the client's certificate associated with the server-
	[RFC5652]. The following depicts this:		generated key is placed in the outer-most SignedData's certificates
			field [RFC5652]. The following depicts this:
	+---------------------------------------------------------+		+---------------------------------------------------------+
	|SignedData: Signed by the CA |		|SignedData: Signed by the CA |
	| Client's certificate found here |		| Client's certificate in certificates field |
	|+-------------------------------------------------------+|		|+-------------------------------------------------------+|
	||PKIResponse: control: TransactionID ||		||PKIResponse: control: TransactionID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|| control: RecipientNonce ||		|| control: RecipientNonce ||
	I-D CMC Extensions: Server Key Generation July 30, 2013
	|| control: ServerKeyGenResponse ||		|| control: ServerKeyGenResponse ||
	|| ||		|| ||
	|| cmsSequence: ||		|| cmsSequence: ||
	|| +----------------------------------------+||		|| +----------------------------------------+||
	|| |EnvelopedData: RecipientInfo: pwri |||		|| |EnvelopedData: RecipientInfo: pwri |||
	|| |+----------------------+ |||		|| |+-----------------------------+ |||
	|| ||SignedData | |||		|| ||SignedData: Signed by the CA | |||
	|| ||+--------------------+| |||		|| ||+---------------------------+| |||
	|| |||AsymmetricKeyPackage|| |||		|| |||AsymmetricKeyPackage || |||
	|| ||+--------------------+| |||		|| ||+---------------------------+| |||
	|| |+----------------------+ |||		|| |+-----------------------------+ |||
	|| +----------------------------------------+||		|| +----------------------------------------+||
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	|+-------------------------------------------------------+|		|+-------------------------------------------------------+|
	+---------------------------------------------------------+		+---------------------------------------------------------+
	2.2 Shared Secret for Authentication and Ephemeral Key for Protection		2.2 Shared Secret for Authentication and Ephemeral Key for Protection
	The shared secret allows the server to authenticate the client and		The shared secret allows the server to authenticate the client and
	the ephemeral key allows the server to use a different key to encrypt		the ephemeral key allows the server to use a different key to encrypt
	the server-side generated key for the client. The shared secret is		the server-side generated key for the client. The shared secret is
	distributed via an out-of-band mechanism that is out-of-scope of this		distributed via an out-of-band mechanism that is out-of-scope of this
	document. Also note that the client needs an identification string		document. Also note that the client needs an identification string
	skipping to change at page 9, line 44 ¶		skipping to change at page 11, line 32 ¶
	Section 6.1), Transaction Identifier [RFC5272], Sender Nonce		Section 6.1), Transaction Identifier [RFC5272], Sender Nonce
	[RFC5272], and Identification [RFC5272]. The Server Key Generation		[RFC5272], and Identification [RFC5272]. The Server Key Generation
	Request control indicates that the shroudMethod is shroud with public		Request control indicates that the shroudMethod is shroud with public
	key and that the bareKey CHOICE is used (see Section 4.1). The		key and that the bareKey CHOICE is used (see Section 4.1). The
	PKIData is encapsulated in an AuthenticatedData content type and the		PKIData is encapsulated in an AuthenticatedData content type and the
	password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note		password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note
	that reqSequence, cmsSequence, or otherMsgSequence are not included.		that reqSequence, cmsSequence, or otherMsgSequence are not included.
	The following depicts this:		The following depicts this:
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	|AuthenticatedData: ReceipientInfo: pwri |		|AuthenticatedData: RecipientInfo: pwri |
	|+-----------------------------------------------------------+|		|+-----------------------------------------------------------+|
	||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)||		||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)||
	|| control: TransationID ||		|| control: TransationID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|| control: Identification ||		|| control: Identification ||
	|+-----------------------------------------------------------+|		|+-----------------------------------------------------------+|
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	After the server has authenticated the client, the server returns the		After the server has authenticated the client and verified the
	server-generated key and any associated parameters in an Asymmetric		request, the server returns the server-generated key and any
			associated parameters in an Asymmetric Key Package content type
			[RFC5958]. The Asymmetric Key Package is then encapsulated within a
			SignedData, which is signed by the server, and that is further
			encapsulated within an EnvelopedData using the key agreement or key
			transport RecipientInfo (i.e., kari or ktri CHOICE). The
			EnvelopedData, which is encrypted for the client, is then placed in a
			PKIResponse cmsSequence [RFC5272] and the following controls are
			included: Transaction Identifier, Sender Nonce, Recipient Nonce
			[RFC5272], and Server Key Generation Response (see Section 6.2). The
			PKIResponse is then encapsulated in a SignedData, which is signed by
			the server, and the certificate associated with the server-generated
			key is placed in the outer-most SignedData's certificates field
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	Key Package content type [RFC5958]. The Asymmetric Key Package is		[RFC5652]. The following depicts this:
	then encapsulated within a SignedData and that is encapsulated within
	an EnvelopedData using the key agreement or key transport
	RecipientInfo (i.e., kari or ktri CHOICE). The EnvelopedData is then
	placed in a PKIResponse cmsSequence [RFC5272] and the following
	controls are included: Transaction Identifier, Sender Nonce,
	Recipient Nonce [RFC5272], and Server Key Generation Response (see
	Section 6.2). The PKIResponse is then encapsulated in a SignedData
	and the certificate associated with the server-generated key is
	placed in the outer-most SignedData's certificate field [RFC5652].
	The following depicts this:
	+-----------------------------------------------------------+		+-----------------------------------------------------------+
	|SignedData: Signed by the CA |		|SignedData: Signed by the CA |
	| Client's certificate found here |		| Client's certificate in certificates field |
	|+---------------------------------------------------------+|		|+---------------------------------------------------------+|
	||PKIResponse: control: TransactionID ||		||PKIResponse: control: TransactionID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|| control: RecipientNonce ||		|| control: RecipientNonce ||
	|| control: ServerKeyGenResponse ||		|| control: ServerKeyGenResponse ||
	|| ||		|| ||
	|| cmsSequence: ||		|| cmsSequence: ||
	|| +------------------------------------------+||		|| +------------------------------------------+||
	|| |EncryptedData: RecipientInfo: kari or ktri|||		|| |EnvelopedData: RecipientInfo: kari or ktri|||
	|| |+----------------------+ |||		|| |+------------------------------+ |||
	|| ||SignedData | |||		|| ||SignedData: Signed by the CA | |||
	|| ||+--------------------+| |||		|| ||+----------------------------+| |||
	|| |||AsymmetricKeyPackage|| |||		|| |||AsymmetricKeyPackage || |||
	|| ||+--------------------+| |||		|| ||+----------------------------+| |||
	|| |+----------------------+ |||		|| |+------------------------------+ |||
	|| +------------------------------------------+||		|| +------------------------------------------+||
	|+---------------------------------------------------------+|		|+---------------------------------------------------------+|
	+-----------------------------------------------------------+		+-----------------------------------------------------------+
	2.3. Certificate for Authentication and Ephemeral Key for Protection		2.3. Certificate for Authentication and Ephemeral Key for Protection
	This scenario differs from the scenarios in Sections 2.1 and 2.2 in		This scenario differs from the scenarios in Sections 2.1 and 2.2 in
	that the client encapsulates the PKIData in a SignedData instead of		that the client encapsulates the PKIData in a SignedData instead of
	an AuthenticatedData (i.e., the client uses its private key		an AuthenticatedData (i.e., the client uses its private key
	associated with its signature-capable certificate to sign the		associated with its signature-capable certificate to sign the
	PKIData) but is similar to Section 2.2 for the response. As implied		PKIData) but is similar to Section 2.2 for the response. As implied
	in [RFC5272], clients omit the Identification and Identity Proof		in [RFC5272], clients omit the Identification and Identity Proof
	controls when using certificates to support digital signature		controls when using certificates to support digital signature
	authentication. A client requesting a certificate for a different		authentication.
	name includes the Change Subject Name attribute to ensure the server
	will not reject the request because the name in the certificate used
	to sign the request does not match the name in the request.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	When the client generates their request, the client includes the		When the client generates its request, the client includes the
	following control attributes in a PKIData content type [RFC5272]:		following control attributes in a PKIData content type [RFC5272]:
	Server Key Generation Request (see Section 6.1), Transaction		Server Key Generation Request (see Section 6.1), Transaction
	Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key		Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key
	Generation Request control indicates the shroudMethod is shroud with		Generation Request control indicates the shroudMethod is shroud with
	public key and the bareKey CHOICE is used (see Section 4.1). The		public key and the bareKey CHOICE is used (see Section 4.1). The
	PKIData is encapsulated in a SignedData content type [RFC5652]. Note		PKIData is encapsulated in a SignedData content type [RFC5652]. Note
	that reqSequence, cmsSequence, and otherMsgSequence are not included		that reqSequence, cmsSequence, and otherMsgSequence are not included
	in the PKIData for the server-side key generation request. The		in the PKIData for the server-side key generation request. The
	following depicts this:		following depicts this:
	+--------------------------------------------------------------+		+--------------------------------------------------------------+
	|SignedData: Signed by the Client |		|SignedData: Signed by the Client |
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	|+------------------------------------------------------------||		|+------------------------------------------------------------||
	||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) ||		||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) ||
	|| control: TransationID ||		|| control: TransationID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|+------------------------------------------------------------+|		|+------------------------------------------------------------+|
	+--------------------------------------------------------------+		+--------------------------------------------------------------+
	After the server has authenticated the client, the server returns the		After the server has authenticated the client and verified the
	server-generated key and any associated parameters in an		request, the server returns the server-generated key and any
	AsymmetricKeyPackage content type [RFC5958]. The		associated parameters in an AsymmetricKeyPackage content type
	AsymmetricKeyPackage is then encapsulated within a SignedData and		[RFC5958]. The AsymmetricKeyPackage is then encapsulated within a
	that is encapsulated within an EnvelopedData using the key agreement		SignedData, which is signed by the server, and that is encapsulated
	or key transport RecipientInfo (i.e., kari or ktri CHOICE). The		within an EnvelopedData using the key agreement or key transport
	EnvelopedData is then placed in a PKIResponse cmsSequence [RFC5272]		RecipientInfo (i.e., kari or ktri CHOICE). The EnvelopedData, which
	and the following controls are included: Transaction Identifier,		is encrypted for the client, is then placed in a PKIResponse
	Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation		cmsSequence [RFC5272] and the following controls are included:
	Response (see Section 6.2). The PKIResponse is then encapsulated in		Transaction Identifier, Sender Nonce, Recipient Nonce [RFC5272], and
	a SignedData and the certificate associated with the server-generated		Server Key Generation Response (see Section 6.2). The PKIResponse is
	key is placed in the outer-most SignedData's certificate field		then encapsulated in a SignedData, which is signed by the server, and
	[RFC5652]. The following depicts this:		the certificate associated with the server-generated key is placed in
			the outer-most SignedData's certificates field [RFC5652]. The
			following depicts this:
	+-----------------------------------------------------------+		+-----------------------------------------------------------+
	|SignedData: Signed by the CA |		|SignedData: Signed by the CA |
	| Client's certificate found here |		| Client's certificate in certificates field |
	|+---------------------------------------------------------+|		|+---------------------------------------------------------+|
	||PKIResponse: control: TransactionID ||		||PKIResponse: control: TransactionID ||
	|| control: SenderNonce ||		|| control: SenderNonce ||
	|| control: RecipientNonce ||		|| control: RecipientNonce ||
	|| control: ServerKeyGenResponse ||		|| control: ServerKeyGenResponse ||
	|| ||		|| ||
	|| cmsSequence: ||		|| cmsSequence: ||
	|| +------------------------------------------+||		|| +------------------------------------------+||
	|| |EnvelopedData: RecipientInfo: kari or ktri|||		|| |EnvelopedData: RecipientInfo: kari or ktri|||
	|| |+----------------------+ |||		|| |+-----------------------------+ |||
	|| ||SignedData | |||		|| ||SignedData: Signed by the CA | |||
			|| ||+---------------------------+| |||
	I-D CMC Extensions: Server Key Generation July 30, 2013		|| |||AsymmetricKeyPackage || |||
			|| ||+---------------------------+| |||
	|| ||+--------------------+| |||		|| |+-----------------------------+ |||
	|| |||AsymmetricKeyPackage|| |||
	|| ||+--------------------+| |||
	|| |+----------------------+ |||
	|| +------------------------------------------+||		|| +------------------------------------------+||
	|+---------------------------------------------------------+|		|+---------------------------------------------------------+|
	+-----------------------------------------------------------+		+-----------------------------------------------------------+
	2.4. Certificate for Authentication and Key Protection		2.4. Certificate for Authentication and Key Protection
	If a client already has been issued a signature-capable certificate,		If a client already has been issued a signature-capable certificate,
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	then it can use this certificate to authenticate the requests. If		then it can use this certificate to authenticate the requests. If
	the certificate also indicates support for encryption (i.e., the key		the certificate also indicates support for encryption (i.e., the key
	usage extension is set to keyEncipherment or keyAgreement), then the		usage extension is set to keyEncipherment or keyAgreement), then the
	client can request that the server use the same certificate to		client can request that the server use the same certificate to
	protect the server-generated key (see Section 2.4.1). If the		protect the server-generated key (see Section 2.4.1). If the
	certificate does not indicate support for encryption, then the client		certificate does not indicate support for encryption, then the client
	can provide the server with another certificate to use to encrypt the		can provide the server with another certificate to use to encrypt the
	server-generated key (see Section 2.4.2). The certificate that		server-generated key (see Section 2.4.2). The certificate that
	protects the server-generated key MUST be encryption-capable.		protects the server-generated key MUST be encryption-capable.
	These scenarios differ from the scenarios in Section 2.3 in that the		These scenarios differ from the scenarios in Section 2.3 in that the
	response is protected with a previously certified key instead of an		response is protected with a previously certified key instead of an
	ephemeral key. As specified in [RFC5272], clients omit the		ephemeral key. As specified in [RFC5272], clients omit the
	Identification and Identity Proof controls when using certificates to		Identification and Identity Proof controls when using certificates to
	support digital signature authentication. A client requesting a		support digital signature authentication.
	certificate for a different name includes the Change Subject Name
	attribute to ensure the server will not reject the request because
	the name in the certificate used to sign the request does not match
	the name in the request.
	2.4.1. Same Certificate for Authentication and Key Protection		2.4.1. Same Certificate for Authentication and Key Protection
	This scenario is the same as in Section 2.3. except Server Key		This scenario is the same as in Section 2.3. except the Server Key
	Generation Request control includes the certificate CHOICE instead of		Generation Request control includes the certificate or certIdentifier
	the bareKey CHOICE.		CHOICE instead of the bareKey CHOICE. The certidentifier is
			sufficient information for the server since the same certificate will
			have already been used for verifying the encapsulating SignedData.
	2.4.2. Different Certificates for Authentication and Key Protection		2.4.2. Different Certificates for Authentication and Key Protection
	When the client's certificate that is used to sign the PKIData does		This scenario is the same as in Section 2.3. except the Server Key
	not support encryption but the client has another certificate that		Generation Request control includes the certificate CHOICE instead of
	does, the client can include this other certificate in the Server Key		the bareKey CHOICE. When using two certificates, the names in the
	Generation Request control's certificate field. When using two		two certificates MUST match to ensure the CA will not reject the
	certificates, the names in the two certificates MUST match to ensure		request due to name mismatches.
	the CA will not reject the request due to name mismatches.
	2.5. RA Scenarios		2.5. RA Scenarios
	I-D CMC Extensions: Server Key Generation July 30, 2013
	In Sections 2.1-2.4, client-to-CA protocol flows were illustrated		In Sections 2.1-2.4, client-to-CA protocol flows were illustrated
	where the CA generates the client's key and no RA was involved. This		where the CA generates the client's key and no RA was involved. This
	section illustrates client-to-RA-to-CA protocol flows. The scenarios		section illustrates client-to-RA-to-CA protocol flows. The scenarios
	divide into two basic categories, according to whether the RA or the		divide into two basic categories, according to whether the RA or the
	CA generates the key pair.		CA generates the key pair.
	When the RA generates the key on behalf of the client, the RA		Regardless of whether the RA or the CA generates the request, the
	effectively becomes a proxy for the client from the CA's perspective.		intent of the RA here is to be transparent. That is, client's
	The protocol exchange between the RA and CA is identical to other		initial the same request regardless of the entity that ultimately
	situations in which a client requests a certificate. This means that		generates the keys.
	the CA need not know about or support the Server Key Generation
	Request and Server Key Generation Response controls. The PKIResponse		When the RA generates the key on behalf of the client, the RA fleshes
	to the client now has to accommodate the fact that the asymmetric key		out the taggedRequst from the client with the RA-generated public key
	package is generated by the RA, whereas the certificate is generated		and applies POP with the corresponding private key. This becomes the
	by the CA. This necessitates that the RA intercepts whatever
	response the CA returns to get the client's certificate and that the		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	RA generates a signed response that includes the asymmetric key
	package as well as the client's certificate. See section 9 for		requestSequences in a new PKIData that the RA will send to the CA,
	security considerations.		and that repeats the controls received from the client. Then the PA
			signs the new PKIData with its own signing key. In this way, the RA
			effectively becomes the client from the CA's perspective. However,
			the RA and CA already have an established trust relationship (i.e.,
			the RA has been issued a certificate from the CA), which might not be
			true for the client. The protocol exchange between the RA and CA is
			identical to a client enrolling with a CMC Full PKI Request;
			therefore, the CA need not know about or support the Server Key
			Generation Request and Server Key Generation Response controls. The
			PKIResponse to the client now has to accommodate the fact that the
			asymmetric key package is generated by the RA, whereas the
			certificate is generated by the CA. This necessitates that the RA
			intercepts whatever response the CA returns to get the client's
			certificate and that the RA generates a signed response that includes
			the asymmetric key package as well as the client's certificate. See
			section 9 for security considerations.
	When the RA participates in the process but does not generate the		When the RA participates in the process but does not generate the
	key, there are two possibilities. If the RA does not contribute to		key, there are two possibilities. If the RA does not contribute to
	the protocol (its effects may be procedural or out-of-band), then it		the protocol (its effects may be procedural or out-of-band), then it
	can simply pass the messages it receives to the other party when		can simply pass the messages it receives to the other party when
	warranted. If that is not warranted, the RA would generate the usual		warranted. If that is not warranted, the RA would generate the usual
	response for the associated failure. No message flow for this		response for the associated failure. No message flow for this
	possibility is included. Alternatively, the RA may be responsible		possibility is included. Alternatively, the RA may be responsible
	for processing certain aspects of the request, and needs to vouch for		for processing certain aspects of the request, and needs to vouch for
	that when forwarding the client request to the CA. The RA does this		that when forwarding the client request to the CA. The RA does this
	per [RFC5272] by embedding the client request in a Full PKI Request		per [RFC5272] by embedding the client request in a Full PKI Request
	that it signs, containing controls for the processing that it		that it signs, containing controls for the processing that it
	performs. Here as in Sections 2.1-2.4, the CA needs to fully		performs. Here, as in Sections 2.1-2.4, the CA needs to fully
	understand and support the Server Key Generation Request and Server		understand and support the Server Key Generation Request and Server
	Key Generation Response controls, since the CA has to generate the		Key Generation Response controls, since the CA has to generate the
	key and construct the asymmetric key package.		key and construct the asymmetric key package.
	In the figures that follow, SKGReq is the Server Key Generation		In the figures that follow, SKGReq is the Server Key Generation
	Request control (see Section 6.1), the SKGRes denotes the Server Key		Request control (see Section 6.1), the SKGRes denotes the Server Key
	Generation Response control (see Section 6.2), TransactionId denotes		Generation Response control (see Section 6.2), TransactionId denotes
	the Transaction Identifier control [RFC5272], SenderNonce denotes the		the Transaction Identifier control [RFC5272], SenderNonce denotes the
	Sender Nonce control [RFC5272], RecipientNonce denotes the Recipient		Sender Nonce control [RFC5272], RecipientNonce denotes the Recipient
	Nonce control [RFC57272]. AKP denotes an Asymmetric Key Package		Nonce control [RFC5272]. AKP denotes an Asymmetric Key Package
	[RFC5958] (i.e., the private key). Also, {} denotes encryption		[RFC5958] (i.e., the private key). Also, {} denotes encryption
	(i.e., EnvelopedData), <> denotes signatures (i.e., SignedData), with		(i.e., EnvelopedData), <> denotes signatures (i.e., SignedData), with
	() identifying some of the information in carried in unsignedAttrs		() identifying some of the information is carried in unsignedAttrs
	for clarity, and [] denotes authentication (i.e., SignedData or		for clarity, and [] denotes authentication (i.e., SignedData or
	AuthenticatedData). control denotes controlSequence, reqSeq denotes		AuthenticatedData). AuthenticatedData is used when clients use a
	requestSequence, and cmsSeq denotes cmsSequence. PKCS#10 [RFC2986]		shared secret for authentication. control denotes controlSequence,
			reqSeq denotes requestSequence, and cmsSeq denotes cmsSequence.
			PKCS#10 [RFC2986], CRMF (Certificate Request Message Format)
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	and CRMF (Certificate Request Message Format) [RFC4211] are the		[RFC4211], and other request message [RFC5272] are the certification
	certification requests.		request formats supported.
	2.5.1. RA-Generated Key Scenarios		2.5.1. RA-Generated Key Scenarios
	There are some differences in the protocol flows when an RA generates		There are some differences in the protocol flows when an RA generates
	the key:		the key:
	o The RA MUST be issued a certificate from the CA. This means all		o The RA MUST be issued a certificate from the CA. This means all
	of the RA-generated PKIData are encapsulated in a SignedData.		of the RA-generated PKIData are encapsulated in a SignedData.
	Further, the RA's certificate can be used for identification and		Further, the RA's certificate can be used for identification and
	linking identity and POP information.		linking identity and POP information.
	o The RA generates the certification request for the client by:		o The RA generates the certification request for the client by:
	* Using the name from the certificate for the key the RA will use		1. Using the name from the certificate for the key the RA will
	to sign the PKIData.		use to sign the PKIData.
	* Using the information from the client's request.		2. Using the information from the client's request.
	* The RA includes the Change Subject Name control [RFC6402]		3. The RA includes the Change Subject Name control [RFC6402]
	either in the PKCS #10 or CRMF TaggedRequest because the POP		either in the PKCS #10 or CRMF TaggedRequest because the name
	and identity linking CMC requirements are that the name in the		in the certificate used for verifying the PKIData signature
	certificate used to sign the PKIData matches the name in the		must match the name in the certificate request. The Change
	certification request. The Change Subject Name attribute		Subject Name attribute allows the names to be different.
	allows the names to be different.
	* Modifying the information as necessary. Notably adding the		4. Modifying the taggedRequest as necessary. Notably adding the
	public key but also adding certificate extensions, etc. Note		public key but also adding certificate extensions, etc. Note
	that the Modify Certificate Template control is not needed as		that the Modify Certificate Template control is not needed as
	the RA is generating a new PKIData.		the RA is generating a new PKIData.
	* Generating the POP information for the RA-generated keys. For		5. Generating the POP information for the certificateRequest
	keys that support digital signatures, the RA includes the		containing the RA-generated keys. For keys that support
	POPSigningKey in the CRMF or the signature in the PKCS #10.		digital signatures, the RA includes the POPSigningKey in the
	For encryption-only keys, the RA can indicate that it performed		CRMF or the signature in the PKCS #10. For encryption-only
	POP by including the RA POP Witness control. Note the CA could		keys, the RA can indicate that it performed POP by including
	force the RA to prove it has possession of the key with the		the RA POP Witness control. Note the CA could force the RA to
	encrypted/decrypted POP mechanism for [RFC57272], but this adds		prove it has possession of the key with the
	additional round trips and is discussed later in this section.		encrypted/decrypted POP mechanism for [RFC5272], but this adds
			additional round trips and is discussed later in this section.
	* Signing the certification request (i.e., the PKIData) with the		6. Signing the certification request (i.e., the PKIData) with the
	RA's private key.		RA's private key.
	The RA can also generate bulk requests (i.e., include more than one		The RA can also generate bulk requests (i.e., include more than one
	request in cmsSequence) with the Bulk Request control [RFC5272] but		request in cmsSequence) with the Bulk Request control [RFC5272] but
	these controls are not depicted in the following sections to simplify		these controls are not depicted in the following sections to simplify
	the protocol flows. When the RA is requesting more than one key for		the protocol flows. When the RA is requesting more than one key for
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	a given client, the RA includes each request in the reqSequence.		a given client, the RA includes each request in the reqSequence.
	The following message flow applies when the RA generates the key. It		The following message flow applies when the RA generates the key. It
	supports all of the previously defined choices for authentication and		supports all of the previously defined choices for authentication and
	shrouding. The diagram below depicts use of a shared secret for		shrouding. The diagram below depicts use of a shared secret for
	authentication by including the Identification control and		authentication by including the Identification control and
	encapsulating the client's PKIData in an AuthenticatedData. If a		encapsulating the client's PKIData in an AuthenticatedData. If a
	digital signature is used for authentication, the Identification		digital signature is used for authentication, the Identification
	control is omitted and the client encapsulates its PKIData in a		control is omitted and the client encapsulates its PKIData in a
	skipping to change at page 15, line 35 ¶		skipping to change at page 17, line 35 ¶
	| Identification] | |		| Identification] | |
	| |-------------------------------------->|		| |-------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | control: TransactionId, SenderNonce, |		| | control: TransactionId, SenderNonce, |
	| | reqSeq:* PKCS #10 or CRMF> |		| | reqSeq:* PKCS #10 or CRMF> |
	| | (RA signed) |		| | (RA signed) |
	| |<--------------------------------------|		| |<--------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: TransactionId, SenderNonce,		| | control: TransactionId, SenderNonce,
	| | RecipientNonce>		| | RecipientNonce>
	|<-----------------| (CA signed with issued client certificate)		| | (CA signed includes issued
			|<-----------------| client certificate)
	| <PKIResponse		| <PKIResponse
	| control: TransactionId, SenderNonce, RecipientNonce, SKGRes		| control: TransactionId, SenderNonce, RecipientNonce, SKGRes
	| cmsSeq: {<AKP>}>		| cmsSeq: {<AKP>}>
	| (RA signed PKIResponse with CA-issued client certificate)		| (RA signed PKIResponse with CA-issued client certificate)
	* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.		* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.
	NOTE: There's no need for the RA to provide the SKGReq or the {<AKP>}		NOTE: There's no need for the RA to provide the SKGReq or the {<AKP>}
	to the CA. The CA won't be able to access the contents of the		to the CA. The CA won't be able to access the contents of the
	{<AKP>} because it's encrypted for the client and the CA's response		{<AKP>} because it's encrypted for the client and the CA's response
	is always returned to the RA because the RA needs to provide the		is always returned to the RA because the RA needs to provide the
	generated {<AKP>} back to the client.		generated {<AKP>} back to the client.
	Whether the client's PKIData is encapsulated in a SignedData or		Whether the client's PKIData is encapsulated in a SignedData or
	AuthenticatedData depends on whether the client used a certificate or		AuthenticatedData depends on whether the client used a certificate or
	shared secret for authentication, respectively. Additionally, the		shared secret for authentication, respectively. Additionally, the
	RecipientInfo for the EnvelopedData encapsulating the <AKP> depends		RecipientInfo for the EnvelopedData encapsulating the <AKP> depends
	on whether the key was protected with a shared secret (pwri),		on whether the key was protected with a shared secret (pwri),
	ephemeral key (ktri or kari), or certificate (ktri or kari).
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
			ephemeral key (ktri or kari), or certificate (ktri or kari).
	The RA intercepts the response from the CA; it strips the CA's		The RA intercepts the response from the CA; it strips the CA's
	signature and creates a new PKIResponse for the client. The		signature and creates a new PKIResponse for the client. The
	controlSequence is comprised of the Transaction Identifier and		controlSequence is comprised of the Transaction Identifier and
	Recipient Nonce fields from the client's request, the RA's Sender		Recipient Nonce fields from the client's request, the RA's Sender
	Nonce, and the Server Key Generation Response (see Section 6.2); the		Nonce, and the Server Key Generation Response (see Section 6.2); the
	cmsSequence includes the RA-generated {<AKP>}; and the RA signs the		cmsSequence includes the RA-generated {<AKP>}; and the RA signs the
	PKIRepsonse and includes the client's certificate, which was returned		PKIRepsonse and includes the client's certificate, which was returned
	in the CA's SignedData.		in the CA's SignedData.
	skipping to change at page 16, line 53 ¶		skipping to change at page 19, line 5 ¶
	| |<---------------------------------------|		| |<---------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: TransactionId, SenderNonce,		| | control: TransactionId, SenderNonce,
	|<-----------------| RecipientNonce>		|<-----------------| RecipientNonce>
	| <PKIResponse		| <PKIResponse
	| control: TransactionId, SenderNonce, RecipientNonce, SKGRes		| control: TransactionId, SenderNonce, RecipientNonce, SKGRes
	| cmsSeq: <{<AKP>}>>		| cmsSeq: <{<AKP>}>>
	* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.		* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	NOTE: The number of round trips between the RA and CA in the above		NOTE: The number of round trips between the RA and CA in the above
	figure is twice as many as the first figure in this Section and in		figure is twice as many as the first figure in this Section and in
	I-D CMC Extensions: Server Key Generation July 30, 2013
	Section 2.5.1.1; however, the additional round trip is specified in		Section 2.5.1.1; however, the additional round trip is specified in
	[RFC5272] (i.e., this document does not introduce the additional		[RFC5272] (i.e., this document does not introduce the additional
	round trip). The additional round trip is necessary when the CA		round trip). The additional round trip is necessary when the CA
	forces the RA to perform POP with the CA. While the additional round		forces the RA to perform POP with the CA. While the additional round
	trip might be problematic between the client and server, the quality		trip might be problematic between the client and server, the quality
	of communication connectivity between RA and CA should not make the		of communication connectivity between RA and CA should not make the
	additional round trips as problematic as between clients and RAs or		additional round trips as problematic as between clients and RAs or
	CAs.		CAs.
	2.5.2. RA-Involved Scenarios		2.5.2. RA-Involved Scenarios
	skipping to change at page 17, line 53 ¶		skipping to change at page 20, line 4 ¶
	well as RA Identity Witness control if the RA checks the client's		well as RA Identity Witness control if the RA checks the client's
	identity.		identity.
	Client RA CA		Client RA CA
	| | |		| | |
	|----------------->| |		|----------------->| |
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| TransactionID, | |		| TransactionID, | |
	| SenderNonce, | |		| SenderNonce, | |
	| Identification] | |
	| |--------------------------------------->|
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
			| Identification] | |
			| |--------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | control: TransactionId, SenderNonce, |		| | control: TransactionId, SenderNonce, |
	| | RAIdentityWitness |		| | RAIdentityWitness |
	| | cmsSeq: [PKIData |		| | cmsSeq: [PKIData |
	| | control: SKGReq, TransactionID, |		| | control: SKGReq, TransactionID, |
	| | SenderNonce, Identification]>|		| | SenderNonce, Identification]>|
	| |<---------------------------------------|		| |<---------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: TransactionId, SenderNonce,		| | control: TransactionId, SenderNonce,
	| | RecipientNonce		| | RecipientNonce
	| | cmsSeq: <PKIResponse		| | cmsSeq: <PKIResponse
	| | control: TransactionID, SenderNonce,		| | control: TransactionID, SenderNonce,
	| | RecipientNonce, SKGRes		| | RecipientNonce, SKGRes
	| | cmsSeq: {<AKP>} >		| | cmsSeq: {<AKP>} >
	| | (CA signed with issued client certificate)		| | (CA signed includes issued
			| | client certificate)
	|<-----------------| > (CA signed)		|<-----------------| > (CA signed)
	| <PKIResponse		| <PKIResponse
	| control: SKGRes, TransactionId, SenderNonce, RecipientNonce		| control: TransactionId, SenderNonce, RecipientNonce, SKGRes
	| cmsSeq: {<AKP>}>		| cmsSeq: {<AKP>}>
	| (CA signed with issued client certificate)		| (CA signed with issued client certificate)
	When the RA receives the request from the CA, it strips the CA's		When the RA receives the request from the CA, it strips the CA's
	response for the RA off and passes the inner response to the client		response for the RA off and passes the inner response to the client
	unchanged. The difference between this scenario and the scenarios in		unchanged. The difference between this scenario and the scenarios in
	Section 2.5.1 is that the signature on the PKIResponse is generated		Section 2.5.1 is that the signature on the PKIResponse is generated
	by the CA not the RA.		by the CA not the RA.
	Note that the additional round trips to prove possession of an		Note that the additional round trips to prove possession of an
	skipping to change at page 18, line 53 ¶		skipping to change at page 21, line 5 ¶
	PKIData ::= SEQUENCE {		PKIData ::= SEQUENCE {
	controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,		controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
	reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,		reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
	cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,		cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
	otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg		otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
	}		}
	[RFC5272] defines PKIResponse as follows (included here for		[RFC5272] defines PKIResponse as follows (included here for
	convenience):		convenience):
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	PKIResponse ::= SEQUENCE {		PKIResponse ::= SEQUENCE {
	controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,		controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
	I-D CMC Extensions: Server Key Generation July 30, 2013
	cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,		cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
	otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg		otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
	}		}
	3.1. Client Requests		3.1. Client Requests
	When the client generates their request, the Server Key Generation		When the client generates its request, the Server Key Generation
	Request control (see Section 6.1) is included in controlSequence; the		Request control (see Section 6.1) is included in controlSequence; the
	other sequences (i.e., reqSequence, cmsSequence, and		other sequences (i.e., reqSequence, cmsSequence, and
	otherMsgSequence) are omitted. If a shared secret is used for		otherMsgSequence) are omitted. If a shared secret is used for
	authentication, the Identification control [RFC5272] is included in		authentication, the Identification control [RFC5272] is included in
	the controlSequence to ensure that the server can locate the shared-		the controlSequence to ensure that the server can locate the shared-
	secret needed to authenticate the request. Additional controls can		secret needed to authenticate the request. Additional controls can
	be included in controlSequence such as Sender Nonce and Transaction		be included in controlSequence such as Sender Nonce and Transaction
	Identifier [RFC5272]. The reqSequence, which is included for client-		Identifier [RFC5272]. The reqSequence, which is included for client-
	generated key certification requests, is not needed as the Server Key		generated key certification requests, is not needed as the Server Key
	Generation Request control includes the certification request. The		Generation Request control includes the certification request. The
	client's request is either encapsulated in an AuthenticatedData or a		client's request is either encapsulated in an AuthenticatedData or a
	SignedData depending on whether the client is using a shared secret		SignedData depending on whether the client is using a shared secret
	or a digital signature key to authenticate the request. If the		or a digital signature key to authenticate the request. If the
	client wishes to request a certificate with a different name than the		client wishes to request a certificate with a different name than the
	one that is present in the certificate that authenticates the		one that is present in the certificate that authenticates the request
	request, the client includes the Change Subject Name control		or associated with the shared secret, the client must nevertheless
	[RFC6402] to ensure the server will not reject the request because		populate the certificateRequest with the Subject Name used in the
	the name in the certificate used to sign the request does not match		existing certificate, and then include the Change Subject Name
	the name in the request.		control to identify the Subject Name that is desired instead.
			Otherwise the server will reject the request as required in
			[RFC6402].
	3.2. RA Processing of Client Requests		3.2. RA Processing of Client Requests
	If an RA is involved, then it can do the following:		If an RA is involved, then it can do the following:
	o Forward the request as-is to the CA. This happens when the CA		o Forward the request as-is to the CA. This happens when the CA
	authenticates the request, performs the Identity checks, and		authenticates the request, performs the identity checks, and
	generates the keys.		generates the keys.
	o Not authenticate the request and place one or more client PKIData		o Authenticate or not the request and place one or more client-
	in cmsSequence; reqSequence and otherMsgSequence are omitted.		authenticated PKIData in cmsSequence; reqSequence and
	Here the RA does not have the shared secret necessary to		otherMsgSequence are omitted. Here the RA does not have the
	authenticate the request. The RA can also include additional		shared secret necessary to authenticate the request. The RA can
	controls in controlSequence such as the Modify Certification		also include additional controls in controlSequence such as the
	Request control if the RA needs to modify the client's request		Modify Certification Request control if the RA needs to modify
	and the Sender Nonce and Transaction Identifier controls for		the client's request and the Sender Nonce and Transaction
	replay protection and transaction processing. If the RA performs		Identifier controls for replay protection and transaction
	the Identity checks it can include the RA Identity Witness
	control. After generation of the PKIData, the RA encapsulates it
	in a SignedData as part of the digital signature process.
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	o Authenticate the request and place one or more client PKIData in		processing. If the RA performs the Identity checks it can
	cmsSequence; reqSequence and otherMsgSequence are omitted. The		include the RA Identity Witness control [RFC6402] otherwise it is
	RA can also include additional controls in controlSequence such		omitted. After generation of its PKIData, the RA encapsulates it
	as the Modify Certification Request control if the RA needs to		in a SignedData as part of the digital signature process.
	modify the client's request in the Server Key Generation Request
	control and Sender Nonce and Transaction Identifier for replay
	protection and transaction control. If the RA also performs the
	Identity check, it includes the Identity Proof Witness control
	[RFC6402] otherwise it is omitted. After generation of the
	PKIData, the RA encapsulates it in a SignedData as part of the
	digital signature process.
	o Authenticate the request and generate the client's keys. When		o Authenticate the request and generate the client's keys. When
	the RA generates the client's key, the RA generates a new PKIData		the RA generates the client's key, the RA generates a new PKIData
	with a reqSequence; cmsSequence and otherMsgSequence are omitted.		with a reqSequence; cmsSequence and otherMsgSequence are omitted.
	The RA includes the Change Subject Name attribute, as specified		The RA must assert its own name as the Subject Name in the
	in [RFC6402], in the PKCS#10 or CRMF because the name in the		certificateRequest, and include the Change Subject Name attribute
	request will not match the name in the certificate used to		carrying the intended client name, as specified in [RFC6402], in
			the PKCS#10 or CRMF because [RFC6402] requires that the name in
			the request will match the name in the certificate used to
	authenticate the request. If the RA-generated key is signature-		authenticate the request. If the RA-generated key is signature-
	capable, POP is provided in the typical fashion (i.e., the		capable, POP is provided in the typical fashion (i.e., the
	embedded CRMF or PKCS#10 request includes the POP). The RA can		embedded CRMF or PKCS#10 request includes the POP). The RA can
	also include additional controls in controlSequence such as		also include additional controls in controlSequence such as
	Sender Nonce and Transaction Identifier. After generation of the		Sender Nonce and Transaction Identifier. After generation of its
	PKIData, the RA encapsulates it in a SignedData as part of the		PKIData, the RA encapsulates it in a SignedData as part of the
	digital signature process.		digital signature process.
	o Reject the client's request and return a PKIResponse with an		o Reject the client's request and return a PKIResponse with an
	appropriate reason in the CMC Status Information V2 control.		appropriate reason in the CMC Status Information V2 control.
	Additionally, the RA includes Transaction Identifier, Sender		Additionally, the RA includes Transaction Identifier, Sender
	Nonce, and Recipient Nonce if the request included Transaction		Nonce, and Recipient Nonce if the request included Transaction
	Identifier and Sender Nonce controls. The PKIResponse is		Identifier and Sender Nonce controls. The PKIResponse is
	encapsulated in a SignedData as part of the digital signature		encapsulated in a SignedData as part of the digital signature
	process. This document defines three error conditions (see		process. This document defines three additional error conditions
	Section 7):		(see Section 7):
	* For a Server Key Generation Request control using the		* For a Server Key Generation Request control using the
	ShroudWithPublicKey choice of certificate or certIdentifier,		ShroudWithPublicKey choice of certificate or certIdentifier,
	the RA can check that the certificate provided to protect the		the RA can check that the certificate provided to protect the
	returned private key validates back to an authorized TA. If		returned private key validates back to an authorized TA. If
	the certificate does not validate back to their TA, then the RA		the certificate does not validate back to its TA, then the RA
	returns a PKIResponse with a CMC Status Information v2 control		returns a PKIResponse with a CMC Status Information v2 control
	indicating the request failed with an extendedFailInfo		indicating the request failed with an extendedFailInfo
	indicating badCertificate (see Section 7) encapsulated in a		indicating badCertificate (see Section 7) encapsulated in a
	SignedData. Note that the RA performing this check will lessen		SignedData. Note that the RA performing this check will lessen
	the load on the CA, but it need only be done by the RA when the		the load on the CA, but it need only be done by the RA when the
	RA is generating the client's keys; when the CA is generating		RA is generating the client's keys; when the CA is generating
	the keys technically it's up to the CA to perform this check if		the keys technically it's up to the CA to perform this check if
	it receives a CA-generated key request from a client.		it receives a CA-generated key request from a client.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	* For a Server Key Generation Request control using the		* For a Server Key Generation Request control using the
	ShroudWithSharedSecret choice and where the RA knows the shared		ShroudWithSharedSecret choice and where the RA knows the shared
	secret, the RA will reject the request if the shared secret		secret, the RA will reject the request if the shared secret
	does not match the one on the RA by returning a PKIResponse		does not match the one on the RA by returning a PKIResponse
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	with a CMC Status Information control indicating the request		with a CMC Status Information control indicating the request
	failed with an extendedFailInfo indicating badSharedSecret (see		failed with an extendedFailInfo indicating badSharedSecret (see
	Section 7) encapsulated in a SignedData. This is done because		Section 7) encapsulated in a SignedData. This is done because
	client authentication failed.		client authentication failed or the HMAC output was corrupted.
	* For a Server Key Generation Request control that has archiveKey		* For a Server Key Generation Request control that has archiveKey
	set to TRUE, the RA is generating the client's keys, and the RA		set to TRUE, the RA is generating the client's keys, and the RA
	does not support archive, the RA will reject the request by		does not support archive, the RA will reject the request by
	returning a PKIResponse with a CMC Status Information v2		returning a PKIResponse with a CMC Status Information v2
	control indicating the request failed with an extendedFailInfo		control indicating the request failed with an extendedFailInfo
	indicating archiveNotSupported (see Section 7) encapsulated in		indicating archiveNotSupported (see Section 7) encapsulated in
	a SignedData. If the RA knows the CA also does not support		a SignedData. If the RA knows the CA also does not support
	archival of keys, the RA, if it wishes, can reject the		archival of keys, the RA, if it wishes, can reject the request
	certificate in the same fashion; when the CA is generating the		in the same fashion; when the CA is generating the keys,
	keys, technically it is up to the CA to perform this check if		technically it is up to the CA to perform this check if it
	it receives a CA-generated key request from a client. Note		receives a CA-generated key request from a client. Note that
	that the RA performing this check will lessen the load on the		the RA performing this check will lessen the load on the CA,
	CA, but it need only be done by the RA when the RA is		but it need only be done by the RA when the RA is generating
	generating the client's keys; when the CA is generating the		the client's keys.
	keys technically it is up to the CA to perform this check if it
	receives a CA-generated key request from a client.
	RA's can also batch more than one request together, by including each		RA's can also batch more than one request together, by including each
	client request in a separate cmsSequence or reqSequence (for Simple		client request in a separate cmsSequence or reqSequence (for Simple
	PKI requests) along with a Batch Request control in the RA's		PKI requests) along with a Batch Request control in the RA's
	PKIRequest control field. After generation of the PKIData, the RA		PKIRequest control field. After generation of the PKIData, the RA
	encapsulates it in a SignedData as part of the digital signature		encapsulates it in a SignedData as part of the digital signature
	process.		process.
	When verifying SignedData signatures, the RA verifies it back to an		When verifying SignedData signatures, the RA verifies it back to an
	authorized TA.		authorized TA.
	3.3. CA Processing		3.3. CA Processing
	Receipt of a PKIResponse with a CMC Status Information control that
	indicates failed results requires an out-of-band mechanism to
	adjudicate the error in order to avoid a loop between the client/RA
	and CA.
	CA processing of requests depends on the number of layers of		CA processing of requests depends on the number of layers of
	encapsulation:		encapsulation:
	o Requests with a single layer of encapsulation will be validated		o Requests with a single layer of encapsulation will be validated
	back to an authorized TA if they are encapsulated in a SignedData		back to an authorized TA if they are encapsulated in a SignedData
	I-D CMC Extensions: Server Key Generation July 30, 2013
	or authenticated with the shared secret if they are encapsulated		or authenticated with the shared secret if they are encapsulated
	in an AuthenticatedData. For AuthenticatedData encapsulated		in an AuthenticatedData. For AuthenticatedData encapsulated
	requests the server locates the necessary shared secret with the		requests the server locates the necessary shared secret with the
	information found in the Identification control. For a PKIRequst		information found in the Identification control. For a
	with a reqSequence, the server verifies the POP. Regardless of		PKIRequest with a reqSequence, the server verifies the POP.
	the encapsulation technique, the server performs the Identity		Regardless of the encapsulation technique, the server performs
	checks and processes other controls such as Transaction		the Identity checks and processes other controls such as
	Identifier and Sender Nonce. If any of these checks fail or		Transaction Identifier and Sender Nonce. If any of these checks
	processing of a control fails, the CA rejects the certification		fail or processing of a control fails, the CA rejects the
	request with the appropriate error code, as specified in		certification request with the appropriate error code, as
	[RFC5272].		specified in [RFC5272].
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	o Requests with multiple layers of encapsulation (i.e., those		o Requests with multiple layers of encapsulation (i.e., those
	requests that are RA-involved) will first validate the signature		requests that are RA-involved) will first validate the signature
	on the outer SignedData back to an authorized TA and process any		on the outer SignedData back to an authorized TA and process any
	controls present such as RA Identity Witness, Modify Certificate		controls present such as RA Identity Witness, Modify Certificate
	Template, Sender Nonce, and Transaction Identifier, as per		Template, Sender Nonce, and Transaction Identifier, as per
	[RFC5272][RFC6402]. Inner requests are also processed as		[RFC5272][RFC6402]. Inner requests are also processed as
	specified in the previous bullet. Failure to validate back to an		specified in the previous bullet. Failure to validate back to an
	authorized TA or control processing failures result in rejected		authorized TA or control processing failures result in rejected
	requests with the appropriate error code, as specified in		requests with the appropriate error code, as specified in
	[RFC5752].		[RFC5272].
	CAs may require that the RA prove that it has possession of		CAs may require that the RA prove that it has possession of
	encryption-only keys that do not support one-time signature use, by		encryption-only keys that do not support one-time signature use, by
	returning a PKIResponse indicating the request failed because POP is		returning a PKIResponse indicating the request failed because POP is
	required and including the Encrypted POP control along with other		required and including the Encrypted POP control along with other
	appropriate controls. The response is signed by the CA. See Section		appropriate controls. The response is signed by the CA. See Section
	2.5.1.		2.5.1.
	After successfully authenticating the request and verifying the		After successfully authenticating the request and verifying the
	client's identity, the CA generates:		client's identity, the CA generates:
	skipping to change at page 22, line 50 ¶		skipping to change at page 24, line 38 ¶
	o Responses for single layer encapsulated requests for RA-generated		o Responses for single layer encapsulated requests for RA-generated
	keys by issuing the certificate. If no controls were present in		keys by issuing the certificate. If no controls were present in
	the request (see Appendix B), the PKIResponse is a Simple PKI		the request (see Appendix B), the PKIResponse is a Simple PKI
	Response [RFC5751], which includes no content and therefore no		Response [RFC5751], which includes no content and therefore no
	signature. With controls (e.g., Transaction Identifier, Sender		signature. With controls (e.g., Transaction Identifier, Sender
	Nonce, and Recipient Nonce), the PKIResponse includes the		Nonce, and Recipient Nonce), the PKIResponse includes the
	appropriate controls and is signed by the CA. The CA places the		appropriate controls and is signed by the CA. The CA places the
	certificate in the SignedData certificates field.		certificate in the SignedData certificates field.
	o Responses for multi-layered encapsulation requests for RA-		o Responses for multi-layered encapsulation requests for RA-
	generated keys (See Appendix B) beginning with the previous		generated keys (See Appendix B) beginning as with the previous
	bullet followed by placing the inner response in a cmsSequence		bullet to form the inner response. This is placed in
	entry. The outer PKIResponse includes the Batch Response control		cmsSequences of the outer PKIResponse, which also includes the
	as well as any other necessary controls in controlSequence and		Batch Response control as well as any other necessary controls in
	the CA generates a signature for the SignedData.		controlSequence. The CA generates a signature for the
			encapsulating SignedData.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	o Responses for single layer encapsulated requests for CA-generated		o Responses for single layer encapsulated requests for CA-generated
	keys by generating the asymmetric key pair and issuing the		keys by generating the asymmetric key pair and issuing the
	certificate. The signed CA-generated PKIResponse includes the		certificate. The signed CA-generated PKIResponse includes the
	Server Key Generation Response control (see Section 6.2) along		Server Key Generation Response control (see Section 6.2) along
	with other controls based on whether they were present in the		with other controls based on whether they were present in the
	controlSequence as well as the signed and then encrypted		controlSequence as well as the signed and then encrypted
	Asymmetric Key Package in cmsSequence. The CA places the		Asymmetric Key Package in cmsSequence. The CA places the
	certificate in the SignedData certificates field.		certificate in the SignedData certificates field.
	o Responses for multi-layered encapsulation requests for CA-		o Responses for multi-layered encapsulation requests for CA-
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	generated keys beginning with the previous bullet followed by		generated keys beginning with the previous bullet followed by
	encapsulating the inner response in cmsSequence. The outer		encapsulating the inner response in cmsSequence for the outer
	response includes controls as necessary in controlSequence and		PKIResponse. The outer response also includes controls as
	the CA generates a signature.		necessary in controlSequence and the CA generates a signature for
			an encapsulating SignedData.
			In all cases, the certificate issued is an X.509 certificate
			[RFC5280].
	If the CA is unable to perform the request at this time or the entire		If the CA is unable to perform the request at this time or the entire
	request cannot be processed, it can return a signed PKIResponse		request cannot be processed, it can return a signed PKIResponse
	indicating with a CMC Status Information control with a status of		indicating with a CMC Status Information control with a status of
	pending or partial along with pendInfo, which the client uses to know		pending or partial along with pendInfo, which the client or RA uses
	when to ask the CA next about the request.		to know when to ask the CA next about the request.
	When the CA fails to or refuses to process the request, it returns a		When the CA fails to or refuses to process the request, it returns a
	PKIResponse with a CMC Status Information control with the		PKIResponse with a CMC Status Information control with the
	appropriate error code from [RFC5272] or from Section 7 of this		appropriate error code from [RFC5272] or from Section 7 of this
	document. Additionally, it includes Transaction Identifier, Sender		document. Additionally, it includes Transaction Identifier, Sender
	Nonce, and Recipient Nonce in the response if the request included		Nonce, and Recipient Nonce in the response if the request included
	Transaction Identifier and Sender Nonce controls.		Transaction Identifier and Sender Nonce controls.
	3.4. RA Processing of CA Responses		3.4. RA Processing of CA Responses
	If the CA rejected the RA's request as indicated by a PKIResponse		If the CA rejected the RA's request as indicated by a PKIResponse
	with CMC Status Information control that is failed, then an out-of-		with CMC Status Information control that indicates "failed", then an
	band mechanism may be necessary to determine the cause of failure in		out-of-band mechanism may be necessary to determine the cause of
	order to avoid a loop of the RA returning the same request at a later		failure in order to avoid a loop of the RA returning the same request
	time only to also have it rejected.		at a later time only to also have it rejected.
	If the CA returned a pending or partial response, the RA will use the		If the CA returned a pending or partial response, the RA will use the
	information in the CMC Status Information control's pendInfo to poll		information in the CMC Status Information control's pendInfo to poll
	the CA with a signed PKIRequest with a Query Pending control. CA		the CA with a signed PKIRequest with a Query Pending control. CA
	processing continues as in Section 3.3.		processing continues as in Section 3.3.
	RA's that are challenged by the CA to prove possession of an		RA's that are challenged by the CA to prove possession of an
	encryption-only RA-generated key validate the CA's signature back to		encryption-only RA-generated key validate the CA's signature back to
	an authorized TA, decrypt the POP, and process any other controls		an authorized TA, decrypt the POP, and process any other controls
	that are present. If any of these fail, then the RA terminate the		that are present. If any of these fail, then the RA terminates the
	request and inform the operator of the fault. Assuming the checks		request and informs the operator of the fault. Assuming the checks
	pass, the RA generates a PKIData that includes a Decrypted POP		pass, the RA generates a PKIData that includes a Decrypted POP
	control and any other controls with no cmsSequence, reqSequence, or		control and any other controls with no cmsSequence, reqSequence, or
			otherMsgSequence. The RA encapsulates the PKIData in a SignedData as
	I-D CMC Extensions: Server Key Generation July 30, 2013		part of the digital signature process and sends it to the CA. CA
			processing resumes as in Section 3.3.
	otherMsgSequence. The RA encapsulates the PKIData or the PKIResponse
	in a SignedData as part of the digital signature process and sends it
	to the CA. CA processing resumes as in Section 3.3.
	Assuming the response is a success:		Assuming the response is a success:
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	o If there is no signature, either the keys are RA-generated or are		o If there is no signature, either the keys are RA-generated or are
	client-generated. If the keys are client-generated, then the RA		CA-generated. If the keys are CA-generated, then the RA returns
	returns the message to the client unmodified. If the key is RA-		the message to the client unmodified. If the key is RA-
	generated, the RA generates a PKIResponse for the client that		generated, the RA generates a PKIResponse for the client that
	includes the signed and then encrypted Asymmetric Key Package in		includes the signed and then encrypted Asymmetric Key Package in
	cmsSequence (see Section 5), the Server Key Generation Response		cmsSequence (see Section 5), the Server Key Generation Response
	control (see Section 6.2), and any other controls. Finally, the		control (see Section 6.2), and any other controls. Finally, the
	RA encapsulates the PKIResponse for the client in a SignedData as		RA encapsulates the PKIResponse for the client in a SignedData as
	part of the digital signature process and includes the client's		part of the digital signature process and includes the client's
	certificate (from the CA) in the SignedData's certificate field.		certificate (from the CA) in the SignedData's certificate field.
	o If there is a signature:		o If there is a signature:
	skipping to change at page 24, line 39 ¶		skipping to change at page 26, line 33 ¶
	controls (and possibly other controls) but there is no		controls (and possibly other controls) but there is no
	cmsSequence or CMC Status Information control indicating the		cmsSequence or CMC Status Information control indicating the
	request failed or is pending. The RA generates a PKIResponse		request failed or is pending. The RA generates a PKIResponse
	for the client that includes the signed and then encrypted		for the client that includes the signed and then encrypted
	Asymmetric Key Package in cmsSequence (see Section 5), the		Asymmetric Key Package in cmsSequence (see Section 5), the
	Server Key Generation Response control (see Section 6.2), and		Server Key Generation Response control (see Section 6.2), and
	any other controls as appropriate. Finally, the RA		any other controls as appropriate. Finally, the RA
	encapsulates the PKIResponse for the client in a SignedData as		encapsulates the PKIResponse for the client in a SignedData as
	part of the digital signature process and includes the client's		part of the digital signature process and includes the client's
	certificate from the CA's response in the RA's SignedData		certificate from the CA's response in the RA's SignedData
	certificate field.		certificates field.
	* The response is for a request where the CA generated the key		* The response is for a request where the CA generated the key
	and the RA knows this by the presence of a cmsSequence element.		and the RA knows this by the presence of a cmsSequence element.
	The RA processes any controls and assuming the processing		The RA processes any controls and assuming the processing
	passes the RA strips off the outer SignedData and forwards the		passes the RA strips off the outer SignedData and forwards the
	cmsSequence element (i.e., the SignedData) to the client.		cmsSequence element (i.e., the SignedData) to the client.
	* The response is for a batch request and the RA knows this by		* The response is for a batch request and the RA knows this by
	the presence of a Batch Response control. The RA process any		the presence of a Batch Response control. The RA process any
	controls and assuming the processing passes the RA strips off		controls and assuming the processing passes the RA strips off
	the outer SignedData and forwards the inner SignedData(s) from		the outer SignedData and forwards the inner SignedData(s) from
	the cmsSequence to the appropriate clients. If any of the		the cmsSequence to the appropriate clients. If any of the
	requests are marked as failed or pending, then the processing		requests are marked as failed or pending, then the processing
	earlier in this section applies.		earlier in this section applies.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	The RA, if it wishes, can also check the returned certificate to make		The RA, if it wishes, can also check the returned certificate to make
	sure it validates back to an authorized TA and that the returned		sure it validates back to an authorized TA and that the returned
	certificate is consistent with the certificate request found in the		certificate is consistent with the certificate request found in the
	Server Key Generation Request control. These checks cut down on		Server Key Generation Request control. These checks cut down on
	errors at the client. If the RA detects that the certificate is not		errors at the client. If the RA detects that the certificate is not
	consistent, the SHOULD NOT return the certificate to the client and		consistent, the RA SHOULD NOT return the certificate to the client
	the RA SHOULD request that the certificate be revoked.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
			and the RA SHOULD request that the certificate be revoked.
	RA-generated keys for which a PKIResponse with a CMC Status		RA-generated keys for which a PKIResponse with a CMC Status
	Information control that is not success SHOULD NOT return the Server		Information control that is not success SHOULD NOT return the Server
	Key Generation Response or the encapsulated Asymmetric Key Package to		Key Generation Response or the encapsulated Asymmetric Key Package to
	the client because the the CA didn't certify the public key.		the client because the CA didn't certify the public key.
	3.4. Client Processing of Responses		3.5. Client Processing of Responses
	Clients validate the signature on all responses back to an authorized		Clients validate the signature on all responses back to an authorized
	TA.		TA.
	Responses signed by an RA with a client certificate signed by a CA		Responses signed by an RA with a client certificate signed by a CA
	whose certificate includes a id-kp-cmcCA EKU (Extended Key Usage)		whose certificate includes a id-kp-cmcCA EKU (Extended Key Usage)
	[RFC6402] will violate the should requirement found in [RFC6042] that		[RFC6402] will violate the "SHOULD" requirement found in [RFC6402]
	the PKIResponse be signed with an entity with the same name as the		that the PKIResponse be signed by an entity with the same name as
	certificate. Because the RA has generated the keys there are many		found in the certificate. Because the RA has generated the keys
	more bad things an RA can do so this seemed like a tradeoff worth		there are many more bad things an RA can do so this seemed like a
	making.		tradeoff worth making.
	4. Shrouding Algorithms		4. Shrouding Algorithms
	For the server-side key generation control attribute described in		For the server-side key generation control attribute described in
	this document to function, clients need to tell the server in advance		this document to function, clients need to tell the server in advance
	what encryption algorithm and what key value is to be used for		what encryption algorithm and what key value is to be used for
	encrypting the returned private key. The encrypted data returned is		encrypting the returned private key. The encrypted data returned is
	returned as an EnvelopedData object as defined by [RFC5652] and		returned as an EnvelopedData object as defined by [RFC5652] and
	placed in the cmsSequence field of a PKIResponse [RFC5272]. Clients		placed in the cmsSequence field of a PKIResponse [RFC5272]. Clients
	also need to tell the server in advance what digital signature and		also need to tell the server what digital signature and hash
	hash algorithms it supports to ensure the certification response and		algorithms it supports to ensure the certification response and
	certificate can be verified.		certificate can be verified.
	Each request control for which the response includes encrypted data		Each request control for which the response includes encrypted data
	contains two fields to define type of encryption used:		contains two fields to define type of encryption used:
	algCapabilities and shroudMethod.		algCapabilities and shroudMethod.
	The algCapabilities field, see Section 6.1, contains the advertised		The algCapabilities field, see Section 6.1, contains the advertised
	capabilities of the client-side entity. This field uses the S/MIME		capabilities of the client-side entity. This field uses the S/MIME
	Capabilities type defined in section 2.5.2 of [RFC5751]. The		Capabilities type defined in section 2.5.2 of [RFC5751]. The
	capabilities to be listed are digital signature algorithms, message		capabilities to be listed are digital signature algorithms, message
	digest algorithms, content encryption algorithms, key agreement		digest algorithms, content encryption algorithms, key agreement
	algorithms, key encipherment algorithms, key-wrap algorithms and key		algorithms, key encipherment algorithms, key-wrap algorithms and key
	I-D CMC Extensions: Server Key Generation July 30, 2013
	derivation algorithms. Encodings for SMIME Capability values for		derivation algorithms. Encodings for SMIME Capability values for
	Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap		Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap
	algorithms can be found in [RFC5753], Message Digest and Signature		algorithms can be found in [RFC5753], Message Digest and Signature
	algorithms can be found in [RFC5754], and AES Key Wrap with Padding		algorithms can be found in [RFC5754], and AES Key Wrap with Padding
	can be found in [RFC5959].		can be found in [RFC5959].
	The shroudMethod field, see Section 6.1, defines the method by which		I-D CMC Extensions: Server Side Key Generation March 27, 2014
			The shroudMethod field (see Section 6.1) defines the method by which
	the server will do the key management of the content encryption key		the server will do the key management of the content encryption key
	(CEK) value in EnvelopedData. The shroudMethod field uses the type		(CEK) value in EnvelopedData. The shroudMethod field uses the type
	ShroudMethod. This type is defined as:		ShroudMethod. This type is defined as:
	ShroudMethod ::= AlgorithmIdentifier {		ShroudMethod ::= AlgorithmIdentifier {
	SHROUD-ALGORITHM, { ShroudAlgorithmSet }		SHROUD-ALGORITHM, { ShroudAlgorithmSet }
	}		}
	When a new shroud method is defined it includes (a) the source of the		When a new shroud method is defined it includes (a) the source of the
	key material, (b) the public or salting information, and (c) the		key material, (b) the public or salting information, and (c) the
	method of protecting the Content Encryption Key (CEK) using the		method of protecting the Content Encryption Key (CEK) using the
	requested data, source key material and salt. This document defines		requested data, source key material and salt. This document defines
	skipping to change at page 26, line 37 ¶		skipping to change at page 28, line 31 ¶
	shroudWithSharedSecret. Clients and servers MUST support id-cmc-		shroudWithSharedSecret. Clients and servers MUST support id-cmc-
	shroudWithPublicKey. Client and servers SHOULD support id-cmc-		shroudWithPublicKey. Client and servers SHOULD support id-cmc-
	shroudWithSharedSecret.		shroudWithSharedSecret.
	Other shrouding methods could be defined in the future that would not		Other shrouding methods could be defined in the future that would not
	involve the use of EnvelopedData. For example, one could conceive of		involve the use of EnvelopedData. For example, one could conceive of
	a shrouding method that required the use of Transport Layer Security		a shrouding method that required the use of Transport Layer Security
	(TLS) [RFC5246] to provide the necessary security between the server		(TLS) [RFC5246] to provide the necessary security between the server
	and the client. This document does not define any such mechanism.		and the client. This document does not define any such mechanism.
	4.1. Shroud With a Public Key		4.1. Shroud with a Public Key
	Clients can indicate that the server use a public key, either wrapped		Clients can indicate that the server use a public key, either wrapped
	in a certificate or as a bare public key, to protect the server-		in a certificate or as a bare public key, to protect the server-
	generated key. For this option, the key material is either included		generated key. For this option, the key material is either included
	or referenced by a key identifier. The following object identifier		or referenced by a key identifier. The following object identifier
	identifies the shroudWithPublicKey shroud method:		identifies the shroudWithPublicKey shroud method:
	id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= { id-cmc XX }		id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= { id-cmc XX }
	shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey:		shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey:
	srda-shroudWithPublicKey SHROUD-ALGORITHM ::= {		srda-shroudWithPublicKey SHROUD-ALGORITHM ::= {
	IDENTIFIED BY id-cmc-shroudWithPublicKey,		IDENTIFIED BY id-cmc-shroudWithPublicKey,
	PARAMS TYPE ShroudWithPublicKey ARE required,		PARAMS TYPE ShroudWithPublicKey ARE required,
	SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithPublicKey }		SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithPublicKey }
	}		}
	I-D CMC Extensions: Server Key Generation July 30, 2013
	ShroudWithPublicKey ::= CHOICE {		ShroudWithPublicKey ::= CHOICE {
	certificate Certificate,		certificate Certificate,
	certIdentifier [1] SignerIdentifier,		certIdentifier [1] SignerIdentifier,
	bareKey [2] SEQUENCE {		bareKey [2] SEQUENCE {
	publicKey SubjectPublicKeyInfo,		publicKey SubjectPublicKeyInfo,
	ski SubjectKeyIdentifier		ski SubjectKeyIdentifier
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	}		}
	}		}
	The fields of type ShroudWithPublicKey have the following meanings:		The fields of type ShroudWithPublicKey have the following meanings:
	o certificate provides a public key certificate containing the		o certificate provides a public key certificate containing the
	public key to be used for encrypting the server-generated private		public key to be used for encrypting the server-generated private
	key from the server to the client.		key from the server to the client.
	o certIdentifier provides a pointer to a public key certificate		o certIdentifier provides a pointer to a public key certificate
	located in the SignedData that encapsulates the client's PKIData.		located in the SignedData that encapsulates the client's PKIData.
	For the above two fields, servers SHOULD check that the subject		For the above two fields, servers SHOULD check that the subject
	and subject alternative names match in some way with the entity		and, if included, subject alternative names match in some way
	that the private key is destined for.		with the entity that the private key is destined for. Servers do
			this to ensure the key they have made for the client is intended
			for the correct client. This mechanism is beyond the scope of
			this document.
	o bareKey allows for an arbitrary public key to be used to return		o bareKey allows for an arbitrary public key to be used to return
	the encrypted private key.		the encrypted private key.
	- publicKey contains the public key that is to be used for		- publicKey contains the public key that is to be used for
	encrypting the private key returned from the server to the		encrypting the private key returned from the server to the
	client.		client.
	- ski contains the SubjectKeyIdentifier that will be used in CMS		- ski contains the SubjectKeyIdentifier that will be used in CMS
	EnvelopedData to identify the public key when encrypting the		EnvelopedData to identify the public key when encrypting the
	skipping to change at page 27, line 49 ¶		skipping to change at page 29, line 46 ¶
	When this method is used with the certificate option, the server		When this method is used with the certificate option, the server
	validates the certificate back to a trust anchor. Further, the		validates the certificate back to a trust anchor. Further, the
	server checks that the client provided certificate belongs to the		server checks that the client provided certificate belongs to the
	same client that authenticated the certification request (e.g. the		same client that authenticated the certification request (e.g. the
	certificate subjects match, or the client provided certificate		certificate subjects match, or the client provided certificate
	belongs to the same entity as the authentication shared secret). If		belongs to the same entity as the authentication shared secret). If
	either of these checks fails, then the server returns a CMCFailInfo		either of these checks fails, then the server returns a CMCFailInfo
	with the value of badCertificate, which is defined in Section 7.		with the value of badCertificate, which is defined in Section 7.
	4.2. Shroud With a Shared-Secret Key		4.2. Shroud with a Shared-Secret Key
	Clients can indicate that servers use a shared secret value to		Clients can indicate that servers use a shared secret value to
	protect the server-generated private key. For this option, the key		protect the server-generated private key. For this option, the key
	material is identified by the identifier, the key derivation		material is identified by the identifier; the key derivation
	algorithms supported by the client are included in the		algorithms supported by the client are included in the
	I-D CMC Extensions: Server Key Generation July 30, 2013
	algCapabilities field. No salting material is provided by the		algCapabilities field. No salting material is provided by the
	client. The derived key is then used as a key encryption key in the		client. The derived key is then used as a key encryption key in the
	EnvelopedData recipient info structure. The following object		EnvelopedData recipient info structure. The following object
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	identifier identifies the shroudWithSharedSecret control attribute:		identifier identifies the shroudWithSharedSecret control attribute:
	id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX}		id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX}
	shroudWithSharedSecret attribute values have the ASN.1 type		shroudWithSharedSecret attribute values have the ASN.1 type
	ShroudWithSharedSecret:		ShroudWithSharedSecret:
	shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= {		shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= {
	IDENTIFIED BY id-cmc-shroudWithSharedSecret		IDENTIFIED BY id-cmc-shroudWithSharedSecret
	PARAMS TYPE ShroudWithSharedSecret ARE required		PARAMS TYPE ShroudWithSharedSecret ARE required
	SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithSharedSecret }		SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithSharedSecret }
	}		}
	ShroudWithSharedSecret ::= UTF8String		ShroudWithSharedSecret ::= UTF8String
	The common identification string for the client and the server is		The client includes an identifier in the ShroudWithSharedSecret
	placed in the ShroudWithSharedSecret field, which is a UTFString		field, which is an UTFString [RFC5280], that the server uses to
	[RFC5280]. In addition the client needs to place both a key		locate the shared secret to be used to protect the returned server-
	derivation function and a key wrap function in the set of		generated private key. The secret identified by the
	capabilities advertised by the client in the algCapabilities field.		ShroudWithSharedSecret field may be different than the secret
	The identification string is used to identify the pass phrase or		referred to by the identification control, which is used to identify
	shared key.		the shared secret used to authenticate the request. In addition, the
			client needs to place both a key derivation function and a key wrap
			function in the set of capabilities advertised by the client in the
			algCapabilities field.
	When this method is used, the server checks that the chosen shared		When this method is used, the server checks that the chosen shared
	secret belongs to the authenticated identity of the entity that		secret belongs to the authenticated identity of the entity that
	generated the certification request. If this check fails, then the		generated the certification request. If this check fails, then the
	server returns a CMCFailInfo with the value of badSharedSecret, which		server returns a CMCFailInfo with the value of badSharedSecret, which
	is defined in Section 7. In general, while it is expected that the		is defined in Section 7. In general, while it is expected that the
	same identity token and shared secret used to do the identity		same identity token and shared secret used to do the identity
	authentication are used to derive the key encryption key this is not		authentication are used to derive the key encryption key this is not
	required.		required.
	skipping to change at page 29, line 5 ¶		skipping to change at page 31, line 5 ¶
	[RFC5958]. The AsymmetricKeyPackage is first encapsulated in a		[RFC5958]. The AsymmetricKeyPackage is first encapsulated in a
	Cryptographic Message Syntax (CMS) SignedData content type [RFC5652],		Cryptographic Message Syntax (CMS) SignedData content type [RFC5652],
	then the inner SignedData is further encapsulated in an EnvelopedData		then the inner SignedData is further encapsulated in an EnvelopedData
	content type [RFC5652], and finally the EnvelopedData is encapsulated		content type [RFC5652], and finally the EnvelopedData is encapsulated
	in an outer SignedData. The Content Hints attribute [RFC2634] can be		in an outer SignedData. The Content Hints attribute [RFC2634] can be
	used in the outer SignedData to provide a hint as to the inner most		used in the outer SignedData to provide a hint as to the inner most
	content type (i.e., the AsymmetricKeyPacakge). There MUST be only		content type (i.e., the AsymmetricKeyPacakge). There MUST be only
	one OneAsymmetricKey present in the AsymmetricKeyPackage sequence.		one OneAsymmetricKey present in the AsymmetricKeyPackage sequence.
	When more than one private key is to be returned, multiple		When more than one private key is to be returned, multiple
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	AsymmetricKeyPackage content types are needed. For example, when		AsymmetricKeyPackage content types are needed. For example, when
	returning more than one private key the separate AsymmetricKeyPackage		returning more than one private key the separate AsymmetricKeyPackage
	content types can be individually encapsulated in SignedData,		content types can be individually encapsulated in SignedData,
	packaged together with the ContentCollection content type [RFC4073],		packaged together with the ContentCollection content type [RFC4073],
	protected with an EnvelopedData around the ContentCollection, and		protected with an EnvelopedData around the ContentCollection, and
	finally the EnvelopedData is encapsulated in a SignedData. The		finally the EnvelopedData is encapsulated in a SignedData. The
	public key SHOULD be included in the AsymmetricKeyPackage.		public key SHOULD be included in the AsymmetricKeyPackage.
	6. Server-Side Key Generation		6. Server-Side Key Generation
	skipping to change at page 29, line 44 ¶		skipping to change at page 31, line 44 ¶
	id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX }		id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX }
	The Server-Side Key Generation Request control attribute has the		The Server-Side Key Generation Request control attribute has the
	following ASN.1 definition:		following ASN.1 definition:
	cmc-serverKeyGenRequest CMC-CONTROL ::= {		cmc-serverKeyGenRequest CMC-CONTROL ::= {
	ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest		ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest
	}		}
	ServerKeyGenRequest ::= SEQUENCE {		ServerKeyGenRequest ::= SEQUENCE {
	certificateRequest CertTemplate,		certificateRequest TaggedRequest,
	shroudMethod ShroudMethod,		shroudMethod ShroudMethod,
	algCapabilities SMimeCapabilties OPTIONAL,		algCapabilities SMimeCapabilties OPTIONAL,
	archiveKey BOOLEAN DEFAULT TRUE		archiveKey BOOLEAN DEFAULT TRUE
	}		}
	The fields in ServerKeyGenRequest have the following meaning:		The fields in ServerKeyGenRequest have the following meaning:
	o certificateRequest contains the data fields that the client		o certificateRequest contains the data fields that the client
	suggests for the certificate being requested for the server		suggests for the certificate being requested for the server
	generated key pair. The format is TaggedRequest from [RFC5272],		generated key pair. The format is TaggedRequest from [RFC5272],
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
	which supports both PKCS#10 and CRMF requests.		which supports both PKCS#10 and CRMF requests. In all instances,
			the bodyPartID is set to zero.
	o shroudMethod contains the identifier of the type of algorithm to		o shroudMethod contains the identifier of the type of algorithm to
	be used in deriving the key used to encrypt the private key.		be used in deriving the key used to encrypt the private key.
	o algCapabilities contains the set of algorithm capabilities being		o algCapabilities contains the set of algorithm capabilities being
	advertised by the client. The server uses algorithms from this		advertised by the client. The server uses algorithms from this
	set in the ServerKeyGenResponse object to encrypt the private key		set in the ServerKeyGenResponse object to encrypt the private key
	of the server-generated key pair. This field is optional because		of the server-generated key pair. This field is optional because
	this information might be carried in a signed attribute, included		this information might be carried in a signed attribute, included
	within a certificate or be part of the local configuration.		within a certificate or be part of the local configuration.
	o archiveKey is set to TRUE if the client wishes the key to be		o archiveKey is set to TRUE if the client wishes the key to be
	archived as well as generated on the server. Further processing		archived as well as generated on the server. Further processing
	by the server when this is set to TRUE is out-of-scope.		by the server when this is set to TRUE is out-of-scope.
	The client can request that the generated key be for a specific		The client can request that the generated key be for a specific
	algorithm by placing data in the publicKey field of the CRMF request		algorithm by placing data in the publicKey.attribute field of the
	or in the subjectPKInfo of the PKCS#10 request. If the publicKey		CRMF request or in the subjectPKInfo.attribute field of the PKCS#10
	field is populated, then the public key is a zero length bit string.		request. If the publicKey or subjectPKInfo field is populated, then
	If the client requests a specific algorithm, the server either		the subjectPublicKey is a zero-length bit string. If the client
	generates a key for that algorithm (with the parameters if defined)		requests a specific algorithm, the server either generates a key for
	or fails to process the request. If the request fails for this		that algorithm (with the parameters if defined) or fails to process
	reason, the server returns a CMCFailInfo with a value of badAlg		the request. If the request fails for this reason, the server
	[RFC5272].		returns a CMCFailInfo with a value of badAlg [RFC5272].
	As specified in [RFC5272]:		As specified in [RFC5272]:
	"A server is not required to use all of the values suggested by		"A server is not required to use all of the values suggested by
	the client in the certificate template. Servers MUST be able to		the client in the certificate template. Servers MUST be able to
	process all extensions defined in [RFC5280]. Servers are not		process all extensions defined in [RFC5280]. Servers are not
	required to be able to process other V3 X.509 extensions		required to be able to process other V3 X.509 extensions
	transmitted using this protocol, nor are they required to be able		transmitted using this protocol, nor are they required to be able
	to process other, private extensions. Servers are permitted to		to process other, private extensions. Servers are permitted to
	modify client-requested extensions. Servers MUST NOT alter an		modify client-requested extensions. Servers MUST NOT alter an
	skipping to change at page 30, line 54 ¶		skipping to change at page 33, line 4 ¶
	exchange to digital signature.) If a certification request is		exchange to digital signature.) If a certification request is
	denied due to the inability to handle a requested extension, the		denied due to the inability to handle a requested extension, the
	server MUST respond with a CMCFailInfo with a value of		server MUST respond with a CMCFailInfo with a value of
	unsupportedExt."		unsupportedExt."
	A server that does not recognize the algorithm identified in		A server that does not recognize the algorithm identified in
	shroudMethod will reject the request. The server returns a		shroudMethod will reject the request. The server returns a
	CMCFailInfo with a value of badAlg [RFC5272].		CMCFailInfo with a value of badAlg [RFC5272].
	A server that does not support at least one of the algCapabilities		A server that does not support at least one of the algCapabilities
	will reject the request. The server returns a CMCFailInfo with a
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
			will reject the request. The server returns a CMCFailInfo with a
	value of badAlg [RFC5272].		value of badAlg [RFC5272].
	If archiveKey is set to true and the server does not support		If archiveKey is set to true and the server does not support
	archiving of private keys, the request will be rejected by the		archiving of private keys, the request will be rejected by the
	server. The server returns a CMCFailInfo with a value of		server. The server returns a CMCFailInfo with a value of
	archiveNotSupported, see Section 7.		archiveNotSupported, see Section 7.
	6.2. Server-side Key Generation Response		6.2. Server-side Key Generation Response
	The server creates a server-side key generation response attribute		The server creates a server-side key generation response attribute
	skipping to change at page 31, line 54 ¶		skipping to change at page 34, line 4 ¶
	aKeyPackage (see Section 4).		aKeyPackage (see Section 4).
	o requestBodyPartId contains the body part identifier for the		o requestBodyPartId contains the body part identifier for the
	server-side key generation request control attribute. This		server-side key generation request control attribute. This
	allows for clients to associate the resulting key and certificate		allows for clients to associate the resulting key and certificate
	with the original request.		with the original request.
	o issuerAndSerialNumber if present contains the identity of the		o issuerAndSerialNumber if present contains the identity of the
	certificate issued to satisfy the request. The certificate is		certificate issued to satisfy the request. The certificate is
	placed in the certificate bag of the immediately encapsulating		placed in the certificate bag of the immediately encapsulating
	signedData object.
	I-D CMC Extensions: Server Key Generation July 30, 2013		I-D CMC Extensions: Server Side Key Generation March 27, 2014
			SignedData object.
	As specified in [RFC5272]:		As specified in [RFC5272]:
	"Clients MUST NOT assume the certificates are in any order.		"Clients MUST NOT assume the certificates are in any order.
	Servers SHOULD include all intermediate certificates needed to		Servers SHOULD include all intermediate certificates needed to
	form complete chains to one or more self-signed certificates, not		form complete chains to one or more self-signed certificates, not
	just the newly issued certificate(s) in the certificate bag. The		just the newly issued certificate(s) in the certificate bag. The
	server MAY additionally return CRLs in the CRL bag. Servers MAY		server MAY additionally return CRLs in the CRL bag. Servers MAY
	include self-signed certificates. Clients MUST NOT implicitly		include self-signed certificates. Clients MUST NOT implicitly
	trust included self-signed certificate(s) merely due to its		trust included self-signed certificate(s) merely due to its
	skipping to change at page 32, line 49 ¶		skipping to change at page 34, line 51 ¶
	o badCertificate indicates that the certificate to be used to		o badCertificate indicates that the certificate to be used to
	encrypt the response did not validate back to a RA/CA trust		encrypt the response did not validate back to a RA/CA trust
	anchor or the certificate does not belong to the client. The		anchor or the certificate does not belong to the client. The
	syntax for the ExtendedFailInfo is as follows:		syntax for the ExtendedFailInfo is as follows:
	cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={		cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={
	IDENTIFIED BY id-tbd		IDENTIFIED BY id-tbd
	}		}
	o badSharedSecret indicates that the shared secret provided by the		o badSharedSecret indicates that the shared secret used by the
	client does not match that stored by the server.		client does not match that stored by the server.
	cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={		cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	IDENTIFIED BY id-tbd		IDENTIFIED BY id-tbd
	}		}
	I-D CMC Extensions: Server Key Generation July 30, 2013
	8. Proof-of-Possession		8. Proof-of-Possession
	Some servers may require that the client prove that it has possession		Some servers may require that the client prove that it has taken
	of the server-generated key. This requires an additional roundtrip		possession of the server-generated key. This proof requires an
	beyond those previously discussed.		additional roundtrip beyond those previously discussed.
	For certificates returned that support digital signatures the process		For certificates returned that support digital signatures the process
	is as described in [RFC5272]: the server indicates in CMCStatus is		is as described in [RFC5272]: the server indicates in CMCStatus that
	confirmRequired, the client returns the Confirm Certificate		status is confirmRequired; the client returns the Confirm Certificate
	Acceptance control in PKIData signed with the server-generated		Acceptance control in PKIData signed with the server-generated
	private key, and the server responds with a CMCStatus of success.		private key; and the server responds with a CMCStatus of success.
	For certificates returned that only support encryption, the server		For certificates returned that only support encryption, the server
	indicates the CMCStatus is popRequired and includes the Encrypted POP		indicates the CMCStatus is popRequired and includes the Encrypted POP
	control, the client returns the Decrypted POP control. Whether the		control; the client returns the Decrypted POP control. Whether the
	PKIRequest from the client is encapsulated in an Authenticated Data		PKIRequest from the client is encapsulated in an AuthenticatedData or
	or Signed Data depends on which mechanism was used during the server		SignedData depends on which mechanism was used during the server key
	key generation request.		generation request.
	9. Security Considerations		9. Security Considerations
	Central generation of digital signature keys contains risks and is		Central generation of digital signature keys contains risks and is
	not always appropriate. Organization-specific CPs (Certificate		not always appropriate. Organization-specific CPs (Certificate
	Policies) [RFC3647] define whether or not server-side generation of		Policies) [RFC3647] define whether or not server-side generation of
	digital signature keys is permitted.		digital signature keys is permitted.
	There is a balance that needs to be maintained between the use of a		For the choice of mechanisms to protect the server-generated key,
	potentially poorly generated one time key and the use of a key		there is a balance that needs to be maintained between the use of a
	externally provided. For externally provided keys, the external		potentially poorly generated one-time key (i.e., the shared secret)
	provider of the key will be able to decrypt the key delivery message		and the use of a key externally provided. For externally provided
	as long as it was captured. For poorly generated one time keys, any		keys, the external provider of the key will be able to decrypt the
	external party might be able to guess the key and thus decrypt the		key delivery message as long as it was captured. For poorly generated
	key delivery message. Different types of keys will have different		one-time keys, any external party might be able to guess the key and
	requirements for what a poorly generated key means. Generators of RSA		thus decrypt the key delivery message. Different types of keys will
	keys need to be able to do good prime checking, generators of Diffie-		have different requirements for what a poorly generated key means.
	Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) keys only need a		Generators of RSA keys need to be able to do good prime checking;
	moderate quality random number generator if the group parameters are		generators of Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman
	externally provided.		(ECDH) keys only need a moderate quality random number generator if
			the group parameters are externally provided and of good quality.
	This specification requires implementations to generate key pairs and		This specification requires implementations to generate key pairs and
	other random values [RFC4086]. The use of inadequate pseudo-random		other random values [RFC4086]. The use of inadequate pseudo-random
	number generators (PRNGs) can result in little or no security. The		number generators (PRNGs) can result in little or no security. The
	generation of quality random numbers is difficult. NIST Special		generation of quality random numbers is difficult. NIST Special
	Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer		Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	guidance.		guidance.
	Private keys, regardless of where they are generated, must be		Private keys, regardless of where they are generated, must be
	appropriately protected from disclosure or modification on the		appropriately protected from disclosure or modification on the
	I-D CMC Extensions: Server Key Generation July 30, 2013
	server, in transit, and on the client. Cryptographic algorithms and		server, in transit, and on the client. Cryptographic algorithms and
	keys used to protect the private key should be at least as strong as		keys used to protect the private key should be at least as strong as
	the private key's intended strength.		the private key's intended strength.
			This document describes the CA signing certificates and messages as
			well as encrypting messages. It should not be assumed that the CA
			uses the same key for all of these operations. In fact, CAs may wish
			to limit the exposure of their private keys by using different keys
			or different purposes.
	Key agreement algorithms (i.e., Diffie-Hellam or Elliptic Curve		Key agreement algorithms (i.e., Diffie-Hellam or Elliptic Curve
	Diffie-Hellman) can be used to protect the returned server-generated		Diffie-Hellman) can be used to protect the returned server-generated
	key. These algorithms support a number of different schemes [SP-800-		key. These algorithms support a number of different schemes [SP-800-
	56]. Normally, an Ephemeral-Static (E-S) scheme is used (more		56]. Normally, an Ephemeral-Static (E-S) scheme is used (more
	formally known as "(Cofactor) One-Pass Diffie-Hellman,		formally known as "(Cofactor) One-Pass Diffie-Hellman,
	C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides		C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides
	an ephemeral key to the server so an S-E scheme is used when the key		an ephemeral key to the server so an S-E scheme is used when the key
	is encrypted for the client. Regardless, the client needs to		is encrypted for the client. Regardless, the client needs to
	generate an ephemeral key and provide it to the server and this key		generate an ephemeral key and provide it to the server and this key
	needs to use the same parameters (i.e., p, q, g for DH and elliptic		needs to use the same parameters (i.e., p, q, g for DH and elliptic
	curve for ECDH) as the server. The client's parameters MUST be		curve for ECDH) as the server. The client's parameters MUST be
	present in the publicKey or certificate field of the Server Key		present in the publicKey or certificate field of the Server Key
	Generation Request control or MUST be in the certificate referred to		Generation Request control or MUST be in the certificate referred to
	by the ski in the same control. The client can find the server's		by the ski in the same control. The client can find the server's
	parameters in the server's certificate; to make it easy on clients,		parameters in the server's certificate; to make it easy on clients,
	server certificates MUST include parameters. How the client		server certificates MUST include parameters. How the client obtains
	obtains the server's certificate is out of scope.		the server's certificate is out of scope.
	Servers that support the features specified herein need to document		Servers that support the features specified herein need to document
	their procedures in a CPS (Certificate Practice Statement) [RFC3647].		their procedures in a CPS (Certificate Practice Statement) [RFC3647].
	CAs that certify server-generated private keys are certifying that		CAs that certify server-generated private keys are certifying that
	they've taken due diligence to ensure that the private key is only		they've taken due diligence to ensure that the private key is only
	known to and used by the subject. Depending on the Certification		known to and used by the subject. Depending on the Certification
	Policy [RFC3647], the keys have been allocated to the subject, but		Policy (CP) [RFC3647], the keys have been allocated to the subject,
	the keys may not be strictly owned by the subject. The CA (and the		but the keys may not be strictly owned by the subject. The CA (and
	enterprise it supports) has a reason for issuing the keys (e.g.,		the enterprise it supports) has a reason for issuing the keys (e.g.,
	employer to employee; school to student) and because the enterprise		employer to employee; school to student) and because the enterprise
	CA generated the private keys it is accountable for the		CA generated the private keys it is accountable for the
	trustworthiness of the private key. But, the subject should beware		trustworthiness of the private key. But, the subject should beware of
	using it for other purposes.		using it for other purposes.
	When using an ephemeral key for protecting the server-generated key,		When using an ephemeral key for protecting the server-generated key,
	A compromised signature key, when used by the intended party, will		a compromised signature key, when used by the intended party, will
	not automatically jeopardize the security of the server-generated		not automatically jeopardize the security of the server-generated
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	keys. Procedural controls can help to ensure a one-to-one mapping		keys. Procedural controls can help to ensure a one-to-one mapping
	between verified requests and intended parties (i.e. mitigate the		between verified requests and intended parties (i.e. mitigate the
	risk of masquerade using a compromised authentication key and		risk of masquerade using a compromised authentication key and
	certificate), but that is outside the scope of this document.		certificate), but that is outside the scope of this document.
	POP is important, but for server-generated keys it can only be		POP is important; [RFC4211] provides some information about POP; for
	provided after the server-generated key has been returned by the		server-generated keys it can only be provided after the server-
	client (see Section 8).		generated key has been returned by the client (see Section 8).
			Whether a server requires POP is a CP dependent [RFC3647], but highly
			recommended.
	When the shared secret is used to provide client authentication and		When the shared secret is used to provide client authentication and
	I-D CMC Extensions: Server Key Generation July 30, 2013
	protect the server-generated private key, the shared secret must be		protect the server-generated private key, the shared secret must be
	kept secret for the lifetime of the key. This is because disclosure		kept secret for the lifetime of the key. This is because disclosure
	could allow attackers to determine the server-generated private key.		could allow attackers to determine the server-generated private key.
	This is different than certification requests with client-generated		This is different than certification requests with client-generated
	keys because the shared secret is no longer needed after the		keys because the shared secret is no longer needed after the
	authentication.		authentication.
	If the key generator and the server are not collocated, then the		If the key generator and the server are not collocated, then the
	exchange between these two entities must be protected from		exchange between these two entities must be protected from
	unauthorized disclosure and modification and both entities must have		unauthorized disclosure and modification and both entities must have
	skipping to change at page 35, line 43 ¶		skipping to change at page 38, line 5 ¶
	10. IANA Considerations		10. IANA Considerations
	This document makes use of object identifiers to register CMC control		This document makes use of object identifiers to register CMC control
	attributes and CMC error codes. Additionally, an object identifier		attributes and CMC error codes. Additionally, an object identifier
	is used to identify the ASN.1 module found in Appendix A. All are		is used to identify the ASN.1 module found in Appendix A. All are
	defined in an arc delegated by IANA to the PKIX Working Group. The		defined in an arc delegated by IANA to the PKIX Working Group. The
	current contents of the arc are located here:		current contents of the arc are located here:
	http://www.imc.org/ietf-pkix/pkix-oid.asn		http://www.imc.org/ietf-pkix/pkix-oid.asn
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	They were obtained by sending a request to ietf-pkix-oid-reg@imc.org.		They were obtained by sending a request to ietf-pkix-oid-reg@imc.org.
	When the PKIX WG closes, this arc and registration procedures will		When the PKIX WG closes, this arc and registration procedures will
	be transferred to IANA. No further action by IANA is necessary for		be transferred to IANA. No further action by IANA is necessary for
	this document or any anticipated updates.		this document or any anticipated updates.
	11. References		11. References
	11.1 Normative References		11.1 Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] 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.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification		[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	Request Syntax Specification Version 1.7", RFC 2986,		Request Syntax Specification Version 1.7", RFC 2986,
	November 2000.		November 2000.
	[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure		[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
	Certificate Request Message Format (CRMF)", RFC 4211,		Certificate Request Message Format (CRMF)", RFC 4211,
	September 2005.		September 2005.
	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS		[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
	(CMC)", RFC 5272, June 2008.		(CMC)", RFC 5272, June 2008.
	skipping to change at page 36, line 42 ¶		skipping to change at page 39, line 5 ¶
	[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)		[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
	Updates", RFC 6402, November 2011.		Updates", RFC 6402, November 2011.
	12.2 Informative References		12.2 Informative References
	[FIPS-186] National Institute of Standards and Technology (NIST),		[FIPS-186] National Institute of Standards and Technology (NIST),
	FIPS 186-3 DRAFT: Digital Signature Standard (DSS),		FIPS 186-3 DRAFT: Digital Signature Standard (DSS),
	November 2008.		November 2008.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",		[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
	RFC 2634, June 1999.		RFC 2634, June 1999.
	[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.		[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
	Wu, "Internet X.509 Public Key Infrastructure Certificate		Wu, "Internet X.509 Public Key Infrastructure Certificate
	Policy and Certification Practices Framework", RFC 3647,		Policy and Certification Practices Framework", RFC 3647,
	November 2003.		November 2003.
	[RFC4073] Housley, R., "Protecting Multiple Contents with the		[RFC4073] Housley, R., "Protecting Multiple Contents with the
	Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.		Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	I-D CMC Extensions: Server Key Generation July 30, 2013
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	June 2005.		June 2005.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
	36, RFC 4949, August 2007.		36, RFC 4949, August 2007.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve		[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
	skipping to change at page 37, line 44 ¶		skipping to change at page 40, line 5 ¶
	[SP-800-90] National Institute of Standards and Technology (NIST),		[SP-800-90] National Institute of Standards and Technology (NIST),
	Special Publication 800-90: Recommendation for Random		Special Publication 800-90: Recommendation for Random
	Number Generation Using Deterministic Random Number Bit		Number Generation Using Deterministic Random Number Bit
	Generators (Revised), March 2007.		Generators (Revised), March 2007.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	To be supplied later.		To be supplied later.
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	Appendix B. Additional Message Flows		Appendix B. Additional Message Flows
	This appendix forms a non-normative part of this specification.		This appendix forms a non-normative part of this specification.
	The main body of this document has portrayed protocol flows with		The main body of this document has portrayed protocol flows with
	optional controls. This was done to explain the more complicated		optional controls. This was done to explain the more complicated
	scenarios. This appendix depicts the flows without those optional		scenarios. This appendix depicts the flows without those optional
	controls.		controls.
	For example the figure in Section 2.5.1 without the TransactionId,		For example the figure in Section 2.5.1 without the TransactionId,
	SenderNonce, and RecipientNonce, appear as follows:		SenderNonce, and RecipientNonce, appear as follows:
	I-D CMC Extensions: Server Key Generation July 30, 2013
	Client RA CA		Client RA CA
	| | |		| | |
	|----------------->| |		|----------------->| |
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| Identification] | |		| Identification] | |
	| |-------------------------------------->|		| |-------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | reqSeq:* PKCS #10 or CRMF> |		| | reqSeq:* PKCS #10 or CRMF> |
	| |<--------------------------------------|		| |<--------------------------------------|
	skipping to change at page 38, line 43 ¶		skipping to change at page 41, line 4 ¶
	| control: SKGReq, | |		| control: SKGReq, | |
	| Identification] | |		| Identification] | |
	| |--------------------------------------->|		| |--------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | control: RAIdentityWitness |		| | control: RAIdentityWitness |
	| | cmsSeq: [PKIData |		| | cmsSeq: [PKIData |
	| | control: SKGReq, Identification]> |		| | control: SKGReq, Identification]> |
	| |<---------------------------------------|		| |<---------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | cmsSeq: <PKIResponse		| | cmsSeq: <PKIResponse
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	| | control: SKGRes		| | control: SKGRes
	|<-----------------| cmsSeq: {<AKP>} > >		|<-----------------| cmsSeq: {<AKP>} > >
	| <PKIResponse		| <PKIResponse
	| control: SKGRes		| control: SKGRes
	| cmsSeq: {<AKP>}>		| cmsSeq: {<AKP>}>
	If the RA doesn't perform the Identity checks, then it can forward		If the RA doesn't perform the Identity checks, then it can forward
	the client's request without the additional layers of encapsulation.		the client's request without the additional layers of encapsulation.
	Client RA CA		Client RA CA
	| | |		| | |
	|----------------->| |		|----------------->| |
	I-D CMC Extensions: Server Key Generation July 30, 2013
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| Identification] | |		| Identification] | |
	| |--------------------------------------->|		| |--------------------------------------->|
	| | [PKIData |		| | [PKIData |
	| | control: SKGReq, Identification] |		| | control: SKGReq, Identification] |
	| |<---------------------------------------|		| |<---------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: SKGRes		| | control: SKGRes
	| | cmsSeq: {<AKP>}>		| | cmsSeq: {<AKP>}>
	skipping to change at page 39, line 43 ¶		skipping to change at page 42, line 4 ¶
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| Identification] | |		| Identification] | |
	| |-------------------------------------->|		| |-------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | cmsSeq (1-n):* PKCS #10 or CRMF> |		| | cmsSeq (1-n):* PKCS #10 or CRMF> |
	| |<--------------------------------------|		| |<--------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: BatchResponse		| | control: BatchResponse
	|<-----------------| cmsSeq (1-n): certs-only>		|<-----------------| cmsSeq (1-n): certs-only>
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	| <PKIResponse(1-n)		| <PKIResponse(1-n)
	| control: SKGRes		| control: SKGRes
	| cmsSeq: {<AKP>}>		| cmsSeq: {<AKP>}>
	* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.		* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.
	In another scenario, all but one of the requests were successfully		In another scenario, all but one of the requests were successfully
	processed. The RA returns those that were successful back to the		processed. The RA returns those that were successful back to the
	clients but later polls the CA, based on the value CMCStatusInfoV2		clients but later polls the CA, based on the value CMCStatusInfoV2
	pendInfo, for the one that was not successful. The CA returns the		pendInfo, for the one that was not successful. The CA returns the
	one successful request.		one successful request.
	I-D CMC Extensions: Server Key Generation July 30, 2013
	Client(1-n) RA CA		Client(1-n) RA CA
	| | |		| | |
	|----------------->| |		|----------------->| |
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| Identification] | |		| Identification] | |
	| |-------------------------------------->|		| |-------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | control: BatchRequest |		| | control: BatchRequest |
	| | cmsSeq (1-n):* PKCS #10 or CRMF> |		| | cmsSeq (1-n):* PKCS #10 or CRMF> |
	skipping to change at page 40, line 43 ¶		skipping to change at page 43, line 4 ¶
	| control: SKGRes		| control: SKGRes
	| cmsSeq: {<AKP>}>		| cmsSeq: {<AKP>}>
	* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.		* Includes ChangeSubjectName attribute in PKCS #10 or CRMF.
	Batching the requests can also be performed for CA-generated keys as		Batching the requests can also be performed for CA-generated keys as
	shown below. The RA Identity Witness controls indicates all those		shown below. The RA Identity Witness controls indicates all those
	client requests that it performed Identity checks on.		client requests that it performed Identity checks on.
	Client RA CA		Client RA CA
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	| | |		| | |
	|----------------->| |		|----------------->| |
	| [PKIData | |		| [PKIData | |
	| control: SKGReq, | |		| control: SKGReq, | |
	| TransactionID, | |		| TransactionID, | |
	| SenderNonce, | |		| SenderNonce, | |
	| Identification] | |		| Identification] | |
	| |--------------------------------------->|		| |--------------------------------------->|
	| | <PKIData |		| | <PKIData |
	| | control: TransactionId, SenderNonce, |		| | control: TransactionId, SenderNonce, |
	| | RAIdentityWitness, BatchRequest |		| | RAIdentityWitness, BatchRequest |
	| | cmsSeq (1-n): [PKIData |		| | cmsSeq (1-n): [PKIData |
	I-D CMC Extensions: Server Key Generation July 30, 2013
	| | control: SKGReq, TransactionID, |		| | control: SKGReq, TransactionID, |
	| | SenderNonce, Identification]>|		| | SenderNonce, Identification]>|
	| |<---------------------------------------|		| |<---------------------------------------|
	| | <PKIResponse		| | <PKIResponse
	| | control: TransactionId, SenderNonce,		| | control: TransactionId, SenderNonce,
	| | RecipientNonce, BatchResponse		| | RecipientNonce, BatchResponse
	| | cmsSeq (1-n): <PKIResponse		| | cmsSeq (1-n): <PKIResponse
	| | control: TransactionID, SenderNonce,		| | control: TransactionID, SenderNonce,
	| | RecipientNonce, SKGRes		| | RecipientNonce, SKGRes
	|<-----------------| cmsSeq: {<AKP>} >>		|<-----------------| cmsSeq: {<AKP>} >>
	skipping to change at page 41, line 36 ¶		skipping to change at page 44, line 4 ¶
	B.1.1. Shroud with Certificate		B.1.1. Shroud with Certificate
	B.1.2. Shroud with Public Key		B.1.2. Shroud with Public Key
	B.1.3. Shroud with Shared Secret		B.1.3. Shroud with Shared Secret
	B.2. CA-Generate Key Response		B.2. CA-Generate Key Response
	B.3. RA-Generate Key Response		B.3. RA-Generate Key Response
			I-D CMC Extensions: Server Side Key Generation March 27, 2014
	Authors' Addresses		Authors' Addresses
	Jim Schaad		Jim Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	Email: jimsch@exmsft.com		Email: jimsch@exmsft.com
	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
	I-D CMC Extensions: Server Key Generation July 30, 2013
	Paul Timmel		Paul Timmel
	National Information Assurance Research Laboratory		National Information Assurance Research Laboratory
	National Security Agency		National Security Agency
	Email: pstimme@tycho.ncsc.mil		Email: pstimme@tycho.ncsc.mil
End of changes. 176 change blocks.
	487 lines changed or deleted		614 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/