< draft-ietf-keyprov-pskc-01.txt		draft-ietf-keyprov-pskc-02.txt >
	keyprov P. Hoyer		keyprov P. Hoyer
	Internet-Draft ActivIdentity		Internet-Draft ActivIdentity
	Intended status: Standards Track M. Pei		Intended status: Standards Track M. Pei
	Expires: July 24, 2009 VeriSign		Expires: August 26, 2009 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	January 20, 2009		February 22, 2009
	Portable Symmetric Key Container (PSKC)		Portable Symmetric Key Container (PSKC)
	draft-ietf-keyprov-pskc-01.txt		draft-ietf-keyprov-pskc-02.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 24, 2009.		This Internet-Draft will expire on August 26, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Portable Key Container Entities Overview and Relationships . . 6		3. Portable Key Container Entities Overview and Relationships . . 6
	4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 8		4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 8
	4.1. <DeviceInfo> Element: Unique Device Identification . . . . 9		4.1. <DeviceInfo> Element: Unique Device Identification . . . . 9
	4.2. <Key>: Embedding Keying Material . . . . . . . . . . . . . 10		4.2. <Key>: Embedding Keying Material . . . . . . . . . . . . . 10
	4.3. <User> Element: User Identification . . . . . . . . . . . 11		4.3. <User> Element: User Identification . . . . . . . . . . . 11
	4.4. <Usage> Element: Supplementary Information for OTP and		4.4. <Usage> Element: Supplementary Information for OTP and
	CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 11		CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12
	5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Protection of Keys and Related Data . . . . . . . . . . . . . 18		6. Protection of Keys and Related Data . . . . . . . . . . . . . 19
	6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 18		6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19
	6.2. Encryption based on Passphrase-based Keys . . . . . . . . 20		6.2. Encryption based on Passphrase-based Keys . . . . . . . . 22
	6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 23		6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24
	6.4. Transmission of Key Derivation Values . . . . . . . . . . 25		6.4. Transmission of Key Derivation Values . . . . . . . . . . 26
	7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 27		7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28
	8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 29		8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 32		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33
	10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 33		10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34
	10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 33		10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34
	11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 35		11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	12.1. Content-type registration for 'application/pskc+xml' . . . 42		12.1. Content-type registration for 'application/pskc+xml' . . . 43
	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 43		12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44
	12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 43		12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44
	12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 44		12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45
	12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 45		12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46
	12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 45		12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 46		13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 46		13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 48
	13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 47		13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 49
	13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 47		13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 49
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 50		16.1. Normative References . . . . . . . . . . . . . . . . . . . 52
	16.2. Informative References . . . . . . . . . . . . . . . . . . 50		16.2. Informative References . . . . . . . . . . . . . . . . . . 52
	Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 52		Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 54
	A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 52		A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 54
	A.1.1. Transport of keys from Server to Cryptographic		A.1.1. Transport of keys from Server to Cryptographic
	Module . . . . . . . . . . . . . . . . . . . . . . . . 52		Module . . . . . . . . . . . . . . . . . . . . . . . . 54
	A.1.2. Transport of keys from Cryptographic Module to		A.1.2. Transport of keys from Cryptographic Module to
	Cryptographic Module . . . . . . . . . . . . . . . . . 52		Cryptographic Module . . . . . . . . . . . . . . . . . 54
	A.1.3. Transport of keys from Cryptographic Module to		A.1.3. Transport of keys from Cryptographic Module to
	Server . . . . . . . . . . . . . . . . . . . . . . . . 53		Server . . . . . . . . . . . . . . . . . . . . . . . . 55
	A.1.4. Server to server Bulk import/export of keys . . . . . 53		A.1.4. Server to server Bulk import/export of keys . . . . . 55
	A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 53		A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 55
	A.2.1. Server to server Bulk import/export of keys . . . . . 53		A.2.1. Server to server Bulk import/export of keys . . . . . 55
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 55		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 57
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
	1. Introduction		1. Introduction
	With increasing use of symmetric key based authentication systems,		With increasing use of symmetric key based authentication systems,
	such as those based one time password (OTP) and challenge response		such as those based one time password (OTP) and challenge response
	mechanisms, there is a need for vendor interoperability and a		mechanisms, there is a need for vendor interoperability and a
	standard format for importing and exporting (provisioning) symmetric		standard format for importing and exporting (provisioning) symmetric
	keys. Traditionally, vendors of authentication servers and service		keys. Traditionally, vendors of authentication servers and service
	providers have used proprietary formats for importing and exporting		providers have used proprietary formats for importing and exporting
	these keys into their systems making it hard to use tokens from		these keys into their systems making it hard to use tokens from
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	3. DeviceInfo entity - representing the information about the device		3. DeviceInfo entity - representing the information about the device
	and criteria to uniquely identify the device		and criteria to uniquely identify the device
	4. Key entity - representing the key transmitted		4. Key entity - representing the key transmitted
	5. KeyData entity - representing data related to the key including		5. KeyData entity - representing data related to the key including
	value either in plain or encrypted		value either in plain or encrypted
	Figure 1 shows the high-level structure of the PSKC data elements.		Figure 1 shows the high-level structure of the PSKC data elements.
	-----------------		+---------------+
	| KeyContainer |		| KeyContainer |
	|---------------|		+---------------+
	| EncryptionKey |		| EncryptionKey |
	| Signature |		| Signature |
	| ... |		| ... |
	-----------------		+---------------+
	|		|
	|		|
	/|\ 1..n		/|\ 1..n
	---------------- ----------------		+--------------+ +--------------+
	| Device | 1| DeviceInfo |		| Device | 1| DeviceInfo |
	|--------------|-----|--------------|		+--------------+-----+--------------+
	| User | | SerialNumber |		| User | | SerialNumber |
	---------------- | Manufacturer |		+--------------+ | Manufacturer |
	| | .... |		| | .... |
	| ----------------		| +--------------+
	/|\ 1..n		/|\ 1..n
	----------------		+--------------+
	| Key |		| Key |
	|--------------|		+--------------+
	| ID |		| ID |
	| Algorithm |		| Algorithm |
	| User |		| User |
	| .... |		| .... |
	----------------		+--------------+
	|		|
	|		|
	/|\ 1..n --------------		/|\ 1..n +------------+
	---------------- | Plainvalue |		+--------------+ | Plainvalue |
	| KeyData | --------------		| KeyData | +----+-------+
	|--------------| |		+--------------+ |
	| name | either|		| name | either|
	| value |----------|		| value +----------+
	| ..... | ------------------		| ..... | +------+---------+
	---------------- | EncryptedValue |		+--------------+ | EncryptedValue |
	------------------		+----------------+
	Figure 1		Figure 1
	The following sections describe in detail all the entities and		The following sections describe in detail all the entities and
	related XML schema elements and attributes.		related XML schema elements and attributes.
	4. <KeyContainer> Element: The Basics		4. <KeyContainer> Element: The Basics
	In it's most basic form a PSKC document uses the top-level element		In it's most basic form a PSKC document uses the top-level element
	<KeyContainer> and a single <Device> element to carry key		<KeyContainer> and a single <Device> element to carry key
	information.		information.
	The following example shows such a simple PSKC document. We will use		The following example shows such a simple PSKC document. We will use
	it to describe the structure of the <KeyContainer> element and it's		it to describe the structure of the <KeyContainer> element and it's
	child elements.		child elements.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1" id="exampleID1"		<KeyContainer Version="1.0" id="exampleID1"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<Device>		<Device>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyId="12345678"		<Key KeyId="12345678"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<Usage>
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 49 ¶
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	Figure 2: Basic PSKC Key Container Example		Figure 2: Basic PSKC Key Container Example
	The attributes of the <KeyContainer> element have the following		The attributes of the <KeyContainer> element have the following
	semantic:		semantic:
	'Version:' The 'Version' attribute is used to identify the version		'Version:' The 'Version' attribute is used to identify the version
	of the PSKC schema version. This specification defines the		of the PSKC schema version. This specification defines the
	initial version ("1") of the PSKC schema. This attribute is		initial version ("1.0") of the PSKC schema. This attribute is
	mandatory.		mandatory.
	'ID:' The 'ID' attribute carries a unique identifier for the		'ID:' The 'ID' attribute carries a unique identifier for the
	container. As such, it helps to identify a specific key		container. As such, it helps to identify a specific key
	container.		container.
	A <KeyContainer> element MUST contain at least one <Device> element.		A <KeyContainer> element MUST contain at least one <Device> element.
	Multiple <Device> elements can be used when for bulk provisioning,		Multiple <Device> elements can be used when for bulk provisioning,
	see Section 8. A <Device> MUST contain at least one <Key> element.		see Section 8. A <Device> MUST contain at least one <Key> element.
	A <Device> MAY be bound to a user. A key SHOULD be bound to only one		A <Device> MAY be bound to a user. A key SHOULD be bound to only one
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	<SerialNo>: This element contains the serial number of the device.		<SerialNo>: This element contains the serial number of the device.
	<Model>: This element describes the model of the device (e.g., one-		<Model>: This element describes the model of the device (e.g., one-
	button-HOTP-token-V1).		button-HOTP-token-V1).
	<IssueNo>: This element contains the issue number in case devices		<IssueNo>: This element contains the issue number in case devices
	with the same serial number that are distinguished by different		with the same serial number that are distinguished by different
	issue numbers.		issue numbers.
	<DeviceBinding>: This element carries the identifier that can be		<DeviceBinding>: In a number of cases access to lower layer device
	used to bind keys to the device or to a class of devices. When		identifiers, such as a serial number, from a PSKC implementation
	loading keys into a device, this identifier can be checked against		is difficult or not possible. For this purpose an opaque
	information obtained from the device to ensure that the correct		identifier, carried in the <DeviceBinding> element, is introduced
	device or class of device is being used.		that allows to bind keys to the device or to a class of devices.
			When loading keys into a device, the value of the <DeviceBinding>
			element MUST be checked against information provided to the user
			via out-of-band mechanisms. The implementation then ensures that
			the correct device or class of device is being used with respect
			to the provisioned key.
	<StartDate>: and <ExpiryDate>: These two elements indicates the		<StartDate>: and <ExpiryDate>: These two elements indicates the
	start and end date of a device (such as the one on a payment card,		start and end date of a device (such as the one on a payment card,
	used when issue numbers are not printed on cards). The date MUST		used when issue numbers are not printed on cards). The date MUST
	be expressed in UTC form with no timezone component.		be expressed in UTC form with no timezone component.
	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.
	Depending on the device type certain child elements of the		Depending on the device type certain child elements of the
	<DeviceInfo> element are necessary to include in order to uniquely		<DeviceInfo> element are necessary to include in order to uniquely
	identify a device. This document does not enumerate the different		identify a device. This document does not enumerate the different
	device types and therefore does not list the elements that are		device types and therefore does not list the elements that are
	mandatory for each type of device.		mandatory for each type of device.
	skipping to change at page 15, line 6 ¶		skipping to change at page 15, line 6 ¶
	If the <Policy> element contains child elements or values within		If the <Policy> element contains child elements or values within
	elements/attributes that are not understood by the recipient of the		elements/attributes that are not understood by the recipient of the
	PSKC document then the recipient MUST assume that key usage is not		PSKC document then the recipient MUST assume that key usage is not
	permitted. This statement ensures that the lack of understanding of		permitted. This statement ensures that the lack of understanding of
	certain extension does not lead to unintended key usage.		certain extension does not lead to unintended key usage.
	We will start our description with an example that expands the		We will start our description with an example that expands the
	example shown in Figure 3.		example shown in Figure 3.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1" id="exampleID1"		<KeyContainer Version="1.0" id="exampleID1"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<Device>		<Device>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyId="12345678"		<Key KeyId="12345678"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<Usage>
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶
	<StartDate> and <ExpiryDate>: These two elements denote the validity		<StartDate> and <ExpiryDate>: These two elements denote the validity
	period of a key. It MUST be ensured that the key is only used		period of a key. It MUST be ensured that the key is only used
	between the start and the end date (inclusive). The value MUST be		between the start and the end date (inclusive). The value MUST be
	expressed in UTC form, with no time zone component.		expressed in UTC form, with no time zone component.
	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. When this element is absent then the current time is		seconds. When this element is absent then the current time is
	assumed as a start time.		assumed as a start time.
			<NumberOfTransactions>: The value in this element indicates a
			restriction regarding the number of times a key carried within the
			PSKC document can be applied. When this element is omitted then
			there is no restriction regarding the number of times a key is
			used.
	<KeyUsage>: The <KeyUsage> element puts constraints on the intended		<KeyUsage>: The <KeyUsage> element puts constraints on the intended
	usage of the key. The recipient of the PSKC document MUST enforce		usage of the key. The recipient of the PSKC document MUST enforce
	the key usage. Currently, the following tokens are registered by		the key usage. Currently, the following tokens are registered by
	this document:		this document:
	OTP: The key MUST only be used for OTP generation.		OTP: The key MUST only be used for OTP generation.
	CR: The key MUST only be used for Challenge/Response purposes.		CR: The key MUST only be used for Challenge/Response purposes.
	Encrypt: The key MUST only be used for data encryption purposes.		Encrypt: The key MUST only be used for data encryption purposes.
	skipping to change at page 16, line 37 ¶		skipping to change at page 16, line 43 ¶
	Unlock: The key MUST only be used for an inverse challenge		Unlock: The key MUST only be used for an inverse challenge
	response in the case a user has locked the device by entering a		response in the case a user has locked the device by entering a
	wrong PIN too many times (for devices with PIN-input		wrong PIN too many times (for devices with PIN-input
	capability).		capability).
	Decrypt: The key MUST only be used for data decryption purposes.		Decrypt: The key MUST only be used for data decryption purposes.
	KeyWrap: The key MUST only be used for key wrap purposes.		KeyWrap: The key MUST only be used for key wrap purposes.
			Unwrap: The key MUST only be used for key unwrap purposes.
			Derive: The key MUST only be used with a key derivation function
			to derive a new key (see also Section 8.2.4 of [NIST]).
			Generate: The key MUST only be used to generate a new key based
			on a random number and the previous value of the key (see also
			Section 8.1.5.2.1 of[NIST]).
			Verify: The key MUST only be used to verify the digest or
			signatures ( is the vice verso of Integrity)
	The element MAY also be repeated to allow several key usages to be		The element MAY also be repeated to allow several key usages to be
	expressed. When this element is absent then no key usage		expressed. When this element is absent then no key usage
	constraint is assumed, i.e., the key MAY be utilized for every		constraint is assumed, i.e., the key MAY be utilized for every
	usage.		usage.
	<PINPolicy>: The <PINPolicy> element allows policy about the PIN		<PINPolicy>: The <PINPolicy> element allows policy about the PIN
	usage to be associated with the key. The following attributes are		usage to be associated with the key. The following attributes are
	specified:		specified:
	'PINKeyId': This attribute contains the unique key id of the key		'PINKeyId': This attribute contains the unique key id of the key
	skipping to change at page 19, line 6 ¶		skipping to change at page 20, line 6 ¶
	of the pre-shared secret is "Example-Key1", as set in the <KeyName>		of the pre-shared secret is "Example-Key1", as set in the <KeyName>
	element (which is a child element of the <EncryptionKey> element).		element (which is a child element of the <EncryptionKey> element).
	The value of the key used is '12345678901234567890123456789012'.		The value of the key used is '12345678901234567890123456789012'.
	Since AES128-CBC does not provide integrity checks a keyed MAC is		Since AES128-CBC does not provide integrity checks a keyed MAC is
	applied to the encrypted value using the algorithm indicated in		applied to the encrypted value using the algorithm indicated in
	<MACAlgorithm> element (in our example		<MACAlgorithm> element (in our example
	"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used). The result		"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used). The result
	of the keyed MAC computation is placed in the <ValueMAC> element.		of the keyed MAC computation is placed in the <ValueMAC> element.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		<KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<EncryptionKey>		<EncryptionKey>
	<ds:KeyName>Pre-shared-key</ds:KeyName>		<ds:KeyName>Pre-shared-key</ds:KeyName>
	</EncryptionKey>		</EncryptionKey>
	<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1		<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
	</MACAlgorithm>		</MACAlgorithm>
	<Device>		<Device>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	skipping to change at page 20, line 5 ¶		skipping to change at page 21, line 5 ¶
	</Key>		</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	Figure 4: AES-128-CBC Encrypted Pre-Shared Secret Key		Figure 4: AES-128-CBC Encrypted Pre-Shared Secret Key
	When protecting the payload with pre-shared keys implementations MUST		When protecting the payload with pre-shared keys implementations MUST
	set the name of the specific pre-shared key in the <KeyName> element		set the name of the specific pre-shared key in the <KeyName> element
	inside the <EncryptionKey> element.		inside the <EncryptionKey> element.
	Systems implementing PSKC MUST support AES128-CBC (with the URI of		For systems implementing PSKC it is RECOMMENDED to support AES-128-
	http://www.w3.org/2001/04/xmlenc#aes128-cbc). An example list of		CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and
	optionally-to-implement encryption algorithms can be found below:		KW-AES128 (with the URI of
			http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-
			AES128 requires that the key to be protected must be a multiple of 8
			bytes. Hence, if keys of a different length have to be protected
			then the usage of the key wrap algorithm with padding, as described
			in [I-D.housley-aes-key-wrap-with-pad] is RECOMMENDED. An example
			list of optionally-to-implement encryption algorithms can be found
			below:
	Algorithm | Uniform Resource Locator (URL)		Algorithm | Uniform Resource Locator (URL)
	---------------+-------------------------------------------------------		---------------+-------------------------------------------------------
	AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc		AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
	AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc		AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
	TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc		TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
	Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128		Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
	Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192		Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
	Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256		Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
	KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128		KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
	KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192		KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
	KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256		KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
	KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes		KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
	KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128		KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
	KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192		KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
	KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256		KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
	When algorithms without integrity checks are used, such as AES12-CBC,		When algorithms without integrity checks are used, such as AES-128-
	a keyed MAC value using the same key as the key encryption key MUST		CBC, a keyed MAC value using the same key as the key encryption key
	be placed in the <ValueMAC> element of the <Data> element. In this		MUST be placed in the <ValueMAC> element of the <Data> element. In
	case the MAC algorithm type MUST be set in the <MACAlgorithm> element		this case the MAC algorithm type MUST be set in the <MACAlgorithm>
	of the <KeyContainer> element. Implementations of PSKC MUST support		element of the <KeyContainer> element. Implementations of PSKC MUST
	HMAC-SHA1 (with the URI of		support HMAC-SHA1 (with the URI of
	http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-		http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-
	implement MAC algorithm. An example list of optionally-to-implement		implement MAC algorithm. An example list of optionally-to-implement
	MAC algorithms can be found below:		MAC algorithms can be found below:
	Algorithm | Uniform Resource Locator (URL)		Algorithm | Uniform Resource Locator (URL)
	---------------+-----------------------------------------------------		---------------+-----------------------------------------------------
	HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256		HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
	HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384		HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
	HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512		HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
	skipping to change at page 22, line 24 ¶		skipping to change at page 23, line 31 ¶
	This key is also used to calculate MAC value of the secret key		This key is also used to calculate MAC value of the secret key
	"12345678901234567890". The encryption with algorithm "AES-128-CBC"		"12345678901234567890". The encryption with algorithm "AES-128-CBC"
	follows the specification defined in [XMLENC].		follows the specification defined in [XMLENC].
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer		<KeyContainer
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:pkcs5=		xmlns:pkcs5=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"		"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	Version="1">		Version="1.0">
	<EncryptionKey>		<EncryptionKey>
	<DerivedKey>		<DerivedKey>
	<CarriedKeyName>Passphrase1</CarriedKeyName>		<CarriedKeyName>Passphrase1</CarriedKeyName>
	<KeyDerivationMethod		<KeyDerivationMethod
	Algorithm=		Algorithm=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">		"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
	<pkcs5:PBKDF2-params>		<pkcs5:PBKDF2-params>
	<pkcs5:Salt>		<pkcs5:Salt>
	<pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified>		<pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified>
	</pkcs5:Salt>		</pkcs5:Salt>
	skipping to change at page 24, line 5 ¶		skipping to change at page 25, line 5 ¶
	6.3. Encryption based on Asymmetric Keys		6.3. Encryption based on Asymmetric Keys
	When using asymmetric keys to encrypt child elements of the <Data>		When using asymmetric keys to encrypt child elements of the <Data>
	element information about the certificate being used MUST be stated		element information about the certificate being used MUST be stated
	in the <X509Data> element, which is a child element of the		in the <X509Data> element, which is a child element of the
	<EncryptionKey> element. The encryption algorithm MUST be indicated		<EncryptionKey> element. The encryption algorithm MUST be indicated
	in the 'Algorithm' attribute of the <EncryptionMethod> element. In		in the 'Algorithm' attribute of the <EncryptionMethod> element. In
	the example shown in Figure 6 the algorithm is set to		the example shown in Figure 6 the algorithm is set to
	"http://www.w3.org/2001/04/xmlenc#rsa_1_5".		"http://www.w3.org/2001/04/xmlenc#rsa_1_5".
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8" ?>
	<KeyContainer Version="1"		<KeyContainer
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	<EncryptionKey>		id="KC0001"
	<ds:X509Data>		Version="1.0">
	<ds:X509Certificate>miib</ds:X509Certificate>		<EncryptionKey>
	</ds:X509Data>		<ds:X509Data>
	</EncryptionKey>		<ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
	<Device>		Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
	<DeviceInfo>		Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
	<Manufacturer>Manufacturer</Manufacturer>		GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
	<SerialNo>0755225266</SerialNo>		hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
	</DeviceInfo>		DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
	<Key KeyAlgorithm=		xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
	"urn:ietf:params:xml:ns:keyprov:pskc#hotp"		JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
	KeyId="0755225266">		rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
	<Issuer>AnIssuer</Issuer>		4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
	<Usage>		</ds:X509Certificate>
	<ResponseFormat Length="8"		</ds:X509Data>
	Encoding="DECIMAL"/>		</EncryptionKey>
	</Usage>		<MACAlgorithm>
	<Data>		http://www.w3.org/2000/09/xmldsig#hmac-sha1
	<Secret>		</MACAlgorithm>
	<EncryptedValue Id="ED">		<Device>
	<xenc:EncryptionMethod		<DeviceInfo>
	Algorithm=		<Manufacturer>TokenVendorAcme</Manufacturer>
	"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		<SerialNo>987654321</SerialNo>
	<xenc:CipherData>		</DeviceInfo>
	<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=		<Key
	</xenc:CipherValue>		KeyId="MBK000000001"
	</xenc:CipherData>		KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	</EncryptedValue>		<Issuer>Example-Issuer</Issuer>
	</Secret>		<Usage>
	<Counter>		<ResponseFormat Length="6" Encoding="DECIMAL"/>
	<PlainValue>0</PlainValue>		</Usage>
	</Counter>		<Data>
	</Data>		<Secret>
	</Key>		<EncryptedValue>
	</Device>		<xenc:EncryptionMethod
	</KeyContainer>		Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
			<xenc:CipherData>
			<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
			xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
			Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
			</xenc:CipherValue>
			</xenc:CipherData>
			</EncryptedValue>
			</Secret>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
			</Data>
			</Key>
			</Device>
			</KeyContainer>
	Figure 6: Example of a PSKC Document using Encryption based on		Figure 6: Example of a PSKC Document using Encryption based on
	Asymmetric Keys		Asymmetric Keys
	Systems implementing PSKC MUST support the		Systems implementing PSKC MUST support the
	http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm.		http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm.
	http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is an example of an		http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is an example of an
	optional-to-implement algorithm.		optional-to-implement algorithm.
	6.4. Transmission of Key Derivation Values		6.4. Transmission of Key Derivation Values
	<KeyProfileId> element, which is a child element of the <Key>		<KeyProfileId> element, which is a child element of the <Key>
	element, carries a unique identifier used between the sending and		element, carries a unique identifier used between the sending and
	receiving party to establish a set of key attribute values that are		receiving party to establish a set of key attribute values that are
	not transmitted within the container but agreed between the two		not transmitted within the container but agreed between the two
	parties out of band. This element will then represent the unique		parties out of band. This element will then represent the unique
	skipping to change at page 25, line 33 ¶		skipping to change at page 26, line 48 ¶
	KeyProfileId='1' would represent a certain set of values (e.g.,		KeyProfileId='1' would represent a certain set of values (e.g.,
	Internet authentication flag set to a specific value). When sending		Internet authentication flag set to a specific value). When sending
	keys these values would not be transmitted as key attributes but only		keys these values would not be transmitted as key attributes but only
	referred to via the <KeyProfileId> element set to the specific agreed		referred to via the <KeyProfileId> element set to the specific agreed
	profile (in this case '1'). When the receiving party receives the		profile (in this case '1'). When the receiving party receives the
	keys it can then associate all relevant key attributes contained in		keys it can then associate all relevant key attributes contained in
	the out of band agreed profile with the imported keys. Often this		the out of band agreed profile with the imported keys. Often this
	methodology is used between the manufacturing and the validation		methodology is used between the manufacturing and the validation
	service to avoid transmission of mainly the same set of values.		service to avoid transmission of mainly the same set of values.
	<MasterKeyId> element uniquely references an external master key when		The <KeyReference> element contains a reference to an external key
	key derivation schemes are used and no specific key is transported		when key derivation schemes are used and no specific key is
	but only the reference to the master key used to derive a specific		transported but only the reference to the external key is used (e.g.,
	key and some derivation data (e.g., the PKCS#11 key label).		the PKCS#11 key label).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1" id="exampleID1"		<KeyContainer Version="1" id="exampleID1"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<Device>		<Device>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyId="12345678"		<Key KeyId="12345678"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<Usage>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</Usage>
	<KeyProfileId>keyProfile1</KeyProfileId>		<KeyProfileId>keyProfile1</KeyProfileId>
	<MasterKeyId>MasterKeyLabel</MasterKeyId>		<KeyReference>MasterKeyLabel</KeyReference>
	<Data>		<Data>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<KeyUsage>OTP</KeyUsage>		<KeyUsage>OTP</KeyUsage>
	</Policy>		</Policy>
	</Key>		</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	The key value will be derived using the serialnumber and a pre-shared		The key value will be derived using the serialnumber and an external
	masterkey identified by 'MasterKeyLabel'.		key identified by the label 'MasterKeyLabel'.
	Figure 7: Example of a PSKC Document transmitting a HOTP key via key		Figure 7: Example of a PSKC Document transmitting a HOTP key via key
	derivation values		derivation values
	7. Digital Signature		7. Digital Signature
	PSKC allows a digital signature to be added to the XML document, as a		PSKC allows a digital signature to be added to the XML document, as a
	child element of the <KeyContainer> element. The description of the		child element of the <KeyContainer> element. The description of the
	XML digital signature can be found in [XMLDSIG].		XML digital signature can be found in [XMLDSIG].
	skipping to change at page 35, line 42 ¶		skipping to change at page 36, line 42 ¶
	<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"		<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Device" type="pskc:DeviceType"		<xs:element name="Device" type="pskc:DeviceType"
	minOccurs="1" maxOccurs="unbounded"/>		minOccurs="1" maxOccurs="unbounded"/>
	<xs:element name="Signature" type="ds:SignatureType"		<xs:element name="Signature" type="ds:SignatureType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="xs:unsignedInt"		<xs:attribute name="Version" type="pskc:VersionType"
	use="required"/>		use="required"/>
	<xs:attribute name="id" type="xs:ID" use="optional"/>		<xs:attribute name="id" type="xs:ID" use="optional"/>
	</xs:complexType>		</xs:complexType>
			<xs:simpleType name="VersionType" final="restriction">
			<xs:restriction base="xs:string">
			<xs:pattern value="\d{1,2}\.\d{1,3}"/>
			</xs:restriction>
			</xs:simpleType>
	<xs:complexType name="KeyType">		<xs:complexType name="KeyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Issuer"		<xs:element name="Issuer"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Usage"		<xs:element name="Usage"
	type="pskc:UsageType"/>		type="pskc:UsageType"/>
	<xs:element name="KeyProfileId"		<xs:element name="KeyProfileId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="MasterKeyId"		<xs:element name="KeyReference"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="FriendlyName"		<xs:element name="FriendlyName"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Data" type="pskc:KeyDataType"		<xs:element name="Data" type="pskc:KeyDataType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="UserId" type="xs:string"		<xs:element name="UserId" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Policy"		<xs:element name="Policy"
	type="pskc:PolicyType" minOccurs="0"/>		type="pskc:PolicyType" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	skipping to change at page 36, line 39 ¶		skipping to change at page 37, line 44 ¶
	<xs:complexType name="PolicyType">		<xs:complexType name="PolicyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="StartDate"		<xs:element name="StartDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="ExpiryDate"		<xs:element name="ExpiryDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="PINPolicy"		<xs:element name="PINPolicy"
	type="pskc:PINPolicyType" minOccurs="0"/>		type="pskc:PINPolicyType" minOccurs="0"/>
	<xs:element name="KeyUsage"		<xs:element name="KeyUsage"
	type="pskc:KeyUsageType" minOccurs="0"/>		type="pskc:KeyUsageType" minOccurs="0"/>
			<xs:element name="NumberOfTransactions"
			type="xs:nonNegativeInteger" minOccurs="0"/>
	<xs:any namespace="##other"		<xs:any namespace="##other"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyDataType">		<xs:complexType name="KeyDataType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Secret"		<xs:element name="Secret"
	type="pskc:binaryDataType"		type="pskc:binaryDataType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="Counter"		<xs:element name="Counter"
	type="pskc:longDataType"		type="pskc:longDataType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="Time"		<xs:element name="Time"
	type="pskc:intDataType"		type="pskc:intDataType"
	skipping to change at page 45, line 45 ¶		skipping to change at page 46, line 45 ¶
	Key Usage Token | Specification		Key Usage Token | Specification
	+---------------------------+-------------------------------		+---------------------------+-------------------------------
	| OTP | [Section 5 of this document]		| OTP | [Section 5 of this document]
	| CR | [Section 5 of this document]		| CR | [Section 5 of this document]
	| Encrypt | [Section 5 of this document]		| Encrypt | [Section 5 of this document]
	| Integrity | [Section 5 of this document]		| Integrity | [Section 5 of this document]
	| Unlock | [Section 5 of this document]		| Unlock | [Section 5 of this document]
	| Decrypt | [Section 5 of this document]		| Decrypt | [Section 5 of this document]
	| KeyWrap | [Section 5 of this document]		| KeyWrap | [Section 5 of this document]
			| Unwrap | [Section 5 of this document]
			| Derive | [Section 5 of this document]
			| Generate | [Section 5 of this document]
			| Verify | [Section 5 of this document]
	+---------------------------+-------------------------------		+---------------------------+-------------------------------
	Expert Review is required to define new key usage tokens. Each		Expert Review is required to define new key usage tokens. Each
	registration request has to provide a description of the semantic.		registration request has to provide a description of the semantic.
	Using the same procedure it is possible to depreciate, delete, or		Using the same procedure it is possible to depreciate, delete, or
	modify existing key usage tokens.		modify existing key usage tokens.
	13. Security Considerations		13. Security Considerations
	The portable key container carries sensitive information (e.g.,		The portable key container carries sensitive information (e.g.,
	cryptographic keys) and may be transported across the boundaries of		cryptographic keys) and may be transported across the boundaries of
	one secure perimeter to another. For example, a container residing		one secure perimeter to another. For example, a container residing
	within the secure perimeter of a back-end provisioning server in a		within the secure perimeter of a back-end provisioning server in a
	secure room may be transported across the internet to an end-user		secure room may be transported across the internet to an end-user
	skipping to change at page 49, line 14 ¶		skipping to change at page 51, line 14 ¶
	15. Acknowledgements		15. Acknowledgements
	The authors of this draft would like to thank the following people		The authors of this draft would like to thank the following people
	for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,		for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
	Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea		Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea
	Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and		Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and
	especially Robert Philpott.		especially Robert Philpott.
	We would like to thank Sean Turner for his draft review in January		We would like to thank Sean Turner for his draft review in January
	2009.		2009. We would also like to thank Anders Rundgren for triggering the
			discussion regarding to the selection of encryption algorithms (KW-
			AES-128 vs. AES-128-CBC) and his input on the keyed message digest
			computation.
	This work is based on earlier work by the members of OATH (Initiative		This work is based on earlier work by the members of OATH (Initiative
	for Open AuTHentication), see [OATH], to specify a format that can be		for Open AuTHentication), see [OATH], to specify a format that can be
	freely distributed to the technical community.		freely distributed to the technical community.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography		[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
	skipping to change at page 50, line 52 ¶		skipping to change at page 52, line 52 ¶
	[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,		[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
	"Dynamic Symmetric Key Provisioning Protocol", Internet		"Dynamic Symmetric Key Provisioning Protocol", Internet
	Draft Informational, URL: http://www.ietf.org/		Draft Informational, URL: http://www.ietf.org/
	internet-drafts/draft-ietf-keyprov-dskpp-05.txt,		internet-drafts/draft-ietf-keyprov-dskpp-05.txt,
	February 2008.		February 2008.
	[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and		[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
	O. Ranen, "HOTP: An HMAC-Based One Time Password		O. Ranen, "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226, December 2005.		Algorithm", RFC 4226, December 2005.
			[I-D.housley-aes-key-wrap-with-pad]
			Housley, R. and M. Dworkin, "Advanced Encryption Standard
			(AES) Key Wrap Algorithm with Padding",
			draft-housley-aes-key-wrap-with-pad-00 (work in progress),
			January 2009.
	[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,		[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
	August 1960, <http://patft.uspto.gov/netacgi/		August 1960, <http://patft.uspto.gov/netacgi/
	nph-Parser?patentnumber=2950048>.		nph-Parser?patentnumber=2950048>.
			[NIST] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
			"NIST Special Publication 800-57, Recommendation for Key
			Management - Part 1: General (Revised)", NIST Special
			Publication 800-57, March 2007.
	[OATH] "Initiative for Open AuTHentication",		[OATH] "Initiative for Open AuTHentication",
	URL: http://www.openauthentication.org.		URL: http://www.openauthentication.org.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Appendix A. Use Cases		Appendix A. Use Cases
	This section describes a comprehensive list of use cases that		This section describes a comprehensive list of use cases that
End of changes. 47 change blocks.
	135 lines changed or deleted		204 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/