< draft-turner-sodp-00.txt		draft-turner-sodp-01.txt >
	Network Working Group S. Turner		Network Working Group S. Turner
	Internet-Draft IECA		Internet-Draft IECA
	Intended status: Standards Track March 7, 2011		Intended status: Standards Track September 1, 2011
	Expires: September 6, 2011		Expires: March 4, 2012
	Secure Object Delivery Protocol (SODP)		Secure Object Delivery Protocol (SODP)
	draft-turner-sodp-00.txt		draft-turner-sodp-01.txt
	Abstract		Abstract
	This document describes the Secure Object Delivery Protocol (SODP).		This document describes the Secure Object Delivery Protocol (SODP).
	SODP enables clients to access secure packages produced by a Key		SODP enables clients to access secure packages produced by a Key
	Management Systems (KMS). Client access is ideally direct and web-		Management Systems (KMS). Client access is ideally direct and web-
	based, but access via agents acting on behalf of clients is		based, but access via agents acting on behalf of clients is
	supported.		supported.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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."
	This Internet-Draft will expire on September 6, 2011.		This Internet-Draft will expire on March 4, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	Internet-Draft SODP 2011-03-07
	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 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. SODP Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. SODP Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Key Management System . . . . . . . . . . . . . . . . . . . . . 8		3. Key Management System . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32		10.1. Package Protection . . . . . . . . . . . . . . . . . . . 32
	10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . 33		10.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . 33
	10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33		10.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 33
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 33		11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . 34		12.1. SODP Name Space . . . . . . . . . . . . . . . . . . . . 34
	12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . 35		12.2. SODP Schema . . . . . . . . . . . . . . . . . . . . . . 35
	12.3. SODP Message Types . . . . . . . . . . . . . . . . . . . 36		12.3. SODP Message Types . . . . . . . . . . . . . . . . . . . 36
	12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . 38		12.4. SODP Path 1 String Values . . . . . . . . . . . . . . . 38
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
	Internet-Draft SODP 2011-03-07
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	14.1. Normative References . . . . . . . . . . . . . . . . . . 38		14.1. Normative References . . . . . . . . . . . . . . . . . . 38
	14.2. Informative References . . . . . . . . . . . . . . . . . 40		14.2. Informative References . . . . . . . . . . . . . . . . . 40
	Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 42		Appendix A. Example Encodings . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	The Secure Object Delivery Protocol (SODP) enables clients to obtain		The Secure Object Delivery Protocol (SODP) enables clients to obtain
	secured packages from a supporting Key Management System (KMS).		secured packages from a supporting Key Management System (KMS).
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	Encrypted Key Package: A package that includes an encrypted key		Encrypted Key Package: A package that includes an encrypted key
	content type [RFC6032].		content type [RFC6032].
	Firmware Package: A package that contains a firmware content type		Firmware Package: A package that contains a firmware content type
	[RFC4108][RFC5911].		[RFC4108][RFC5911].
	NOTE: [RFC4108] defines the semantics for the firmware content		NOTE: [RFC4108] defines the semantics for the firmware content
	type's fields. [RFC5911] provides the 2002 ASN.1 definitions.		type's fields. [RFC5911] provides the 2002 ASN.1 definitions.
	Identity and Authentication (IA) Key/Certificate: Key/Certificate		Identity and Authentication (IA) Key/Certificate: Key/Certificate
	Internet-Draft SODP 2011-03-07
	used to support IA of the client, when the client communicates with		used to support IA of the client, when the client communicates with
	the KMS as well as with other end-entities. It provides the KMS or		the KMS as well as with other end-entities. It provides the KMS or
	other end-entities with an appropriate degree of confidence in the		other end-entities with an appropriate degree of confidence in the
	client's identity before delivering products, services or sensitive		client's identity before delivering products, services or sensitive
	information to the client.		information to the client.
	Key Exchange (KE) Key/Certificate: Key/Certificate used when the		Key Exchange (KE) Key/Certificate: Key/Certificate used when the
	client and the KMS or other end-entity must cooperatively create a		client and the KMS or other end-entity must cooperatively create a
	wrapping key to protect the delivery of products or sensitive		wrapping key to protect the delivery of products or sensitive
	information for use by the client. It is also used to establish		information for use by the client. It is also used to establish
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	KMS services. This document defines three services that manifest in		KMS services. This document defines three services that manifest in
	three types of service messages: publication, distribution, and		three types of service messages: publication, distribution, and
	certificate management. One, registration, does not manifest itself		certificate management. One, registration, does not manifest itself
	in a service message.		in a service message.
	Source Authority: A source authority is trusted by clients to		Source Authority: A source authority is trusted by clients to
	generate particular package types. Clients determine this by		generate particular package types. Clients determine this by
	validating the digital signature on the package back to a Trust		validating the digital signature on the package back to a Trust
	Anchor (TA).		Anchor (TA).
	Internet-Draft SODP 2011-03-07
	Sponsor: A person that is accountable for use of the client's		Sponsor: A person that is accountable for use of the client's
	identity. This may or may not be the entity that operates the client		identity. This may or may not be the entity that operates the client
	(i.e., the operator).		(i.e., the operator).
	Symmetric Key Package: A package that contains a symmetric key		Symmetric Key Package: A package that contains a symmetric key
	content type [RFC6031].		content type [RFC6031].
	Trust Anchor (TA): From [RFC5934], a TA contains a public key that is		Trust Anchor (TA): From [RFC5934], a TA contains a public key that is
	used to validate digital signatures. In this document, a TA		used to validate digital signatures. In this document, a TA
	represents an authoritative entity via a public key and associated		represents an authoritative entity via a public key and associated
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	the key management system, one or more clients, and agents acting on		the key management system, one or more clients, and agents acting on
	behalf of clients. KMS-to-client and KMS-to-agent protocol		behalf of clients. KMS-to-client and KMS-to-agent protocol
	interactions are in-scope; agent-to-client protocol interactions are		interactions are in-scope; agent-to-client protocol interactions are
	out-of-scope. KMS-to-client and KMS-to-agent interactions support		out-of-scope. KMS-to-client and KMS-to-agent interactions support
	mutual authentication, provide integrity, and optionally provide		mutual authentication, provide integrity, and optionally provide
	confidentiality through the use of HTTPS. Confidentiality for KMS-		confidentiality through the use of HTTPS. Confidentiality for KMS-
	to-client and KMS-to-agent interactions is OPTIONAL because when		to-client and KMS-to-agent interactions is OPTIONAL because when
	confidentiality is needed the packages are encrypted for the client.		confidentiality is needed the packages are encrypted for the client.
	See Section 10 for requirements on cryptographic suites.		See Section 10 for requirements on cryptographic suites.
	Internet-Draft SODP 2011-03-07
	<===> IP-Based Protocol Profile (in scope)		<===> IP-Based Protocol Profile (in scope)
	<- -> ECU-Specified Access Protocol (out of scope)		<- -> ECU-Specified Access Protocol (out of scope)
	///// CMS-Protected Packages (in scope; full support)		///// CMS-Protected Packages (in scope; full support)
	\\\\\ CMS-Protected Packages (in scope; partial support;		\\\\\ CMS-Protected Packages (in scope; partial support;
	requires validation of outer signature only)		requires validation of outer signature only)
	+----------------+		+----------------+
	| | +------------+		| | +------------+
	| Key | | Client A |		| Key | | Client A |
	| Management | | +---+ |		| Management | | +---+ |
	| System |<=====>| /// |ECU| |		| System |<=====>| /// |ECU| |
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 4 ¶
	Identifiers (URIs) for client packages. Retrieval of packages		Identifiers (URIs) for client packages. Retrieval of packages
	referenced in the PAL delivers KMS services to the client.		referenced in the PAL delivers KMS services to the client.
	Alternatively, clients can retrieve packages directly from the KMS if		Alternatively, clients can retrieve packages directly from the KMS if
	they obtain URIs from another source. KMS services are discussed in		they obtain URIs from another source. KMS services are discussed in
	Section 2.1; the PAL and URI format are discussed in Section 5.		Section 2.1; the PAL and URI format are discussed in Section 5.
	While the KMS is viewed as being a single entity, operationally the		While the KMS is viewed as being a single entity, operationally the
	issuance of different packages can be assigned to different		issuance of different packages can be assigned to different
	authorities within the KMS. These authorities are referred to as		authorities within the KMS. These authorities are referred to as
	source authorities. A source authority is trusted by clients to		source authorities. A source authority is trusted by clients to
	Internet-Draft SODP 2011-03-07
	generate particular package types. Entities validate their source		generate particular package types. Entities validate their source
	authorities when validating the digital signature(s) in/on packages.		authorities when validating the digital signature(s) in/on packages.
	That is, when a client retrieves a package referred to in their PAL		That is, when a client retrieves a package referred to in their PAL
	the client ensures that the signatures in/on the package validate to		the client ensures that the signatures in/on the package validate to
	an installed trust anchor (TA). See Section 4.1 for more information		an installed trust anchor (TA). See Section 4.1 for more information
	on clients' TAs.		on clients' TAs.
	Packages may be encrypted for the client. Packages that contain		Packages may be encrypted for the client. Packages that contain
	cleartext (i.e., unencrypted) symmetric keys or asymmetric private		cleartext (i.e., unencrypted) symmetric keys or asymmetric private
	keys MUST be encrypted for the client to ensure that the keys are not		keys MUST be encrypted for the client to ensure that the keys are not
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 4 ¶
	client interactions, which is the client's joie de vivre or the		client interactions, which is the client's joie de vivre or the
	client's mission. The initial certificate set is only used to		client's mission. The initial certificate set is only used to
	communicate with the KMS and the second set is only ever used to		communicate with the KMS and the second set is only ever used to
	communicate with other clients. In this case the first set is		communicate with other clients. In this case the first set is
	referred to as IA(I)/KE(I) certificates for (I)nfrastructure		referred to as IA(I)/KE(I) certificates for (I)nfrastructure
	certificates and the second set is referred to as IA(M)/KE(M)		certificates and the second set is referred to as IA(M)/KE(M)
	certificates for (M)ission certificates. Not all clients need the		certificates for (M)ission certificates. Not all clients need the
	second set of certificate, if clients only need symmetric key, then		second set of certificate, if clients only need symmetric key, then
	only one set of certificates is issued. *(I) certificates are issued		only one set of certificates is issued. *(I) certificates are issued
	to it and instead of IA(M)/KE(M) certificates issued later only		to it and instead of IA(M)/KE(M) certificates issued later only
	Internet-Draft SODP 2011-03-07
	symmetric key packages are provided.		symmetric key packages are provided.
	3. Key Management System		3. Key Management System
	The SODP is the interface to the KMS that clients use to access KMS-		The SODP is the interface to the KMS that clients use to access KMS-
	services and associated KMS-generated packages. The internal		services and associated KMS-generated packages. The internal
	components of the KMS and their interactions are out-of-scope.		components of the KMS and their interactions are out-of-scope.
	However, if a KMS provides all of the KMS packages (see Section 3.2),		However, if a KMS provides all of the KMS packages (see Section 3.2),
	it will need the capability to package trust anchors (TAs), generate		it will need the capability to package trust anchors (TAs), generate
	and package symmetric keys, package firmware, generate and package		and package symmetric keys, package firmware, generate and package
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 4 ¶
	o Client Manufacturer		o Client Manufacturer
	o Client Name		o Client Name
	o Client Type		o Client Type
	The KMS could also assign a KMS user number for an internal index,		The KMS could also assign a KMS user number for an internal index,
	label, or abbreviated name for associating data elements pertaining		label, or abbreviated name for associating data elements pertaining
	to that user. This number is not sent to the client and is only used		to that user. This number is not sent to the client and is only used
	by the KMS.		by the KMS.
	During this step the client is also assigned an identity, which the		During this step the client is also assigned an identity, which the
	Internet-Draft SODP 2011-03-07
	KMS stores in its database. At a minimum the identity is an		KMS stores in its database. At a minimum the identity is an
	identifier but it can also include additional information such as a		identifier but it can also include additional information such as a
	client's sponsor (e.g., Alexa Morris), the client's operator (e.g.,		client's sponsor (e.g., Alexa Morris), the client's operator (e.g.,
	Alexa Morris), and the sponsor's organizational affiliation (e.g.,		Alexa Morris), and the sponsor's organizational affiliation (e.g.,
	AMS). That is, the KMS MUST assign and record an identifier to the		AMS). That is, the KMS MUST assign and record an identifier to the
	client, but recording other client-related identity data is OPTIONAL.		client, but recording other client-related identity data is OPTIONAL.
	Additionally:		Additionally:
	o For cases where the sponsor isn't the entity that operates the		o For cases where the sponsor isn't the entity that operates the
	client, the identity can also include an indication of the entity		client, the identity can also include an indication of the entity
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	match another client served by the KMS. After this check passes, the		match another client served by the KMS. After this check passes, the
	final step in the registration process occurs: client IA certificate		final step in the registration process occurs: client IA certificate
	issuance. The KMS MUST issue a certificate [RFC5280] to the client		issuance. The KMS MUST issue a certificate [RFC5280] to the client
	that contains the client's permanent identifier (see Section 6).		that contains the client's permanent identifier (see Section 6).
	NOTE: 1) The process for delivering the IA certificate directly to		NOTE: 1) The process for delivering the IA certificate directly to
	the client is out-of-scope; 2) the format and protocol for		the client is out-of-scope; 2) the format and protocol for
	communicating the registration data is out-of-scope; and 3) the		communicating the registration data is out-of-scope; and 3) the
	client need not contribute to or respond to the supplied identity		client need not contribute to or respond to the supplied identity
	information.		information.
	Internet-Draft SODP 2011-03-07
	3.1.2. Distribution Service		3.1.2. Distribution Service
	The KMS employs the distribution service to provide clients' access		The KMS employs the distribution service to provide clients' access
	to their packages. The KMS provides access to packages through the		to their packages. The KMS provides access to packages through the
	use of URIs, which uniquely refers to specifically CMS-wrapped		use of URIs, which uniquely refers to specifically CMS-wrapped
	packages for delivery to the target client. The KMS generates a PAL		packages for delivery to the target client. The KMS generates a PAL
	that clients can use to retrieve packages. Alternatively, the client		that clients can use to retrieve packages. Alternatively, the client
	can directly access the package, but this assumes the client obtained		can directly access the package, but this assumes the client obtained
	the URI(s) via another mechanism, which is out-of-scope. Packages		the URI(s) via another mechanism, which is out-of-scope. Packages
	include symmetric key packages as well as centrally-generated		include symmetric key packages as well as centrally-generated
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 26 ¶
	NOTE: Certificates associated with client generated asymmetric		NOTE: Certificates associated with client generated asymmetric
	keys (i.e., locally-generated public-private keys) are delivered		keys (i.e., locally-generated public-private keys) are delivered
	via the Certificate Management Service (See Section 3.1.3).		via the Certificate Management Service (See Section 3.1.3).
	Figure 2 depicts an example ladder diagram for a protocol flow. The		Figure 2 depicts an example ladder diagram for a protocol flow. The
	first step is to establish a mutually authenticated HTTPS connection		first step is to establish a mutually authenticated HTTPS connection
	between the client/agent and KMS. The client then requests their PAL		between the client/agent and KMS. The client then requests their PAL
	from the KMS (via HTTP GET). The KMS replies with the client's PAL		from the KMS (via HTTP GET). The KMS replies with the client's PAL
	(via HTTP GET Response). Once a client has successfully downloaded		(via HTTP GET Response). Once a client has successfully downloaded
	their PAL, it will process it to obtain the included packages(s).		their PAL, it will process it to obtain the included packages(s). The
	The processing provided will depend on the PAL entry. Section 3.2		processing provided will depend on the PAL entry. Section 3.2
	details the KMS-package requirements, Section 4 details clients-		details the KMS-package requirements, Section 4 details clients-
	package requirements, and Section 5 details agent-package		package requirements, and Section 5 details agent-package
	requirements.		requirements.
	Internet-Draft SODP 2011-03-07
	| |		| |
	KMS | Establish HTTPS | Client or Agent		KMS | Establish HTTPS | Client or Agent
	| Connection |		| Connection |
	|<-------------------->|		|<-------------------->|
	| |		| |
	| Request PAL |		| Request PAL |
	| (HTTP GET) |		| (HTTP GET) |
	|<---------------------|		|<---------------------|
	|--------------------->|		|--------------------->|
	| Deliver PAL with URI |		| Deliver PAL with URI |
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	Certificate Policies (CPs), and Certificate Practice Statements		Certificate Policies (CPs), and Certificate Practice Statements
	(CPSs) packages. The KMS MUST support distribution of CRLs but MAY		(CPSs) packages. The KMS MUST support distribution of CRLs but MAY
	support distribution of CPs and CPSs.		support distribution of CPs and CPSs.
	NOTE: CPs and CPSs are the one exception to the Package		NOTE: CPs and CPSs are the one exception to the Package
	definition found in section 1.1. CPs and CPSs are not		definition found in section 1.1. CPs and CPSs are not
	encapsulated in CMS, they are URIs to the location on the KMS for		encapsulated in CMS, they are URIs to the location on the KMS for
	the CP and CPS.		the CP and CPS.
	Certificates delivered can include additional CA certificates or peer		Certificates delivered can include additional CA certificates or peer
	Internet-Draft SODP 2011-03-07
	client certificate(s).		client certificate(s).
	Clients may elect to obtain the CRLs that they rely on from sources		Clients may elect to obtain the CRLs that they rely on from sources
	other than the (e.g., a local directory).		other than the (e.g., a local directory).
	CRLs are offered in the form, or forms, produced by the responsible		CRLs are offered in the form, or forms, produced by the responsible
	Certification Authority (CA). The form of the CRL is transparent to		Certification Authority (CA). The form of the CRL is transparent to
	the KMS Publication Service. CAs may choose to publish compact		the KMS Publication Service. CAs may choose to publish compact
	versions of CRLs (e.g., partitioned CRLs) that are compatible with a		versions of CRLs (e.g., partitioned CRLs) that are compatible with a
	disadvantaged client within the overall subscriber population. The		disadvantaged client within the overall subscriber population. The
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	a KE certificate.		a KE certificate.
	o Rekey: Where an existing IA certificate is provided with new		o Rekey: Where an existing IA certificate is provided with new
	keying material.		keying material.
	CA MUST generate public key certificates in accordance with		CA MUST generate public key certificates in accordance with
	[RFC5280]. A Registration Authority (RA) may be used to register		[RFC5280]. A Registration Authority (RA) may be used to register
	subscribers as well as assist the CA when issuing and rekeying		subscribers as well as assist the CA when issuing and rekeying
	certificates for clients.		certificates for clients.
	Internet-Draft SODP 2011-03-07
	3.2. KMS Packages		3.2. KMS Packages
	The KMS Distribution, Publication, and Certificate Management		The KMS Distribution, Publication, and Certificate Management
	services translate into KMS packages. The primary packages are key		services translate into KMS packages. The primary packages are key
	packages, but they also include firmware packages necessary to use		packages, but they also include firmware packages necessary to use
	the key packages, TAMP packages to validate the package's source of		the key packages, TAMP packages to validate the package's source of
	authority, publication packages that contain additional certificates		authority, publication packages that contain additional certificates
	and CRLs, and collections of key packages. This section lists the		and CRLs, and collections of key packages. This section lists the
	package requirements for the KMS.		package requirements for the KMS.
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 4 ¶
	package [RFC6032] supports encrypting key packages in one of three		package [RFC6032] supports encrypting key packages in one of three
	ways: with key exchange algorithms (i.e., using EnvelopedData), with		ways: with key exchange algorithms (i.e., using EnvelopedData), with
	previously distributed symmetric algorithms (i.e., using		previously distributed symmetric algorithms (i.e., using
	EncryptedData), and with authenticated-encryption algorithms (i.e.,		EncryptedData), and with authenticated-encryption algorithms (i.e.,
	using AuthEnvelopedData). The KMS MUST support the ct-encrypted-key-		using AuthEnvelopedData). The KMS MUST support the ct-encrypted-key-
	package content type and the EnvelopedData choice (i.e., support ct-		package content type and the EnvelopedData choice (i.e., support ct-
	enveloped-data). The KMS MUST support encapsulating ct-encrypted-		enveloped-data). The KMS MUST support encapsulating ct-encrypted-
	key-package in a ct-signed-data content type.		key-package in a ct-signed-data content type.
	The KMS distributes object code for implementing one or more		The KMS distributes object code for implementing one or more
	Internet-Draft SODP 2011-03-07
	cryptographic algorithms in a cryptographic module and software to		cryptographic algorithms in a cryptographic module and software to
	implement a communications protocol with the Firmware package		implement a communications protocol with the Firmware package
	[RFC4108][RFC5911]. The KMS MUST support the ct-firmwarePacakge		[RFC4108][RFC5911]. The KMS MUST support the ct-firmwarePacakge
	content type. It MUST support receipt of the ct-firmwareLoadReceipt		content type. It MUST support receipt of the ct-firmwareLoadReceipt
	and ct-firmwareLoadError content types. The KMS MUST support		and ct-firmwareLoadError content types. The KMS MUST support
	encapsulating the ct-firmwarePackage content type in a ct-signed-data		encapsulating the ct-firmwarePackage content type in a ct-signed-data
	content type.		content type.
	To support sending multiple package types to a client, the KMS can		To support sending multiple package types to a client, the KMS can
	use the Content Collection [RFC4073] CMS content type. To allow the		use the Content Collection [RFC4073] CMS content type. To allow the
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	Section 3.1.1 addresses client registration. As noted there, the		Section 3.1.1 addresses client registration. As noted there, the
	client need not contribute to or respond to the supplied identity		client need not contribute to or respond to the supplied identity
	information. After registration is completed, the client is supplied		information. After registration is completed, the client is supplied
	with an IA certificate. Prior to using this certificate, the client		with an IA certificate. Prior to using this certificate, the client
	MUST verify that the certificate back to an installed trust anchor.		MUST verify that the certificate back to an installed trust anchor.
	The number of TAs is implementation KMS-specific, but in general:		The number of TAs is implementation KMS-specific, but in general:
	o If the client supports locally-generated asymmetric keys, then it		o If the client supports locally-generated asymmetric keys, then it
	MUST support at least one TA.		MUST support at least one TA.
	Internet-Draft SODP 2011-03-07
	o If the client support centrally-generated asymmetric keys, then		o If the client support centrally-generated asymmetric keys, then
	it MUST also support at least one TA.		it MUST also support at least one TA.
	o If the client supports symmetric keys, then it MUST support two		o If the client supports symmetric keys, then it MUST support two
	TAs: one for symmetric keys and one for the asymmetric keys		TAs: one for symmetric keys and one for the asymmetric keys
	(i.e., the PKI Root).		(i.e., the PKI Root).
	o If the client support firmware, the it MUST support two TAs: one		o If the client support firmware, the it MUST support two TAs: one
	for the firmware and one for the asymmetric keys (i.e., the PKI		for the firmware and one for the asymmetric keys (i.e., the PKI
	Root).		Root).
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	Distribution Authority (KDA). The KSA creates the asymmetric key		Distribution Authority (KDA). The KSA creates the asymmetric key
	places it in the symmetric key content type, signs it (signed data		places it in the symmetric key content type, signs it (signed data
	content type), includes the corresponding certificate, and encrypts		content type), includes the corresponding certificate, and encrypts
	it (encrypted key content type). The KDA applies an additional		it (encrypted key content type). The KDA applies an additional
	signature layer around the encrypted data. Upon receipt the client		signature layer around the encrypted data. Upon receipt the client
	validates KDA's certificate and signature to the KTA, decrypt the		validates KDA's certificate and signature to the KTA, decrypt the
	message, the KSA's signature and certificates to the KTA, the client		message, the KSA's signature and certificates to the KTA, the client
	validates their certificate to the PKI TA, and the client checks that		validates their certificate to the PKI TA, and the client checks that
	the private key corresponds to the public key.		the private key corresponds to the public key.
	Internet-Draft SODP 2011-03-07
	+-----+ +--------+		+-----+ +--------+
	| KTA | | PKI TA |		| KTA | | PKI TA |
	+-----+ +--------+		+-----+ +--------+
	| |		| |
	| Signs | Signs		| Signs | Signs
	| |		| |
	+-------------+ V		+-------------+ V
	| | +----+		| | +----+
	V V | CA |		V V | CA |
	+-----+ +-----+ +----+		+-----+ +-----+ +----+
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 4 ¶
	it can occur at a later time.		it can occur at a later time.
	NOTE: A client only needs to be loaded with an IA key to perform		NOTE: A client only needs to be loaded with an IA key to perform
	KMS Services.		KMS Services.
	If the client needs additional certificates (e.g., for		If the client needs additional certificates (e.g., for
	confidentiality or separate mission certificates), the client or		confidentiality or separate mission certificates), the client or
	agent can retrieve them via the PAL. Client retrieval of packages		agent can retrieve them via the PAL. Client retrieval of packages
	via the PAL is OPTIONAL. Clients may elect to obtain product package		via the PAL is OPTIONAL. Clients may elect to obtain product package
	URI information using a different mechanism (e.g., inputs from a		URI information using a different mechanism (e.g., inputs from a
	Internet-Draft SODP 2011-03-07
	human or agent).		human or agent).
	4.3. Packages		4.3. Packages
	Client support for packages varies depending on the type of service		Client support for packages varies depending on the type of service
	they desire. All clients MUST support the ct-signed-data content		they desire. All clients MUST support the ct-signed-data content
	type to ensure the packages source of authority can be determined.		type to ensure the packages source of authority can be determined.
	They MUST also support validating package signatures back to a TA		They MUST also support validating package signatures back to a TA
	[RFC5652][RFC5280].		[RFC5652][RFC5280].
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	For clients that support certificate management packages with		For clients that support certificate management packages with
	centrally-generated keys, they MUST support ct-asymmetric-key-package		centrally-generated keys, they MUST support ct-asymmetric-key-package
	[RFC5958], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse		[RFC5958], ct-PKIData [RFC5272][RFC5912], and ct-PKIResponse
	[RFC5272][RFC5912].		[RFC5272][RFC5912].
	5. Agents		5. Agents
	Agents act on behalf of the client. Agents MUST support PAL		Agents act on behalf of the client. Agents MUST support PAL
	processing.		processing.
	Internet-Draft SODP 2011-03-07
	TO DO: Fill this out.		TO DO: Fill this out.
	6. Electronic Serial Number		6. Electronic Serial Number
	The Electronic Serial Number (ESN) is a permanent identifier that is		The Electronic Serial Number (ESN) is a permanent identifier that is
	used to identify the client throughout its lifecycle. Certificates		used to identify the client throughout its lifecycle. Certificates
	include the ESN with the Hardware Module Name from [RFC4108] in the		include the ESN with the Hardware Module Name from [RFC4108] in the
	Subject Alternative Name extension [RFC5280]. The hardware module		Subject Alternative Name extension [RFC5280]. The hardware module
	name form is an hwType (an object identifier) and hwSerialNumber		name form is an hwType (an object identifier) and hwSerialNumber
	(octet string). The combination of the object identifier and octet		(octet string). The combination of the object identifier and octet
	skipping to change at page 19, line 4 ¶		skipping to change at page 19, line 4 ¶
	<message>		<message>
	<type>100</type>		<type>100</type>
	<date>00000000000000</date>		<date>00000000000000</date>
	<size>0</size>		<size>0</size>
	<info>DN of subject</info>		<info>DN of subject</info>
	</message>		</message>
	<message>		<message>
	<type>TBD</type>		<type>TBD</type>
	<date>00000000000000</date>		<date>00000000000000</date>
	<size>2390</size>		<size>2390</size>
	Internet-Draft SODP 2011-03-07
	<info>https://www.example.com/distribution/100</info>		<info>https://www.example.com/distribution/100</info>
	</message>		</message>
	<message>		<message>
	<type>1</type>		<type>1</type>
	<date>00000000000000</date>		<date>00000000000000</date>
	<size>0</size>		<size>0</size>
	<info>https://www.example.com/distribution/12345</info>		<info>https://www.example.com/distribution/12345</info>
	</message>		</message>
	</pal>		</pal>
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 5 ¶
	o Certificate: Anywhere from 0 to a maximum of j candidate entries		o Certificate: Anywhere from 0 to a maximum of j candidate entries
	(i.e., pending certificate management transactions or certificate		(i.e., pending certificate management transactions or certificate
	notifications) where j <= the maximum number of certificates the		notifications) where j <= the maximum number of certificates the
	device can have.		device can have.
	o Distribution: Anywhere from zero (0) to a maximum of q packages		o Distribution: Anywhere from zero (0) to a maximum of q packages
	where q is less than or equal to the total number of		where q is less than or equal to the total number of
	independently-deliverable keys, and bundled packages the client		independently-deliverable keys, and bundled packages the client
	is designed to accept.		is designed to accept.
	Internet-Draft SODP 2011-03-07
	An order of precedence for PAL offerings is based on the following		An order of precedence for PAL offerings is based on the following
	rationale:		rationale:
	o Publication packages are the most important because they support		o Publication packages are the most important because they support
	validation decisions on certificates used to sign and encrypt		validation decisions on certificates used to sign and encrypt
	other listed PAL items.		other listed PAL items.
	o Certificate Management packages items are next in importance,		o Certificate Management packages items are next in importance,
	since they can impact an IA certificate used by the device to		since they can impact an IA certificate used by the device to
	sign CMS content or a KE certificate to establish keys for		sign CMS content or a KE certificate to establish keys for
	encrypting content exchanged with the client.		encrypting content exchanged with the client.
	* A client engaged in a certificate management should accept and		* A client engaged in a certificate management should accept and
	process CA-provided transactions as soon as possible to avoid		process CA-provided transactions as soon as possible to avoid
	undue delays that might lead to protocol failure.		undue delays that might lead to protocol failure.
	o Distribution packages containing keys and other types of products		o Distribution packages containing keys and other types of products
	are last. Precedence SHOULD be given to KMS packages that the		are last. Precedence SHOULD be given to KMS packages that the
	client has not previously downloaded. The items listed in a PAL		client has not previously downloaded. The items listed in a PAL
	may not identify all of the packages available for a device.		may not identify all of the packages available for a device. This
	This can be for any of the following reasons:		can be for any of the following reasons:
	o The KMS may temporarily withhold some outstanding PAL items to		o The KMS may temporarily withhold some outstanding PAL items to
	simplify client processing.		simplify client processing.
	* Certificate Management PAL entries linked to a near-real-time		* Certificate Management PAL entries linked to a near-real-time
	CA device protocol (i.e., not staged through intermediary media		CA device protocol (i.e., not staged through intermediary media
	devices or store and forward communication systems that may		devices or store and forward communication systems that may
	significantly delay interactions) will be limited to one-at-a-		significantly delay interactions) will be limited to one-at-a-
	time.		time.
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 4 ¶
	certificate, before beginning the process for another. At most		certificate, before beginning the process for another. At most
	one pending certificate management transaction will be		one pending certificate management transaction will be
	advertised in the PAL at a time.		advertised in the PAL at a time.
	o A PAL is limited to a maximum of thirty-two entries. If more		o A PAL is limited to a maximum of thirty-two entries. If more
	than thirty-two entries are available for the client, additional		than thirty-two entries are available for the client, additional
	PALs will be identified in the last entry of the PAL. The first		PALs will be identified in the last entry of the PAL. The first
	PAL in the chain is identified as the Initial PAL.		PAL in the chain is identified as the Initial PAL.
	o Packages will be removed when their contents are superseded or at		o Packages will be removed when their contents are superseded or at
	Internet-Draft SODP 2011-03-07
	the direction of a KMS Manager.		the direction of a KMS Manager.
	The remainder of this section describes the PAL format and its use of		The remainder of this section describes the PAL format and its use of
	URIs.		URIs.
	7.1. PAL Format		7.1. PAL Format
	The PAL furnishes information for KMS messages that are currently		The PAL furnishes information for KMS messages that are currently
	available and authorized for retrieval by a client or an agent. The		available and authorized for retrieval by a client or an agent. The
	PAL is used to identify the following information:		PAL is used to identify the following information:
	skipping to change at page 22, line 4 ¶		skipping to change at page 22, line 4 ¶
	o The Last Download Date subcomponent is provided for each PAL		o The Last Download Date subcomponent is provided for each PAL
	entry. It is a 14-character field that contains either:		entry. It is a 14-character field that contains either:
	o The date and time (expressed as Generalized Time) that the client		o The date and time (expressed as Generalized Time) that the client
	last successfully downloaded the identified package from the KMS,		last successfully downloaded the identified package from the KMS,
	or		or
	o All zeroes characters, if:		o All zeroes characters, if:
	* There is no indication the device has successfully loaded the		* There is no indication the device has successfully loaded the
	Internet-Draft SODP 2011-03-07
	identified KMS package,		identified KMS package,
	o The PAL entry is a notification, or		o The PAL entry is a notification, or
	o The PAL entry corresponds to a notification or pointer to a		o The PAL entry corresponds to a notification or pointer to a
	next PAL.		next PAL.
	o The Package Size subcomponent is provided for each PAL entry. If		o The Package Size subcomponent is provided for each PAL entry. If
	the PAL entry is for a notification, this subcomponent will be		the PAL entry is for a notification, this subcomponent will be
	populated with a zero character. Otherwise, it indicates the		populated with a zero character. Otherwise, it indicates the
	size of the identified package in bytes. The maximum size of		size of the identified package in bytes. The maximum size of
	packages is 2.1 Gbytes.		packages is 2.1 Gbytes.
	o The Additional Information subcomponent will be provided for each		o The Additional Information subcomponent will be provided for each
	PAL entry and will either provide a Distinguished Name (DN) or a		PAL entry and will either provide a Distinguished Name (DN) or a
	URI of where the identified KMS package can be retrieved. When		URI of where the identified KMS package can be retrieved. When
	the entry is a notification, the subcomponent is a DN that		the entry is a notification, the subcomponent is a DN that
	identifies a certificate that is the subject of the		identifies a certificate that is the subject of the notification.
	notification.
	When more than thirty-two PAL entries are available, an additional		When more than thirty-two PAL entries are available, an additional
	PAL is advertised in the thirty second PAL entry. The additional PAL		PAL is advertised in the thirty second PAL entry. The additional PAL
	will have between one and thirty-two PAL entries.		will have between one and thirty-two PAL entries.
	The Last Download Date MUST be represented in a form that matches the		The Last Download Date MUST be represented in a form that matches the
	dateTime production in "canonical representation" [XMLSCHEMA].		dateTime production in "canonical representation" [XMLSCHEMA].
	Implementations SHOULD NOT rely on time resolution finer than		Implementations SHOULD NOT rely on time resolution finer than
	milliseconds and MUST NOT generate time instants that specify leap		milliseconds and MUST NOT generate time instants that specify leap
	seconds.		seconds.
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	correspond to:		correspond to:
	o A PAL that provides a unique URI for each KMS package that the		o A PAL that provides a unique URI for each KMS package that the
	KMS holds for the client and URIs identifying client actions that		KMS holds for the client and URIs identifying client actions that
	need to be taken, or		need to be taken, or
	o A KMS package that the client believes is being held by the KMS.		o A KMS package that the client believes is being held by the KMS.
	The data may contain product, a protocol-related transaction, or		The data may contain product, a protocol-related transaction, or
	a collection of packages with various contents.		a collection of packages with various contents.
	Internet-Draft SODP 2011-03-07
	When a client performs an HTTP POST operation, the URI indicates the		When a client performs an HTTP POST operation, the URI indicates the
	specific KMS Service that is targeted to process the information. A		specific KMS Service that is targeted to process the information. A
	client SHALL be capable of requesting information by providing a URI		client SHALL be capable of requesting information by providing a URI
	in an HTTP GET request to a connected KMS.		in an HTTP GET request to a connected KMS.
	A client may know, or believe they know, a specific KMS package URI,		A client may know, or believe they know, a specific KMS package URI,
	because:		because:
	o They discovered the URI on a PAL,		o They discovered the URI on a PAL,
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 4 ¶
	+- certificate		+- certificate
	Figure 5 - PAL URI Components		Figure 5 - PAL URI Components
	7.2.1. URI Scheme		7.2.1. URI Scheme
	All HTTP GET and POST requests and responses MUST use "https" as the		All HTTP GET and POST requests and responses MUST use "https" as the
	scheme [RFC2818]. All processing of scheme data will be case-		scheme [RFC2818]. All processing of scheme data will be case-
	insensitive as required in [RFC3986].		insensitive as required in [RFC3986].
	PALs that do not specify "https" as the URI scheme for every PAL		PALs that do not specify "https" as the URI scheme for every PAL
	Internet-Draft SODP 2011-03-07
	entry MUST be rejected.		entry MUST be rejected.
	7.2.2. URI Authority		7.2.2. URI Authority
	The authority component of a URI identifies the KMS that the client		The authority component of a URI identifies the KMS that the client
	is requesting the specific KMS Service from. The authority component		is requesting the specific KMS Service from. The authority component
	is in the form of a host name and an optional "https" port number.		is in the form of a host name and an optional "https" port number.
	The host name identifies the HTTP server by name, and the port number		The host name identifies the HTTP server by name, and the port number
	identifies the HTTP server port that will service the request.		identifies the HTTP server port that will service the request.
	Inclusion of the port number is OPTIONAL, as port 443 MUST be used.		Inclusion of the port number is OPTIONAL, as port 443 MUST be used.
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 5 ¶
	packages, and bundled packages with one or more collections of		packages, and bundled packages with one or more collections of
	content types as offered by the KMS Distribution Service.		content types as offered by the KMS Distribution Service.
	o publication - This identifier is used to obtain publicly-		o publication - This identifier is used to obtain publicly-
	available CA, CRLs, and CPs as offered by the KMS Publication		available CA, CRLs, and CPs as offered by the KMS Publication
	Service.		Service.
	o certificate - This identifier is used in PKI issuance and rekey		o certificate - This identifier is used in PKI issuance and rekey
	protocols as offered by the KMS Certificate Management.		protocols as offered by the KMS Certificate Management.
	Internet-Draft SODP 2011-03-07
	The Product Identifier (aka Path 2), when present, is always the		The Product Identifier (aka Path 2), when present, is always the
	second path segment. It is formatted as an integer and represents		second path segment. It is formatted as an integer and represents
	the unique identifier the KMS has associated with the package to be		the unique identifier the KMS has associated with the package to be
	retrieved. Message types are included in the Message Type registry		retrieved. Message types are included in the Message Type registry
	found in Section 11. The Product Identifier is only present in the		found in Section 11. The Product Identifier is only present in the
	URIs that will be included in HTTP GET requests to obtain a package.		URIs that will be included in HTTP GET requests to obtain a package.
	The Product Identifier is not included in:		The Product Identifier is not included in:
	o The URI a client uses to obtain the initial PAL,		o The URI a client uses to obtain the initial PAL,
	skipping to change at page 26, line 4 ¶		skipping to change at page 26, line 4 ¶
	The KMS does not use Query and Fragment elements in support of KMS		The KMS does not use Query and Fragment elements in support of KMS
	Services. They are not supported by clients in the processing of		Services. They are not supported by clients in the processing of
	received URIs, or in the generation of URIs.		received URIs, or in the generation of URIs.
	The KMS MUST omit query and fragment components from PALs.		The KMS MUST omit query and fragment components from PALs.
	The KMS SHOULD reject the delivery of any PAL that contains a URI		The KMS SHOULD reject the delivery of any PAL that contains a URI
	with a query or fragment components.		with a query or fragment components.
	Clients and agents SHOULD reject the delivery of any PAL that		Clients and agents SHOULD reject the delivery of any PAL that
	Internet-Draft SODP 2011-03-07
	contains a URI with a query or fragment component.		contains a URI with a query or fragment component.
	When generating a URI, clients and agents MUST NOT populate the URI		When generating a URI, clients and agents MUST NOT populate the URI
	with any query or fragment components.		with any query or fragment components.
	8. SODP Transport Requirements		8. SODP Transport Requirements
	This section provides the requirements for SODP interactions.		This section provides the requirements for SODP interactions.
	8.1. KMS Requirements		8.1. KMS Requirements
	skipping to change at page 27, line 5 ¶		skipping to change at page 27, line 5 ¶
	of status codes. The KMS will not ask a client to take further		of status codes. The KMS will not ask a client to take further
	action to fulfill a request.		action to fulfill a request.
	o Client Error - The KMS will return this class when they cannot		o Client Error - The KMS will return this class when they cannot
	fulfill the requested GET or POST because of a client error.		fulfill the requested GET or POST because of a client error.
	o Server Error - The KMS may return this class, when a valid POST		o Server Error - The KMS may return this class, when a valid POST
	or GET request was received, but the KMS cannot fulfill the		or GET request was received, but the KMS cannot fulfill the
	request for other reasons.		request for other reasons.
	Internet-Draft SODP 2011-03-07
	8.2. Client Requirements		8.2. Client Requirements
	Clients MUST support HTTP 1.1 [RFC2616]; clients MUST support HTTP		Clients MUST support HTTP 1.1 [RFC2616]; clients MUST support HTTP
	generating GET and POST requests and HTTP GET and POST responses;		generating GET and POST requests and HTTP GET and POST responses;
	clients MUST support HTTPS [RFC2818] over TCP [RFC793] on port 443,		clients MUST support HTTPS [RFC2818] over TCP [RFC793] on port 443,
	and; clients MUST support either IPv4 [RFC791] or IPv6 [RFC2460]		and; clients MUST support either IPv4 [RFC791] or IPv6 [RFC2460]
	(IPv6 is preferred). TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST		(IPv6 is preferred). TLS 1.2 [RFC5246][I-D.tls-ssl2-must-not] MUST
	be implemented in conjunction with HTTPS. Clients MUST support		be implemented in conjunction with HTTPS. Clients MUST support
	client-side certificate authentication when connecting to the KMS.		client-side certificate authentication when connecting to the KMS.
	See Section 10 for cipher suite requirements.		See Section 10 for cipher suite requirements.
	skipping to change at page 28, line 4 ¶		skipping to change at page 28, line 4 ¶
	the KMS.		the KMS.
	If a client receives an HTTP response with a Server Error class		If a client receives an HTTP response with a Server Error class
	status code, it SHOULD either:		status code, it SHOULD either:
	o Reattempt the request after a non-deterministic delay, or		o Reattempt the request after a non-deterministic delay, or
	o Attempt the request with a different KMS.		o Attempt the request with a different KMS.
	8.3. Agent Requirements		8.3. Agent Requirements
	Internet-Draft SODP 2011-03-07
	Agent requirements are identical to those for clients with one		Agent requirements are identical to those for clients with one
	exception and that is that agents MUST support either agent-side		exception and that is that agents MUST support either agent-side
	certificate authentication when connecting to the KMS or		certificate authentication when connecting to the KMS or
	username/password.		username/password.
	9. Message Sequences		9. Message Sequences
	This section depicts message sequences when using a PAL.		This section depicts message sequences when using a PAL.
	9.1. Distribution		9.1. Distribution
	skipping to change at page 28, line 37 ¶		skipping to change at page 28, line 35 ¶
	An example PAL entry for a distribution package is as follows:		An example PAL entry for a distribution package is as follows:
	<message>		<message>
	<type>TBD</type>		<type>TBD</type>
	<date>00000000000000</date>		<date>00000000000000</date>
	<size>1996</size>		<size>1996</size>
	<info>https://www.example.com/distribution/symmtrickey1</info>		<info>https://www.example.com/distribution/symmtrickey1</info>
	</message>		</message>
	The message type TBD indicates the message is a symmetric key. The		The message type TBD indicates the message is a symmetric key. The
	date and time indicates that the package has not been downloaded.		date and time indicates that the package has not been downloaded. The
	The message size indicates the size of the package and the additional		message size indicates the size of the package and the additional
	info element provides a link to the symmetric key.		info element provides a link to the symmetric key.
	The sequence for both symmetric key and firmware packages is		The sequence for both symmetric key and firmware packages is
	identical, as shown in Figure 6. The client or agent connects to the		identical, as shown in Figure 6. The client or agent connects to the
	KMS, retrieves their PAL, and the requests the package from the URI		KMS, retrieves their PAL, and the requests the package from the URI
	provided in the additional info component.		provided in the additional info component.
	Internet-Draft SODP 2011-03-07
	| |		| |
	KMS | Establish HTTPS | Client or Agent		KMS | Establish HTTPS | Client or Agent
	| Connection |		| Connection |
	|<-------------------->|		|<-------------------->|
	| |		| |
	| Request PAL |		| Request PAL |
	| (HTTP GET) |		| (HTTP GET) |
	|<---------------------|		|<---------------------|
	|--------------------->|		|--------------------->|
	| Deliver PAL with URI |		| Deliver PAL with URI |
	skipping to change at page 30, line 4 ¶		skipping to change at page 30, line 4 ¶
	An example PAL entry for a publication package is as follows:		An example PAL entry for a publication package is as follows:
	<message>		<message>
	<type>TBD</type>		<type>TBD</type>
	<date>00000000000000</date>		<date>00000000000000</date>
	<size>1996</size>		<size>1996</size>
	<info>https://www.example.com/publication/Root.crl</info>		<info>https://www.example.com/publication/Root.crl</info>
	</message>		</message>
	The message type TBD indicates the message is a Root CRL. The date		The message type TBD indicates the message is a Root CRL. The date
	Internet-Draft SODP 2011-03-07
	and time indicates that the package has not been downloaded. The		and time indicates that the package has not been downloaded. The
	message size indicates the size of the package and the additional		message size indicates the size of the package and the additional
	info element provides a link to the Root CRL. The message sequence is		info element provides a link to the Root CRL. The message sequence is
	identical to Figure 6.		identical to Figure 6.
	9.3. Certificate Management		9.3. Certificate Management
	The KMS Certificate Management service instantiates itself with the		The KMS Certificate Management service instantiates itself with the
	distribution of notifications (i.e., start rekey), and CMC		distribution of notifications (i.e., start rekey), and CMC
	transactions. The message types are defined as follows:		transactions. The message types are defined as follows:
	skipping to change at page 31, line 4 ¶		skipping to change at page 31, line 4 ¶
	and the additional info element provides a link to the rekey		and the additional info element provides a link to the rekey
	notification.		notification.
	The message sequence for certificate rekey and issuance is a three-		The message sequence for certificate rekey and issuance is a three-
	step process. The initial step is client/agent retrieval of the PAL		step process. The initial step is client/agent retrieval of the PAL
	and then retrieval of a notification for either IA rekey or KE		and then retrieval of a notification for either IA rekey or KE
	issuance. Step two is the client/agent posting of the CMC package.		issuance. Step two is the client/agent posting of the CMC package.
	Step three is certificate request response (success or failure) from		Step three is certificate request response (success or failure) from
	the KMS. Prior to each interaction with the KMS, the client/agent		the KMS. Prior to each interaction with the KMS, the client/agent
	authenticates itself with the KMS. The three steps are depicted in		authenticates itself with the KMS. The three steps are depicted in
	Internet-Draft SODP 2011-03-07
	Figures 7-9.		Figures 7-9.
	Step 1		Step 1
	KMS | Establish HTTPS | Client or Agent		KMS | Establish HTTPS | Client or Agent
	| Connection |		| Connection |
	|<-------------------->|		|<-------------------->|
	| |		| |
	| Request PAL |		| Request PAL |
	| (HTTP GET) |		| (HTTP GET) |
	skipping to change at page 32, line 4 ¶		skipping to change at page 32, line 4 ¶
	| |		| |
	| Deliver Transaction |		| Deliver Transaction |
	| Two |		| Two |
	| (HTTP POST) |		| (HTTP POST) |
	|<---------------------|		|<---------------------|
	|--------------------->|		|--------------------->|
	| (HTTP Post Response) |		| (HTTP Post Response) |
	Figure 8 - SODP Certificate Management Service		Figure 8 - SODP Certificate Management Service
	Message Sequence Step 2		Message Sequence Step 2
	Internet-Draft SODP 2011-03-07
	Step 3		Step 3
	KMS | Establish HTTPS | Client or Agent		KMS | Establish HTTPS | Client or Agent
	| Connection |		| Connection |
	|<-------------------->|		|<-------------------->|
	| |		| |
	| Request PAL |		| Request PAL |
	| (HTTP GET) |		| (HTTP GET) |
	|<---------------------|		|<---------------------|
	|--------------------->|		|--------------------->|
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 5 ¶
	symmetrickeypackage-algs].		symmetrickeypackage-algs].
	For [RFC6032] algorithm requirements see [RFC6033].		For [RFC6032] algorithm requirements see [RFC6033].
	NOTE: The "cert-only" package does not have algorithm requirements		NOTE: The "cert-only" package does not have algorithm requirements
	because no cryptographic operations are performed while generating		because no cryptographic operations are performed while generating
	this package.		this package.
	TO DO: Include text or reference(s) for the following:		TO DO: Include text or reference(s) for the following:
	Internet-Draft SODP 2011-03-07
	For [RFC4108][RFC5911] algorithm requirements see [TO DO].		For [RFC4108][RFC5911] algorithm requirements see [TO DO].
	For [RFC5934] algorithm requirements see [TO DO].		For [RFC5934] algorithm requirements see [TO DO].
	For [RFC5280] algorithm requirements see [TO DO].		For [RFC5280] algorithm requirements see [TO DO].
	10.2. TLS Cipher Suites		10.2. TLS Cipher Suites
	The following requirements apply to the KMS, client, and agent:		The following requirements apply to the KMS, client, and agent:
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 5 ¶
	TO DO: Expand this section!		TO DO: Expand this section!
	This document relies on many other specifications. For IP and TCP		This document relies on many other specifications. For IP and TCP
	security considerations see [RFC791], [RFC793], and [RFC2460]; for		security considerations see [RFC791], [RFC793], and [RFC2460]; for
	HTTP, HTTPS, and TLS security considerations see [RFC2616],		HTTP, HTTPS, and TLS security considerations see [RFC2616],
	[RFC2818], and [RFC5246]; for URI security considerations see		[RFC2818], and [RFC5246]; for URI security considerations see
	[RFC3986]; for content type security considerations see [RFC4073],		[RFC3986]; for content type security considerations see [RFC4073],
	[RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5958], [RFC5934],		[RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5958], [RFC5934],
	[RFC6031], and [RFC6032]; for certificate security considerations see		[RFC6031], and [RFC6032]; for certificate security considerations see
	Internet-Draft SODP 2011-03-07
	[RFC5280], [RFC5480], and [RFC6010], and; for algorithm security		[RFC5280], [RFC5480], and [RFC6010], and; for algorithm security
	considerations see [RFC5959], [RFC6033],		considerations see [RFC5959], [RFC6033],
	[I-D.turner-cms-symmetrickeypackage-algs].		[I-D.turner-cms-symmetrickeypackage-algs].
	TO DO: Probably more references are needed above for algorithms based		TO DO: Probably more references are needed above for algorithms based
	on what gets added in Section 9.1.		on what gets added in Section 9.1.
	It is critical that the KMS encrypt symmetric keys and centrally-		It is critical that the KMS encrypt symmetric keys and centrally-
	generated asymmetric private keys for the end client. Failure		generated asymmetric private keys for the end client. Failure
	encrypt these keys will allow any intermediaries to intercept the key		encrypt these keys will allow any intermediaries to intercept the key
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 4 ¶
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">		<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>		<head>
	<title>SODP Messages</title>		<title>SODP Messages</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for SODP Messages</h1>		<h1>Namespace for SODP Messages</h1>
	Internet-Draft SODP 2011-03-07
	<h2>urn:ietf:params:xml:ns:TBD</h2>		<h2>urn:ietf:params:xml:ns:TBD</h2>
	<p>See TBD</p>		<p>See TBD</p>
	</body>		</body>
	</html>		</html>
	END		END
	12.2. SODP Schema		12.2. SODP Schema
	This section registers an XML schema as per the guidelines in		This section registers an XML schema as per the guidelines in
	[RFC3688].		[RFC3688].
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 4 ¶
	<xsd:complexType name="SODPMessageType">		<xsd:complexType name="SODPMessageType">
	<xsd:sequence>		<xsd:sequence>
	<xsd:element name="type" type="sodp:MessageType" />		<xsd:element name="type" type="sodp:MessageType" />
	<xsd:element name="date" type="sodp:GeneralizedTimeType" />		<xsd:element name="date" type="sodp:GeneralizedTimeType" />
	<xsd:element name="size" type="sodp:PackageSizeType" />		<xsd:element name="size" type="sodp:PackageSizeType" />
	<xsd:element name="info" type="sodp:MessageInfoType" />		<xsd:element name="info" type="sodp:MessageInfoType" />
	</xsd:sequence>		</xsd:sequence>
	</xsd:complexType>		</xsd:complexType>
	<!-- =====Simple Data Element Type Definitions ===== -->		<!-- =====Simple Data Element Type Definitions ===== -->
	Internet-Draft SODP 2011-03-07
	<xsd:simpleType name="MessageType">		<xsd:simpleType name="MessageType">
	<xsd:restriction base="xsd:string">		<xsd:restriction base="xsd:string">
	<xsd:pattern value="[0-9]+" />		<xsd:pattern value="[0-9]+" />
	<xsd:maxLength value="4" />		<xsd:maxLength value="4" />
	</xsd:restriction>		</xsd:restriction>
	</xsd:simpleType>		</xsd:simpleType>
	<xsd:simpleType name="GeneralizedTimeType">		<xsd:simpleType name="GeneralizedTimeType">
	<xsd:restriction base="xsd:string">		<xsd:restriction base="xsd:string">
	<xsd:pattern value="[0-9]{14}" />		<xsd:pattern value="[0-9]{14}" />
	skipping to change at page 37, line 5 ¶		skipping to change at page 37, line 5 ¶
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:schema>		</xsd:schema>
	12.3. SODP Message Types		12.3. SODP Message Types
	This section registers the SODP Message Types. SODP Message Types		This section registers the SODP Message Types. SODP Message Types
	registrations are to be subject to Specification Required, as per RFC		registrations are to be subject to Specification Required, as per RFC
	5226 [RFC5226]. The registry has the following values:		5226 [RFC5226]. The registry has the following values:
	Internet-Draft SODP 2011-03-07
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| Value | Message Type | Specification |		| Value | Message Type | Specification |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| 1 | Additional PAL value present | This document |		| 1 | Additional PAL value present | This document |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| 100 | IA Rekey Notification | This document |		| 100 | IA Rekey Notification | This document |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| TBD | Symmetric Key Package | This document |		| TBD | Symmetric Key Package | This document |
	skipping to change at page 38, line 5 ¶		skipping to change at page 38, line 5 ¶
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| TBD | KE Certificate Issuance | This document |		| TBD | KE Certificate Issuance | This document |
	| | Transaction Three - Success | |		| | Transaction Three - Success | |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	| TBD | KE Certificate Issuance | This document |		| TBD | KE Certificate Issuance | This document |
	| | Transaction Three - Fail | |		| | Transaction Three - Fail | |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	TO DO: Add values from Section 9 to the above table.		TO DO: Add values from Section 9 to the above table.
	Internet-Draft SODP 2011-03-07
	12.4. SODP Path 1 String Values		12.4. SODP Path 1 String Values
	This section registers SODP Path String Types as per [RFC3688]. SODP		This section registers SODP Path String Types as per [RFC3688]. SODP
	Path 1 String Value registrations are to be subject to Specification		Path 1 String Value registrations are to be subject to Specification
	Required, as per RFC 5226 [RFC5226]. The registry has the following		Required, as per RFC 5226 [RFC5226]. The registry has the following
	structure:		structure:
	+----------------------------------------+		+----------------------------------------+
	| SODP Message Types | Specification |		| SODP Message Types | Specification |
	+----------------------------------------+		+----------------------------------------+
	skipping to change at page 39, line 5 ¶		skipping to change at page 39, line 5 ¶
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
	L., Leach, P. and T. Berners-Lee, "Hypertext Transfer		L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
	Protocol -- HTTP/1.1", RFC 2616, June 1999		Protocol -- HTTP/1.1", RFC 2616, June 1999
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	Internet-Draft SODP 2011-03-07
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, January 2005.		3986, January 2005.
	[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.
	[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to		[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
	Protect Firmware Packages", RFC 4108, August 2005.		Protect Firmware Packages", RFC 4108, August 2005.
	skipping to change at page 40, line 5 ¶		skipping to change at page 40, line 5 ¶
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	June 2010.		June 2010.
	[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor		[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
	Management Protocol (TAMP)", RFC 5934, August 2010.		Management Protocol (TAMP)", RFC 5934, August 2010.
	[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August		[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
	2010.		2010.
	Internet-Draft SODP 2011-03-07
	[RFC5959] Turner, S., "Algorithms for Asymmetric Key Packages", RFC		[RFC5959] Turner, S., "Algorithms for Asymmetric Key Packages", RFC
	5959, August 2010.		5959, August 2010.
	[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic		[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
	Message Syntax (CMS) Content Constraints Extension", RFC		Message Syntax (CMS) Content Constraints Extension", RFC
	6010, September 2010.		6010, September 2010.
	[RFC6031] Turner, S., and R. Housley, "Symmetric Key Package Content		[RFC6031] Turner, S., and R. Housley, "Symmetric Key Package Content
	Type", RFC 6031, December 2010.		Type", RFC 6031, December 2010.
	skipping to change at page 41, line 5 ¶		skipping to change at page 42, line 5 ¶
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	June 2005.		June 2005.
	[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880, November 2007.		Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet
	Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,		Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
	September 2010.		September 2010.
	Internet-Draft SODP 2011-03-07
	Internet-Draft SODP 2011-03-07
	[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in		[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in
	XML", World Wide Web Consortium FirstEdition REC-xml-names-		XML", World Wide Web Consortium FirstEdition REC-xml-names-
	19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-		19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-
	names-19990114>.		names-19990114>.
	Appendix A. Example Encodings		Appendix A. Example Encodings
	TO DO: Include BASE64 encodings of ASN.1 encodings of selected		TO DO: Include BASE64 encodings of ASN.1 encodings of selected
	packages. They're a lot smaller than the ASN.1 pretty prints and		packages. They're a lot smaller than the ASN.1 pretty prints and
	there are tons of available to tools to convert.		there are tons of available to tools to convert.
End of changes. 47 change blocks.
	112 lines changed or deleted		11 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/