< draft-ietf-keyprov-pskc-02.txt		draft-ietf-keyprov-pskc-03.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: August 26, 2009 VeriSign		Expires: December 11, 2009 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	February 22, 2009		June 9, 2009
	Portable Symmetric Key Container (PSKC)		Portable Symmetric Key Container (PSKC)
	draft-ietf-keyprov-pskc-02.txt		draft-ietf-keyprov-pskc-03
	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 August 26, 2009.		This Internet-Draft will expire on December 11, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	This document specifies a symmetric key format for transport and		This document specifies a symmetric key format for transport and
	provisioning of symmetric keys (for example One Time Password (OTP)		provisioning of symmetric keys to different types of crypto modules.
	shared secrets or symmetric cryptographic keys) to different types of		For example One Time Password (OTP) shared secrets or symmetric
	crypto modules, such as a strong authentication device. The standard		cryptographic keys to strong authentication devices. The standard
	key transport format enables enterprises to deploy best-of-breed		key transport format enables enterprises to deploy best-of-breed
	solutions combining components from different vendors into the same		solutions combining components from different vendors into the same
	infrastructure.		infrastructure.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Portable Key Container Entities Overview and Relationships . . 6		1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 8		1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4
	4.1. <DeviceInfo> Element: Unique Device Identification . . . . 9		1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4
	4.2. <Key>: Embedding Keying Material . . . . . . . . . . . . . 10		1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5
	4.3. <User> Element: User Identification . . . . . . . . . . . 11		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. <Usage> Element: Supplementary Information for OTP and		3. Portable Key Container Entities Overview and Relationships . . 7
	CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12		4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 9
	5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.1. <Key>: Embedding Keying Material and Key Related
	6. Protection of Keys and Related Data . . . . . . . . . . . . . 19		Information . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19		4.2. Transmission of supplementary Information . . . . . . . . 11
	6.2. Encryption based on Passphrase-based Keys . . . . . . . . 22		4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12
	6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24		4.2.2. <CryptoModuleInfo> Element: CryptoModule
	6.4. Transmission of Key Derivation Values . . . . . . . . . . 26		Identification . . . . . . . . . . . . . . . . . . . . 13
	7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28		4.2.3. <UserId> Element: User Identification . . . . . . . . 14
	8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30		4.2.4. <AlgorithmParameters> Element: Supplementary
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33		Information for OTP and CR Algorithms . . . . . . . . 14
	10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34		4.3. Transmission of Key Derivation Values . . . . . . . . . . 16
	10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34		5. Key policy - transmission of key usage policies and key
	10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34		PIN protection policy . . . . . . . . . . . . . . . . . . . . 18
	11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36		6. Key protection methods . . . . . . . . . . . . . . . . . . . . 23
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23
	12.1. Content-type registration for 'application/pskc+xml' . . . 43		6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25
	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44		6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26
	12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44		6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29
	12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45		6.4. Padding of encrypted values for non-padded encryption
	12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46		algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30
	12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46		7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 48		8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33
	13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 48		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
	13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 49		10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37
	13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 49		10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50		10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51		11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 52		12.1. Content-type registration for 'application/pskc+xml' . . . 46
	16.2. Informative References . . . . . . . . . . . . . . . . . . 52		12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
	Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 54		12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47
	A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 54		12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48
			12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49
			12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49
			13. Security Considerations . . . . . . . . . . . . . . . . . . . 51
			13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 51
			13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 52
			13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 52
			14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
			15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
			16.1. Normative References . . . . . . . . . . . . . . . . . . . 55
			16.2. Informative References . . . . . . . . . . . . . . . . . . 55
			Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57
			A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57
	A.1.1. Transport of keys from Server to Cryptographic		A.1.1. Transport of keys from Server to Cryptographic
	Module . . . . . . . . . . . . . . . . . . . . . . . . 54		Module . . . . . . . . . . . . . . . . . . . . . . . . 57
	A.1.2. Transport of keys from Cryptographic Module to		A.1.2. Transport of keys from Cryptographic Module to
	Cryptographic Module . . . . . . . . . . . . . . . . . 54		Cryptographic Module . . . . . . . . . . . . . . . . . 57
	A.1.3. Transport of keys from Cryptographic Module to		A.1.3. Transport of keys from Cryptographic Module to
	Server . . . . . . . . . . . . . . . . . . . . . . . . 55		Server . . . . . . . . . . . . . . . . . . . . . . . . 58
	A.1.4. Server to server Bulk import/export of keys . . . . . 55		A.1.4. Server to server Bulk import/export of keys . . . . . 58
	A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 55		A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58
	A.2.1. Server to server Bulk import/export of keys . . . . . 55		A.2.1. Server to server Bulk import/export of keys . . . . . 58
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 57		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
	1. Introduction		1. Introduction
	With increasing use of symmetric key based authentication systems,		With increasing use of symmetric key based systems, such as
	such as those based one time password (OTP) and challenge response		encryption of data at rest or systems used for strong authentication
	mechanisms, there is a need for vendor interoperability and a		such as those based on one-time-password (OTP) and challenge response
			(CR) 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, for example vendors of authentication servers
	providers have used proprietary formats for importing and exporting		and service providers have used proprietary formats for importing and
	these keys into their systems making it hard to use tokens from		exporting these keys into their systems, thus making it hard to use
	vendor "Foo" with a server from vendor "Bar".		tokens from vendor "Foo" with a server from vendor "Bar".
	This document proposes a standardized XML-based key container, called		This document defines a standardized XML-based key container, called
	Portable Symmetric Key Container (PSKC), for transporting symmetric		Portable Symmetric Key Container (PSKC), for transporting symmetric
	keys and meta data. This document also specifies the information		keys and key related meta data. The document also specifies the
	elements that are required for computing the initial event counter		information elements that may be required when the symmetric key is
	used by the MAC-Based One Time Password Algorithm (HOTP) algorithm		utilized for specific purposes, such as the initial counter in the
	[HOTP] and these elements are also applicable for other time-based		MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also
	algorithms.		requests the creation of a IANA registry for algorithm profiles where
			algorithms, their related meta-data and PSKC transmission profile can
			be recorded for centralised standardised reference.
	2. Terminology		1.1. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
			1.2. Versions
			There is a provision made in the syntax for an explicit version
			number. Only version "1.0" is currently specified.
			1.3. Namespace Identifiers
			This document uses Uniform Resource Identifiers [RFC2396] to identify
			resources, algorithms, and semantics..
			1.3.1. Defined Identifiers
			The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
			xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
			References to qualified elements in the PSKC schema defined herein
			use the prefix "pskc".
			1.3.2. Referenced Identifiers
			The PSKC syntax presented in this document relies on algorithm
			identifiers and elements defined in the XML Signature [XMLDSIG]
			namespace:
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			References to the XML Signature namespace are represented by the
			prefix "ds".
			PSKC also relies on algorithm identifiers and elements defined in the
			XML Encryption [XMLENC] namespace:
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
			References to the XML Encryption namespace are represented by the
			prefix "xenc".
			When protecting keys in transport with passphrase-based keys, PSKC
			also relies on the derived key element defined in the W3C Derived Key
			[W3C-DKEY] namespace:
			xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
			References to the W3C Derived Key namespace are represented by the
			prefix "dkey".
			When protecting keys in transport with passphrase-based keys, PSKC
			also relies on algorithm identifiers and elements defined in the
			PKCS#5 [PKCS5] namespace:
			xmlns:pkcs5=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
			References to the PKCS#5 namespace are represented by the prefix
			"pkcs5".
			2. Terminology
	NOTE: In subsequent sections of the document we highlight		NOTE: In subsequent sections of the document we highlight
	**mandatory** XML elements and attributes. Optional elements and		**mandatory** XML elements and attributes. Optional elements and
	attributes are not explicitly indicated, i.e., if it does not say		attributes are not explicitly indicated, i.e., if it does not say
	mandatory it is optional.		mandatory it is optional.
	3. Portable Key Container Entities Overview and Relationships		3. Portable Key Container Entities Overview and Relationships
	The portable key container is based on an XML schema definition and		The portable key container is based on an XML schema definition and
	contains the following main conceptual entities:		contains the following main conceptual entities:
	1. KeyContainer entity - representing the container that carries the		1. KeyContainer entity - representing the container that carries a
	keys		number of KeyPackages
	2. Device entity - representing a physical or virtual device where		2. KeyPackage entity - representing the package of upmost one key
	the keys reside optionally bound to a specific user		and its related provisioning endpoint or current usage endpoint,
			such as a physical or virtual device and a specific CryptoModule
	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. CryptoModuleInfo entity - representing the information about the
			CryptoModule where the keys reside or are provisioned to
	5. KeyData entity - representing data related to the key including		5. Key entity - representing the key transported or provisioned
	value either in plain or encrypted
			6. Data entity - representing a list of meta-data related to the
			key, where the element name is the name of the meta-data and its
			associated value is either in encrypted form (for example for
			Data element 'SECRET') or plaintext (for example for the Data
			element 'COUNTER')
	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 |		| KeyPackage | 0..1| DeviceInfo |
	+--------------+-----+--------------+		|--------------|--------|--------------|
	| User | | SerialNumber |		| |-- | SerialNumber |
	+--------------+ | Manufacturer |		---------------- | | Manufacturer |
	| | .... |		| | | .... |
	| +--------------+		| | ----------------
	/|\ 1..n		/|\ 0..1 |
	+--------------+		---------------- | --------------------
	| Key |		| Key | | 0..1| CryptoModuleInfo |
	+--------------+		|--------------| -----|------------------|
	| ID |		| Id | | Id |
	| Algorithm |		| Algorithm | |.... |
	| User |		| UserId | --------------------
			| Policy |
	| .... |		| .... |
	+--------------+		----------------
	|		|
	|		|
	/|\ 1..n +------------+		/|\ 0..n
	+--------------+ | Plainvalue |		--------------------------------------- - -
	| KeyData | +----+-------+		| | |
	+--------------+ |		------------------ ---------------- -------- - -
	| name | either|		| Data:Secret | | Data:Counter | | Data:other
	| value +----------+		|----------------| |--------------| |-- - -
	| ..... | +------+---------+		| EncryptedValue | | PlainValue |
	+--------------+ | EncryptedValue |		| ValueMAC | ----------------
	+----------------+		------------------
	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 its most basic form, a PSKC document uses the top-level element
	<KeyContainer> and a single <Device> element to carry key		<KeyContainer> and a single <KeyPackage> 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 its
	child elements.		child elements.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0" id="exampleID1"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		Id="exampleID1"
	<Device>		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<DeviceInfo>		<KeyPackage>
	<Manufacturer>Manufacturer</Manufacturer>		<Key Id="12345678"
	<SerialNo>987654321</SerialNo>		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
	</DeviceInfo>		<Issuer>Issuer-A</Issuer>
	<Key KeyId="12345678"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>
	<Usage>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		<PlainValue>MTIzNA==
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>
	<PlainValue>0</PlainValue>
	</Counter>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</KeyPackage>
	</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:		semantics:
	'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.0") 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.		in cases when multiple containers are embedded in larger xml
			documents.
	A <KeyContainer> element MUST contain at least one <Device> element.
	Multiple <Device> elements can be used when for bulk provisioning,
	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
	<Device> element.
	4.1. <DeviceInfo> Element: Unique Device Identification
	The <DeviceInfo> element uniquely identifies the device the <Key>
	element refers to. Since devices can come in different form factors,
	such as hardware tokens, smart-cards, soft tokens in a mobile phone
	or as a PC, this element allows different criteria to be used.
	Combined though the criteria MUST uniquely identify the device. For
	example, for hardware tokens the combination of <SerialNo> and
	<Manufacturer> elements uniquely identifies a device but the
	<SerialNo> element alone is insufficient since two different token
	manufacturers might issue devices with the same serial number
	(similar to the Issuer Distinguished Name and serial number of a
	certificate).
	The <DeviceInfo> element has the following child elements:
	<Manufacturer>: This element indicates the manufacturer 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-
	button-HOTP-token-V1).
	<IssueNo>: This element contains the issue number in case devices
	with the same serial number that are distinguished by different
	issue numbers.
	<DeviceBinding>: In a number of cases access to lower layer device
	identifiers, such as a serial number, from a PSKC implementation
	is difficult or not possible. For this purpose an opaque
	identifier, carried in the <DeviceBinding> element, is introduced
	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
	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
	be expressed in UTC form with no timezone component.
	Implementations SHOULD NOT rely on time resolution finer than
	milliseconds and MUST NOT generate time instants that specify leap
	seconds.
	Depending on the device type certain child elements of the
	<DeviceInfo> element are necessary to include in order to uniquely
	identify a device. This document does not enumerate the different
	device types and therefore does not list the elements that are
	mandatory for each type of device.
	4.2. <Key>: Embedding Keying Material		4.1. <Key>: Embedding Keying Material and Key Related Information
	The following attributes of the <Key> element MUST be included at a		The following attributes of the <Key> element MUST be included at a
	minimum:		minimum:
	'KeyId': This attribute carries a globally unique identifier for the		'Id': This attribute carries a globally unique identifier for the
	symmetric key. The identifier is defined as a string of		symmetric key. The identifier is defined as a string of
	alphanumeric characters.		alphanumeric characters.
	'KeyAlgorithm': This attribute contains a unique identifier for the		'Algorithm': This attribute contains a unique identifier for the
	PSKC algorithm profile. This profile associates a specific		PSKC algorithm profile. This profile associates specific
	semantic to the elements and attributes contained in the <Key>		semantics to the elements and attributes contained in the <Key>
	element. More information about the PSKC algorithm profile		element. This document describes profiles for open standards
	defined in this document can be found in Section 10.		algorithms in Section 10. Additional profiles are defined in the
			following information draft [PSKC-ALGORITHM-PROFILES]
	The <Key> element has a number of optional child elements. An		The <Key> element has a number of optional child elements. An
	initial set is described below:		initial set is described below:
	<Issuer>: This element represents the name of the party that issued		<Issuer>: This element represents the name of the party that issued
	the key. For example, a bank "Foobar Bank Inc." issuing hardware		the key. For example, a bank "Foobar Bank Inc." issuing hardware
	tokens to their retail banking users may set this element to		tokens to their retail banking users may set this element to
	"Foobar Bank Inc.".		"Foobar Bank Inc.".
	<FriendlyName>: A human readable name for the secret key for easier		<FriendlyName>: A human readable name for the secret key for easier
	reference. This element serves informational purposes only.		reference. This element serves informational purposes only.
	<Usage>: This element provides supplementary information for usage		<AlgorithmParameters>: This element carries parameters that
	with OTP and CR algorithms. A more detailed discussion of the		influence the result of the algorithmic computation, for example
	element can be found in Section 4.4.		response truncation and format in OTP and CR algorithms. A more
			detailed discussion of the element can be found in Section 4.2.4.
	<Data>: This element carries data about and related to the key. The		<Data>: This element carries data about and related to the key. The
	follow child elements are defined for the <Data> element:		following child elements are defined for the <Data> element:
	<Secret>: This element carries the value of the key itself in a		<Secret>: This element carries the value of the key itself in a
	binary representation.		binary representation.
	<Counter>: This element contains the event counter for event		<Counter>: This element contains the event counter for event
	based OTP algorithms.		based OTP algorithms.
	<Time>: This element contains the time for time based OTP		<Time>: This element contains the time for time based OTP
	algorithms. (If time interval is used, this element carries		algorithms. (If time interval is used, this element carries
	the number of time intervals passed from a specific start		the number of time intervals passed from a specific start
	point, normally algorithm dependent)		point, normally algorithm dependent)
	<TimeInterval>: This element carries the time interval value for		<TimeInterval>: This element carries the time interval value for
	time based OTP algorithms.		time based OTP algorithms.
	<TimeDrift>: This element contains the device clock drift value		<TimeDrift>: This element contains the device clock drift value
	for time based OTP algorithms. The value indicates number of		for time-based OTP algorithms. The value indicates the number
	seconds that the device clock may drift each day.		of seconds that the device clock may drift each day.
	All these elements listed above (and those defined in the future)		All the elements listed above (and those defined in the future)
	obey a simple structure in that they MUST support child elements		obey a simple structure in that they MUST support child elements
	to convey the content in plaintext and in encrypted format:		to convey the data value in either plaintext or encrypted format:
	Plain Text: The <PlainValue> element carries plaintext content		Plaintext: The <PlainValue> element carries plaintext value that
	that is typed, for example to xs:integer.		is typed, for example to xs:integer.
	Encrypted Content: The <EncryptedValue> element carries encrypted		Encrypted: The <EncryptedValue> element carries encrypted value
	content.
	Additionally, a <ValueMac> element, which is populated with a MAC		Additionally, it MUST be possible to carry a <ValueMac> element,
	generated from the unencrypted value in case the encryption		which is populated with a MAC generated from the encrypted value
	algorithm does not support integrity checks, MAY be included as a		in case the encryption algorithm does not support integrity
	child element. The example shown at Figure 2 illustrates the		checks, as a child element. The example shown at Figure 2
	usage of the <Data> element with two child elements, namely		illustrates the usage of the <Data> element with two child
	<Secret> and <Counter>. Both elements carry plaintext value		elements, namely <Secret> and <Counter>. Both elements carry
	within the <PlainValue> child element.		plaintext value within the <PlainValue> child element.
	4.3. <User> Element: User Identification		4.2. Transmission of supplementary Information
	The <User> element identifies the user of the device using a		A PSKC document can contain a number of additional information
	distinguished name, as defined in [RFC4514]. For example:		regarding device identification, cryptomodule identification, user
	UID=jsmith,DC=example,DC=net		identification and parameters for usage with OTP and CR algorithms.
			The following example, see Figure 3, is used as a reference for the
			subsequent sub-sections.
	There is no semantic associated with this element, i.e., there are no		<?xml version="1.0" encoding="UTF-8"?>
	checks enforcing that only a specific user can use this key. As		<KeyContainer Version="1.0"
	such, this element is for informational purposes only.		Id="exampleID1"
			xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
			<KeyPackage>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654321</SerialNo>
			<UserId>DC=example-bank,DC=net</UserId>
			</DeviceInfo>
			<CryptoModuleInfo>
			<Id>CM_ID_001</Id>
			</CryptoModuleInfo>
			<Key Id="12345678"
			Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
			<Issuer>Issuer</Issuer>
			<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
			<AlgorithmParameters>
			<ResponseFormat Length="8" Encoding="DECIMAL"/>
			</AlgorithmParameters>
			<Data>
			<Secret>
			<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
			</PlainValue>
			</Secret>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
			</Data>
			</Key>
			</KeyPackage>
			</KeyContainer>
	4.4. <Usage> Element: Supplementary Information for OTP and CR		Figure 3: PSKC Key Container Example with Supplementary Data
	Algorithms
	The <Usage> element is a child element of the <Key> element and this		4.2.1. <DeviceInfo> Element: Unique Device Identification
	document defines two child elements: <ChallengeFormat> and
	<ResponseFormat>		The <DeviceInfo> element uniquely identifies the device the
			<KeyPackage> is provisioned to. Since devices can come in different
			form factors, such as hardware tokens, smart-cards, soft tokens in a
			mobile phone or as a PC, this element allows different child element
			combinations to be used. When combined, the values of the child
			elements MUST uniquely identify the device. For example, for
			hardware tokens the combination of <SerialNo> and <Manufacturer>
			elements uniquely identifies a device but the <SerialNo> element
			alone is insufficient since two different token manufacturers might
			issue devices with the same serial number (similar to the Issuer
			Distinguished Name and serial number of a certificate).
			The <DeviceInfo> element has the following child elements:
			<Manufacturer>: This element indicates the manufacturer 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-
			button-HOTP-token-V1).
			<IssueNo>: This element contains the issue number in case devices
			with the same serial number that are distinguished by different
			issue numbers.
			<DeviceBinding>: In a number of cases access to lower layer device
			identifiers, such as a serial number, from a PSKC implementation
			is difficult or impossible. For this purpose an opaque
			identifier, carried in the <DeviceBinding> element, is introduced
			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 indicate the 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 be
			expressed in UTC form with no timezone component. Implementations
			SHOULD NOT rely on time resolution finer than milliseconds and
			MUST NOT generate time instants that specify leap seconds.
			Depending on the device type certain child elements of the
			<DeviceInfo> element MUST be included in order to uniquely identify a
			device. This document does not enumerate the different device types
			and therefore does not list the elements that are mandatory for each
			type of device.
			4.2.2. <CryptoModuleInfo> Element: CryptoModule Identification
			The <CryptoModuleInfo> element identifies the cryptographic module to
			which the symmetric keys are or have been provisioned to. This
			allows the identification of the specific cases where a device MAY
			contain more than one crypto module (e.g. a PC hosting a TPM and a
			connected token)
			The <CryptoModuleInfo> element has a single mandatory child element:
			<Id>: This element carries a unique identifier for the CryptoModule
			and is implementation specific. As such, it helps to identify a
			specific CryptoModule to which the key is being or was
			proivisioned.
			4.2.3. <UserId> Element: User Identification
			The <UserId> element identifies the user using a distinguished name,
			as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net
			Although the syntax of the user identifier is defined there are no
			semantics associated with this element, i.e., there are no checks
			enforcing that only a specific user can use this key. As such, this
			element is for informational purposes only.
			This element may appear in two places, namely as a child element of
			the <Key> element where it indicates the user with whom the key is
			associated with and as a child element of the <DeviceInfo> element
			where it indicates that the entity the device belongs to.
			4.2.4. <AlgorithmParameters> Element: Supplementary Information for OTP
			and CR Algorithms
			The <AlgorithmParameters> element is a child element of the <Key>
			element and this document defines two child elements:
			<ChallengeFormat> and <ResponseFormat>
	<ChallengeFormat>:		<ChallengeFormat>:
	The <ChallengeFormat> element defines the characteristics of the		The <ChallengeFormat> element defines the characteristics of the
	challenge in a CR usage scenario whereby the following attributes		challenge in a CR usage scenario whereby the following attributes
	are defined:		are defined:
	'Encoding': This mandatory attribute defines the encoding of the		'Encoding': This mandatory attribute defines the encoding of the
	challenge accepted by the device and MUST be one of the		challenge accepted by the device and MUST be one of the
	following values:		following values:
	skipping to change at page 12, line 29 ¶		skipping to change at page 15, line 4 ¶
	challenge accepted by the device and MUST be one of the		challenge accepted by the device and MUST be one of the
	following values:		following values:
	DECIMAL Only numerical digits		DECIMAL Only numerical digits
	HEXADECIMAL Hexadecimal response		HEXADECIMAL Hexadecimal response
	ALPHANUMERIC All letters and numbers (case sensitive)		ALPHANUMERIC All letters and numbers (case sensitive)
	BASE64 Base 64 encoded		BASE64 Base 64 encoded
	BINARY Binary data		BINARY Binary data
	'CheckDigit': This optional attribute indicates whether a device		'CheckDigit': This optional attribute indicates whether a device
	needs to check the appended Luhn check digit, as defined in		needs to check the appended Luhn check digit, as defined in
	[LUHN], contained in a provided challenge. This is only valid		[LUHN], contained in a challenge. This is only valid if the
	if the 'Encoding' attribute is 'DECIMAL'. A value of TRUE		'Encoding' attribute is 'DECIMAL'. A value of TRUE indicates
	indicates that the device will check the appended Luhn check		that the device will check the appended Luhn check digit in a
	digit in a provided challenge. A value of indicates that the		provided challenge. A value of FALSE indicates that the device
	device will not check appended Luhn check digit in challenge.		will not check the appended Luhn check digit in the challenge.
	'Min': This mandatory attribute defines the minimum size of the		'Min': This mandatory attribute defines the minimum size of the
	challenge accepted by the device for CR mode. If the		challenge accepted by the device for CR mode. If the
	'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or		'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
	'ALPHANUMERIC' this value indicates the minimum number of		'ALPHANUMERIC' this value indicates the minimum number of
	digits/characters. If the 'Encoding' attribute is 'BASE64' or		digits/characters. If the 'Encoding' attribute is 'BASE64' or
	'BINARY', this value indicates the minimum number of bytes of		'BINARY', this value indicates the minimum number of bytes of
	the unencoded value.		the unencoded value.
	'Max': This mandatory attribute defines the maximum size of the		'Max': This mandatory attribute defines the maximum size of the
	skipping to change at page 13, line 26 ¶		skipping to change at page 15, line 49 ¶
	'Encoding': This mandatory attribute defines the encoding of the		'Encoding': This mandatory attribute defines the encoding of the
	response generated by the device and MUST be one of the		response generated by the device and MUST be one of the
	following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,		following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,
	or BINARY.		or BINARY.
	'CheckDigit': This optional attribute indicates whether the		'CheckDigit': This optional attribute indicates whether the
	device needs to append a Luhn check digit, as defined in		device needs to append a Luhn check digit, as defined in
	[LUHN], to the response. This is only valid if the 'Encoding'		[LUHN], to the response. This is only valid if the 'Encoding'
	attribute is 'DECIMAL'. If the value is TRUE then the device		attribute is 'DECIMAL'. If the value is TRUE then the device
	will append a Luhn check digit to the response. If the value		will append a Luhn check digit to the response. If the value
	is FALSE then the device will not append a Luhn check digit to		is FALSE, then the device will not append a Luhn check digit to
	the response.		the response.
	'Length': This mandatory attribute defines the length of the		'Length': This mandatory attribute defines the length of the
	response generated by the device. If the 'Encoding' attribute		response generated by the device. If the 'Encoding' attribute
	is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value		is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
	indicates the number of digits/characters. If the 'Encoding'		indicates the number of digits/characters. If the 'Encoding'
	attribute is 'BASE64' or 'BINARY', this value indicates the		attribute is 'BASE64' or 'BINARY', this value indicates the
	number of bytes of the unencoded value.		number of bytes of the unencoded value.
	5. Policy		4.3. Transmission of Key Derivation Values
			<KeyProfileId> element, which is a child element of the <Key>
			element, carries a unique identifier used between the sending and
			receiving parties to establish a set of key attribute values that are
			not transmitted within the container but agreed between the two
			parties out of band. This element will then represent the unique
			reference to a set of key attribute values. (For example, a smart
			card application personalisation profile id related to attributes
			present on a smart card application that have influence when
			computing a response.) Likewise, the sending and receiving parties,
			might agree to a set of values related to the MasterCard's Chip
			Authentication Protocol [CAP].
			For example, sending and receiving party would agree that
			KeyProfileId='1' would represent a certain set of values (e.g.,
			Internet authentication flag set to a specific value). When sending
			keys these values would not be transmitted as key attributes but only
			referred to via the <KeyProfileId> element set to the specific agreed
			profile (in this case '1'). When the receiving party receives the
			keys it can then associate all relevant key attributes contained in
			the out of band agreed profile with the imported keys. Often this
			methodology is used between the manufacturing and the validation
			service to avoid repeated transmission of the same set of values.
			The <KeyReference> element contains a reference to an external key to
			be used with a key derivation scheme and no specific key is
			transported but only the reference to the external key is used (e.g.,
			the PKCS#11 key label).
			<?xml version="1.0" encoding="UTF-8"?>
			<KeyContainer Version="1.0" id="exampleID1"
			xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
			<KeyPackage>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654321</SerialNo>
			</DeviceInfo>
			<CryptoModuleInfo>
			<Id>CM_ID_001</Id>
			</CryptoModuleInfo>
			<Key Id="12345678"
			Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
			<Issuer>Issuer</Issuer>
			<AlgorithmParameters>
			<ResponseFormat Length="8" Encoding="DECIMAL"/>
			</AlgorithmParameters>
			<KeyProfileId>keyProfile1</KeyProfileId>
			<Data>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
			</Data>
			<Policy>
			<KeyUsage>OTP</KeyUsage>
			</Policy>
			</Key>
			</KeyPackage>
			</KeyContainer>
			Figure 4: Example of a PSKC Document transmitting a HOTP key via key
			derivation values
			The key value will be derived using the value of the <SerialNumber>
			element and an external key identified by the label 'MasterKeyLabel'.
			5. Key policy - transmission of key usage policies and key PIN
			protection policy
	This section illustrates the functionality of the <Policy> element		This section illustrates the functionality of the <Policy> element
	within PSKC that allows policy to be attached to a key and related		within PSKC that allows policy to be attached to a key and its
	meta data. This element is a child element of the <Key> element.		related meta data. This element is a child element of the <Key>
			element.
	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 extensions 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.0" id="exampleID1"		<KeyContainer
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		Version="1.0" Id="exampleID1"
	<Device>		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
			<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyId="12345678"		<CryptoModuleInfo>
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		<Id>CM_ID_001</Id>
			</CryptoModuleInfo>
			<Key Id="12345678"
			Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<PINPolicy MinLength="4" MaxLength="4"		<PINPolicy MinLength="4" MaxLength="4"
	PINKeyId="123456781" PINEncoding="DECIMAL"		PINKeyId="123456781" PINEncoding="DECIMAL"
	PINUsageMode="Local"/>		PINUsageMode="Local"/>
	<KeyUsage>OTP</KeyUsage>		<KeyUsage>OTP</KeyUsage>
	</Policy>		</Policy>
	</Key>		</Key>
	<Key KeyId="123456781"		</KeyPackage>
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">		<KeyPackage>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654321</SerialNo>
			</DeviceInfo>
			<CryptoModuleInfo>
			<Id>CM_ID_001</Id>
			</CryptoModuleInfo>
			<Key Id="123456781"
			Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="4" Encoding="DECIMAL"/>		<ResponseFormat Length="4" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNA==</PlainValue>		<PlainValue>MTIzNA==</PlainValue>
	</Secret>		</Secret>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 3: Non-Encrypted HOTP Secret Key protected by PIN		Figure 5: Non-Encrypted HOTP Secret Key protected by PIN
	This document defines the following elements:		This document defines the following Policy child elements:
	<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 the current time is assumed
	assumed as a start time.		as the start time.
	<NumberOfTransactions>: The value in this element indicates a		<NumberOfTransactions>: The value in this element indicates the
	restriction regarding the number of times a key carried within the		maximum number of times a key carried within the PSKC document can
	PSKC document can be applied. When this element is omitted then		be used. When this element is omitted then there is no
	there is no restriction regarding the number of times a key is		restriction regarding the number of times a key can be used.
	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.
	Integrity: The key MUST only be used to generate a keyed message		Integrity: The key MUST only be used to generate a keyed message
	digest for data integrity or authentication purposes.		digest for data integrity or authentication purposes.
			Verify: The key MUST only be used to verify a keyed message
			digest for data integrity or authentication purposes. ( is the
			vice versa of Integrity)
	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 where a user has locked the device by
	wrong PIN too many times (for devices with PIN-input		entering a 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.		Unwrap: The key MUST only be used for key unwrap purposes.
	Derive: The key MUST only be used with a key derivation function		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]).		to derive a new key (see also Section 8.2.4 of [NIST800-57]).
	Generate: The key MUST only be used to generate a new key based		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		on a random number and the previous value of the key (see also
	Section 8.1.5.2.1 of[NIST]).		Section 8.1.5.2.1 of[NIST800-57]).
	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:
	skipping to change at page 17, line 41 ¶		skipping to change at page 21, line 29 ¶
	server.		server.
	Append: This value indicates that the PIN is appended to the		Append: This value indicates that the PIN is appended to the
	OTP or response hence it MUST be checked by the validation		OTP or response hence it MUST be checked by the validation
	server.		server.
	Algorithmic: This value indicates that the PIN is used as part		Algorithmic: This value indicates that the PIN is used as part
	of the algorithm computation.		of the algorithm computation.
	'MaxFailedAttempts': This attribute indicates the maximum number		'MaxFailedAttempts': This attribute indicates the maximum number
	of times the PIN can be entered wrongly before it MUST NOT be		of times the PIN may be entered wrongly before it MUST NOT be
	possible to use the key anymore.		possible to use the key anymore.
	'MinLength': This attribute indicates the minimum length of a PIN		'MinLength': This attribute indicates the minimum length of a PIN
	that can be set to protect this key. It MUST NOT be possible		that can be set to protect the associated key. It MUST NOT be
	to set a PIN shorter than this value. If the 'PINFormat'		possible to set a PIN shorter than this value. If the
	attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this		'PINFormat' attribute is 'DECIMAL', 'HEXADECIMAL' or
	value indicates the number of digits/characters. If the		'ALPHANUMERIC' this value indicates the number of digits/
	'PINFormat' attribute is 'BASE64' or 'BINARY', this value		characters. If the 'PINFormat' attribute is 'BASE64' or
	indicates the number of bytes of the unencoded value.		'BINARY', this value indicates the number of bytes of the
			unencoded value.
	'MaxLength': This attribute indicates the maximum lenght of a PIN		'MaxLength': This attribute indicates the maximum lenght of a PIN
	that can be set to protect this key. It MUST NOT be possible		that can be set to protect this key. It MUST NOT be possible
	to set a PIN longer than this value. If the 'PINFormat'		to set a PIN longer than this value. If the 'PINFormat'
	attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this		attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
	value indicates the number of digits/characters. If the		value indicates the number of digits/characters. If the
	'PINFormat' attribute is 'BASE64' or 'BINARY', this value		'PINFormat' attribute is 'BASE64' or 'BINARY', this value
	indicates the number of bytes of the unencoded value.		indicates the number of bytes of the unencoded value.
	'PINEncoding': This attribute indicates the encoding of the PIN		'PINEncoding': This attribute indicates the encoding of the PIN
	and MUST be one of the values: DECIMAL, HEXADECIMAL,		and MUST be one of the values: DECIMAL, HEXADECIMAL,
	ALPHANUMERIC, BASE64, or BINARY.		ALPHANUMERIC, BASE64, or BINARY.
	If the 'PinUsageMode' attribute is set to "Local" then the device		If the 'PinUsageMode' attribute is set to "Local" then the device
	MUST enforce the restriction indicated in the 'MaxFailedAttempts',		MUST enforce the restriction indicated in the 'MaxFailedAttempts',
	'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it		'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it
	MUST be enforced on the server side.		MUST be enforced on the server side.
	6. Protection of Keys and Related Data		6. Key protection methods
	With the functionality described in the previous sections information		With the functionality described in the previous sections,
	related to keys had to be transmitted in clear text. With the help		information related to keys had to be transmitted in clear text.
	of the <EncryptionKey> element, which is a child element of the		With the help of the <EncryptionKey> element, which is a child
	<KeyContainer> element, it is possible to encrypt keys and associated		element of the <KeyContainer> element, it is possible to encrypt keys
	information. The level of encryption is applied to the value of		and associated information. The level of encryption is applied to
	individual elements and the applied encryption algorithm MUST be the		the value of individual elements and the applied encryption algorithm
	same for elements. Key encryption is supported based on the		MUST be the same for all encrypted elements. Keys are protected
	following credentials: pre-shared keys, passphrase-based keys, and		using the following methods: pre-shared keys, passphrase-based keys,
	asymmetric keys		and asymmetric keys.
	6.1. Encryption based on Pre-Shared Keys		6.1. Encryption based on Pre-Shared Keys
	Figure 4 shows an example that illustrates the encryption of the		Figure 6 shows an example that illustrates the encryption of the
	content of the <Secret> element using AES128-CBC, the plaintext value		content of the <Secret> element using AES128-CBC and PKCS5 Padding.
	of <Secret> is '3132333435363738393031323334353637383930'. The name		The plaintext value of <Secret> is
	of the pre-shared secret is "Example-Key1", as set in the <KeyName>		'3132333435363738393031323334353637383930'. The name of the pre-
	element (which is a child element of the <EncryptionKey> element).		shared secret is "Example-Key1", as set in the <KeyName> element
	The value of the key used is '12345678901234567890123456789012'.		(which is a child element of the <EncryptionKey> element). The value
			of the encryption 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 a MAC key and a MAC algorithm as
	<MACAlgorithm> element (in our example		declared in the <MACMethod> 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 use as the algorithm
	of the keyed MAC computation is placed in the <ValueMAC> element.		and the value of the MAC key is randomly generated, in our case
			'1122334455667788990011223344556677889900', and encrypted with the
			above encryption key.) The result of the keyed MAC computation is
			placed in the <ValueMAC> child element of <Secret>.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		<KeyContainer Version="1.0"
	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:ds="http://www.w3.org/2000/09/xmldsig#"
			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		<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
	</MACAlgorithm>		<MACKey>
	<Device>		<xenc:EncryptionMethod
			Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
			<xenc:CipherData>
			<xenc:CipherValue>
			R8+5I6m74doa0nRhaPejbt3elq9hLPGvxHgXVlYpbgA=
			</xenc:CipherValue>
			</xenc:CipherData>
			</MACKey>
			</MACMethod>
			<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyId="12345678"		<CryptoModuleInfo>
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		<Id>CM_ID_001</Id>
			</CryptoModuleInfo>
			<Key Id="12345678"
			Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<EncryptedValue>		<EncryptedValue>
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm=		Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
	"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
	<xenc:CipherData>		<xenc:CipherData>
	<xenc:CipherValue>		<xenc:CipherValue>
	pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=		pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
	</xenc:CipherValue>		</xenc:CipherValue>
	</xenc:CipherData>		</xenc:CipherData>
	</EncryptedValue>		</EncryptedValue>
	<ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=		<ValueMAC>ooo0Swn6s/myD4o05FCfBHN0560=</ValueMAC>
	</ValueMAC>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 4: AES-128-CBC Encrypted Pre-Shared Secret Key		Figure 6: 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. When the encryption method uses
			a CBC mode that requires an explicit initialization vector (IV), the
			IV MUST be passed by prepending it to the encrypted value.
	For systems implementing PSKC it is RECOMMENDED to support AES-128-		For systems implementing PSKC it is RECOMMENDED to support AES-128-
	CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and		CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and
	KW-AES128 (with the URI of		KW-AES128 (with the URI of
	http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-		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		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		bytes in length. Hence, if keys of a different length have to be
	then the usage of the key wrap algorithm with padding, as described		protected then the usage of the key wrap algorithm with padding, as
	in [I-D.housley-aes-key-wrap-with-pad] is RECOMMENDED. An example		described in [AESKWPAD] is RECOMMENDED. Some of the encryption
	list of optionally-to-implement encryption algorithms can be found		algorithms that can optionally be implemented are:
	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
			6.1.1. MAC Method
	When algorithms without integrity checks are used, such as AES-128-		When algorithms without integrity checks are used, such as AES-128-
	CBC, a keyed MAC value using the same key as the key encryption key		CBC, a keyed MAC value MUST be placed in the <ValueMAC> element of
	MUST be placed in the <ValueMAC> element of the <Data> element. In		the <Data> element. In this case the MAC algorithm type MUST be set
	this case the MAC algorithm type MUST be set in the <MACAlgorithm>		in the <MACMethod> element of the <KeyContainer> element. The MAC
	element of the <KeyContainer> element. Implementations of PSKC MUST		key MUST be a randomly generated key by the sender, a pre-shared one
	support HMAC-SHA1 (with the URI of		between the receiver and the sender, or one set by an application
			protocol that uses KeyContainer. It is recommended that a sender
			generates a random MAC key. When the sender generates such a random
			MAC key, the MAC key material MUST be encrypted with the same
			encryption key specified in <EncryptionKey> element of the key
			container. The encryption method and encrypted value MUST be set
			respectively in the <EncryptionMethod> element and the <CipherData>
			element of the <MACKey> element in the <MACMethod> element. The
			<MACKeyReference> element of the <MACMethod> element MAY be used to
			indicate a pre-shared MAC key or a provisioning protocol derived MAC
			key. Implementations of PSKC MUST 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. Some of the MAC algorithms that can
	MAC algorithms can be found below:		optionally be implemented are:
	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
	6.2. Encryption based on Passphrase-based Keys		6.2. Encryption based on Passphrase-based Keys
	To be able to support passphrase based key encryption keys as defined		Figure 7 shows an example that illustrates the encryption of the
	in PKCS#5 the following PBE related parameters have been introduced		content of the <Secret> element using passphrase based encryption
	into PSKC. Implementations of PSKC MUST support the PKCS#5		PBES2 as defined in [PKCS5]. When using passphrase based encryption,
	recommended PBKDF2 and PBES2 algorithms. Differing from the PKCS#5		the <DerivedKey> element defined in W3C [W3C-DKEY] MUST be used to
	XML schema definition, the PBKDF2 and PBES2 are specified in two		specify the passphrased-based key. A <DerivedKey> element is set as
	separate elements in a <KeyContainer> element:		the child element of <EncryptionKey> element of the key container.
	(a) PBKDF2 is specified via the <DerivedKey> element, which is a
	child element of the <EncryptionKey> element.
	(b) PBES2 is specified by the 'Algorithm' attribute (with the
	value set to
	http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2) of
	the <EncryptionMethod> element used inside the encrypted data
	elements.
	The attributes of the <DerivedKey> element have the following
	semantic:
	'xml:id': This attribute carries the unique identifier for this key.
	'Type': This attribute was included for conformance with XML
	encryption. It is an optional attribute identifying type
	information about the plaintext form of the encrypted content.
	Please see Section 3.1 of [XMLENC] for more details.
	The elements of the <DerivedKey> element have the following semantic:
	<CarriedKeyName>: This element carries a friendly name of the key.
	<KeyDerivationMethod>: This element defines how key encryption key		The <DerivedKey> element is used to specify the key derivation
	is derived. The 'Algorithm' attribute is used to indicate the key		function and related parameters. The encryption algorithm, namely
	derivation method. When PBKDF2 is used, the URI		PBES2 as specified in [PKCS5] ( URI
	http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 MUST		'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2'), MUST
	be used. When PBKDF2 is used, it MUST include the <PBKDF2-params>		be set in the 'Algorithm' attribute of <EncryptionMethod> element
	child element to indicate the PBKDF2 parameters, such as salt and		used inside the encrypted data elements.
	iteration count.
	<ReferenceList>: This element contains a list of IDs of the elements		When PBKDF2 is used, the attribute "Algorithm" of the element <dkey:
	that have been encrypted by this key.		KeyDerivationMethod> MUST be set to the URI
			'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The
			element <dkey:KeyDerivationMethod> MUST include the <PBKDF2-params>
			child element to indicate the PBKDF2 parameters, such as salt and
			iteration count.
	When PBES2 is used for encryption, the URL		When PBES2 is used for encryption, the URL
	http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 MUST be		'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2' MUST
	specified as the 'Algorithm' attribute of <xenc:EncryptionMethod>		be specified as the 'Algorithm' attribute of <xenc:EncryptionMethod>
	element. The underlying encryption scheme and initialization vector		element. The underlying encryption scheme MUST be expressed in the
	MUST be expressed in the <pskc:EncryptionScheme> element, which is a		<pskc:EncryptionScheme> element, which is a child element of <xenc:
	child element of <xenc:EncryptionMethod>.		EncryptionMethod>.
			When the encryption method uses a CBC mode that uses an explicit
			initialization vector (IV) other than a derived one, the IV MUST be
			passed by prepending it to the encrypted value.
	When PKCS#5 password based encryption is used, the <EncryptionKey>		When PKCS#5 password based encryption is used, the <EncryptionKey>
	element and <xenc:EncryptionMethod> element MUST be used in exactly		element and <xenc:EncryptionMethod> element MUST be used in exactly
	the form as shown in Figure 5.		the form as shown in Figure 7.
	In the example below, the following data is used.		In the example below, the following data is used.
	Password: qwerty		Password: qwerty
	Salt: 0x123eff3c4a72129c		Salt: 0x123eff3c4a72129c
	Iteration Count: 1000		Iteration Count: 1000
			MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
	OTP Secret: 12345678901234567890		OTP Secret: 12345678901234567890
	The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41".		The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41".
	This key is also used to calculate MAC value of the secret key		The initialization vector (IV) is
	"12345678901234567890". The encryption with algorithm "AES-128-CBC"		"0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to
	follows the specification defined in [XMLENC].		encrypt the randomly chosen MAC key. A different IV can be used,
			say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the example. The
	<?xml version="1.0" encoding="UTF-8"?>		encryption with algorithm "AES-128-CBC" follows the specification
	<KeyContainer		defined in [XMLENC].
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:pkcs5=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	Version="1.0">
	<EncryptionKey>
	<DerivedKey>
	<CarriedKeyName>Passphrase1</CarriedKeyName>
	<KeyDerivationMethod
	Algorithm=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
	<pkcs5:PBKDF2-params>
	<pkcs5:Salt>
	<pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified>
	</pkcs5:Salt>
	<pkcs5:IterationCount>1000</pkcs5:IterationCount>
	<pkcs5:KeyLength>16</pkcs5:KeyLength>
	<pkcs5:PRF/>
	</pkcs5:PBKDF2-params>
	</KeyDerivationMethod>
	<xenc:ReferenceList>
	<xenc:DataReference URI="#ED"/>
	</xenc:ReferenceList>
	</DerivedKey>
	</EncryptionKey>
	<Device>
	<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>987654321</SerialNo>
	</DeviceInfo>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
	KeyId="123456">
	<Issuer>Example-Issuer</Issuer>
	<Usage>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>
	<Data>
	<Secret>
	<EncryptedValue Id="ED">
	<xenc:EncryptionMethod Algorithm=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
	<EncryptionScheme Algorithm=
	"http://www.w3.org/2001/04/xmlenc#aes128-cbc">
	</EncryptionScheme>
	</xenc:EncryptionMethod>
	<xenc:CipherData>
	<xenc:CipherValue>
	oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
	</xenc:CipherValue>
	</xenc:CipherData>
	<ns2:ValueMAC>cOpiQ/H7Zlj6ywiYWtwgz9cRaOA=
	</ns2:ValueMAC>
	</EncryptedValue>
	</Secret>
	</Data>
	</Key>
	</Device>
	</KeyContainer>
	Figure 5: Example of a PSKC Document using Encryption based on		<?xml version="1.0" encoding="UTF-8"?>
			<pskc:KeyContainer
			xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
			xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
			xmlns:pkcs5=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
			<pskc:EncryptionKey>
			<dkey:DerivedKey>
			<dkey:KeyDerivationMethod
			Algorithm=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
			<pkcs5:PBKDF2-params>
			<Salt>
			<Specified>Ej7/PEpyEpw=</Specified>
			</Salt>
			<IterationCount>1000</IterationCount>
			<KeyLength>16</KeyLength>
			<PRF/>
			</pkcs5:PBKDF2-params>
			</dkey:KeyDerivationMethod>
			<xenc:ReferenceList>
			<xenc:DataReference URI="#ED"/>
			</xenc:ReferenceList>
			<dkey:MasterKeyName>My Password 1</dkey:MasterKeyName>
			</dkey:DerivedKey>
			</pskc:EncryptionKey>
			<pskc:MACMethod
			Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
			<pskc:MACKey>
			<xenc:EncryptionMethod
			Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
			<xenc:CipherData>
			<xenc:CipherValue>
			2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ
			SWJblA7Dzi031L6FNnUrcjsGGcQ==
			</xenc:CipherValue>
			</xenc:CipherData>
			</pskc:MACKey>
			</pskc:MACMethod>
			<pskc:KeyPackage>
			<pskc:DeviceInfo>
			<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
			<pskc:SerialNo>987654321</pskc:SerialNo>
			</pskc:DeviceInfo>
			<pskc:CryptoModuleInfo>
			<pskc:Id>CM_ID_001</pskc:Id>
			</pskc:CryptoModuleInfo>
			<pskc:Key Algorithm=
			"urn:ietf:params:xml:ns:keyprov:pskc#hotp" Id="123456">
			<pskc:Issuer>Example-Issuer</pskc:Issuer>
			<pskc:AlgorithmParameters>
			<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
			</pskc:AlgorithmParameters>
			<pskc:Data>
			<pskc:Secret>
			<pskc:EncryptedValue Id="ED">
			<xenc:EncryptionMethod
			Algorithm=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
			<pskc:EncryptionScheme
			Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
			</xenc:EncryptionMethod>
			<xenc:CipherData>
			<xenc:CipherValue>
			oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
			</xenc:CipherValue>
			</xenc:CipherData>
			</pskc:EncryptedValue>
			<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
			</pskc:ValueMAC>
			</pskc:Secret>
			</pskc:Data>
			</pskc:Key>
			</pskc:KeyPackage>
			</pskc:KeyContainer>
			Figure 7: Example of a PSKC Document using Encryption based on
	Passphrase-based Keys		Passphrase-based Keys
	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 8 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		<KeyContainer
	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="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#"
	id="KC0001"		id="KC0001"
	Version="1.0">		Version="1.0">
	<EncryptionKey>		<EncryptionKey>
	skipping to change at page 25, line 27 ¶		skipping to change at page 29, line 39 ¶
	GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI		GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
	hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e		hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
	DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ		DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
	xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY		xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
	JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf		JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
	rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w		rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
	4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=		4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
	</ds:X509Certificate>		</ds:X509Certificate>
	</ds:X509Data>		</ds:X509Data>
	</EncryptionKey>		</EncryptionKey>
	<MACAlgorithm>		<KeyPackage>
	http://www.w3.org/2000/09/xmldsig#hmac-sha1
	</MACAlgorithm>
	<Device>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key		<Key
	KeyId="MBK000000001"		Id="MBK000000001"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Example-Issuer</Issuer>		<Issuer>Example-Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="6" Encoding="DECIMAL"/>		<ResponseFormat Length="6" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<EncryptedValue>		<EncryptedValue>
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
	<xenc:CipherData>		<xenc:CipherData>
	<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4		<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
	xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6		xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
	Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=		Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
	</xenc:CipherValue>		</xenc:CipherValue>
	skipping to change at page 26, line 4 ¶		skipping to change at page 30, line 15 ¶
	<Secret>		<Secret>
	<EncryptedValue>		<EncryptedValue>
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
	<xenc:CipherData>		<xenc:CipherData>
	<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4		<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
	xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6		xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
	Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=		Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
	</xenc:CipherValue>		</xenc:CipherValue>
	</xenc:CipherData>		</xenc:CipherData>
	</EncryptedValue>		</EncryptedValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 6: Example of a PSKC Document using Encryption based on		Figure 8: 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 one example of
	optional-to-implement algorithm.		optional implemnted asymmetric key encryption algorithm
	6.4. Transmission of Key Derivation Values
	<KeyProfileId> element, which is a child element of the <Key>
	element, carries a unique identifier used between the sending and
	receiving party to establish a set of key attribute values that are
	not transmitted within the container but agreed between the two
	parties out of band. This element will then represent the unique
	reference to a set of attribute values. For example, a smart card
	application personalisation profile id related to attributes present
	on a smart card application that have influence when computing a
	response. The sending and the receiving party would agree to a set
	of values related to the MasterCard's Chip Authentication Protocol
	(CAP) [CAP].
	For example, sending and receiving party would agree that
	KeyProfileId='1' would represent a certain set of values (e.g.,
	Internet authentication flag set to a specific value). When sending
	keys these values would not be transmitted as key attributes but only
	referred to via the <KeyProfileId> element set to the specific agreed
	profile (in this case '1'). When the receiving party receives the
	keys it can then associate all relevant key attributes contained in
	the out of band agreed profile with the imported keys. Often this
	methodology is used between the manufacturing and the validation
	service to avoid transmission of mainly the same set of values.
	The <KeyReference> element contains a reference to an external key
	when key derivation schemes are used and no specific key is
	transported but only the reference to the external key is used (e.g.,
	the PKCS#11 key label).
	<?xml version="1.0" encoding="UTF-8"?>		6.4. Padding of encrypted values for non-padded encryption algorithms
	<KeyContainer Version="1" id="exampleID1"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<Device>
	<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>
	</DeviceInfo>
	<Key KeyId="12345678"
	KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>
	<Usage>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>
	<KeyProfileId>keyProfile1</KeyProfileId>
	<KeyReference>MasterKeyLabel</KeyReference>
	<Data>
	<Counter>
	<PlainValue>0</PlainValue>
	</Counter>
	</Data>
	<Policy>
	<KeyUsage>OTP</KeyUsage>
	</Policy>
	</Key>
	</Device>
	</KeyContainer>
	The key value will be derived using the serialnumber and an external		The sections above describe the use of different type of algorithms
	key identified by the label 'MasterKeyLabel'.		to protect the transported keys. When algorithms are used that do
			not have embedded padding (for example AES algorithm in CBC mode) and
			the keys transmitted are not og the cypher block length (for example
			a HOTP key that is 20 bytes long enctypted with AES that has an 8
			byte block cypher) padding is required.
	Figure 7: Example of a PSKC Document transmitting a HOTP key via key		PSKC impllementations MUST use PKCS5 padding as described in [PKCS5].
	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].
	<?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=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
	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#"
	Version="1">		Version="1.0">
	<Device>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>0755225266</SerialNo>		<SerialNo>0755225266</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"		<Key Id="123"
	KeyId="123">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Example-Issuer</Issuer>		<Issuer>Example-Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="6" Encoding="DECIMAL"/>		<ResponseFormat Length="6" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</KeyPackage>
	<Signature>		<Signature>
	<ds:SignedInfo>		<ds:SignedInfo>
	<ds:CanonicalizationMethod		<ds:CanonicalizationMethod
	Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>		Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
	<ds:SignatureMethod		<ds:SignatureMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>		Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
	<ds:Reference URI="#Device">		<ds:Reference URI="#Device">
	<ds:DigestMethod		<ds:DigestMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>		Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<ds:DigestValue>		<ds:DigestValue>
	skipping to change at page 29, line 6 ¶		skipping to change at page 32, line 4 ¶
	<ds:CanonicalizationMethod		<ds:CanonicalizationMethod
	Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>		Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
	<ds:SignatureMethod		<ds:SignatureMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>		Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
	<ds:Reference URI="#Device">		<ds:Reference URI="#Device">
	<ds:DigestMethod		<ds:DigestMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>		Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<ds:DigestValue>		<ds:DigestValue>
	j6lwx3rvEPO0vKtMup4NbeVu8nk=		j6lwx3rvEPO0vKtMup4NbeVu8nk=
	</ds:DigestValue>		</ds:DigestValue>
	</ds:Reference>		</ds:Reference>
	</ds:SignedInfo>		</ds:SignedInfo>
	<ds:SignatureValue>		<ds:SignatureValue>
	j6lwx3rvEPO0vKtMup4NbeVu8nk=		j6lwx3rvEPO0vKtMup4NbeVu8nk=
	</ds:SignatureValue>		</ds:SignatureValue>
	<ds:KeyInfo>		<ds:KeyInfo>
	<ds:X509Data>		<ds:X509Data>
	<ds:X509IssuerSerial>		<ds:X509IssuerSerial>
	<ds:X509IssuerName>		<ds:X509IssuerName>
	CN=Example.com,C=US		CN=Example.com,C=US
	</ds:X509IssuerName>		</ds:X509IssuerName>
	<ds:X509SerialNumber>		<ds:X509SerialNumber>
	12345678		12345678
	</ds:X509SerialNumber>		</ds:X509SerialNumber>
	</ds:X509IssuerSerial>		</ds:X509IssuerSerial>
	</ds:X509Data>		</ds:X509Data>
	</ds:KeyInfo>		</ds:KeyInfo>
	</Signature>		</Signature>
	</KeyContainer>		</KeyContainer>
	Figure 8: Digital Signature Example		Figure 9: Digital Signature Example
	8. Bulk Provisioning		8. Bulk Provisioning
	The functionality of bulk provisioning can be accomplished by		The functionality of bulk provisioning can be accomplished by
	repeating the <Device> element multiple times within the		repeating the <KeyPackage> element multiple times within the
	<KeyContainer> element indicating that multiple keys are provided to		<KeyContainer> element indicating that multiple keys are provided to
	different devices. The <EncryptionKey> element then applies to all		different devices or cryptomodules. The <EncryptionKey> element then
	<Device> elements. Furthermore, within a single <Device> element the		applies to all <KeyPackage> elements. When provisioning multiple
	<Key> element may also be repeated providing different keys and meta		keys to the same device the <KeyPackage> element is repeated but the
	data for a single device.		enclosed <DeviceInfo> element will contain the same sub elements that
			uniquely identify the single device.
	Figure 9 shows an example utilizing these capabilities.		Figure 10 shows an example utilizing these capabilities.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<Device>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>654321</SerialNo>		<SerialNo>654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"		<Key Id="1"
	KeyId="1">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<StartDate>2006-05-01T00:00:00Z</StartDate>		<StartDate>2006-05-01T00:00:00Z</StartDate>
	<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	</Device>		</KeyPackage>
	<Device>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>123456</SerialNo>		<SerialNo>123456</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"		<Key Id="2"
	KeyId="2">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<StartDate>2006-05-01T00:00:00Z</StartDate>		<StartDate>2006-05-01T00:00:00Z</StartDate>
	<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	</Device>		</KeyPackage>
	<Device>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>9999999</SerialNo>		<SerialNo>9999999</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"		<Key Id="3"
	KeyId="3">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	skipping to change at page 31, line 51 ¶		skipping to change at page 35, line 4 ¶
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<StartDate>2006-03-01T00:00:00Z</StartDate>		<StartDate>2006-03-01T00:00:00Z</StartDate>
	<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"		<Key Id="4"
	KeyId="4">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</Usage>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<StartDate>2006-04-01T00:00:00Z</StartDate>		<StartDate>2006-04-01T00:00:00Z</StartDate>
	<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	</Device>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 9: Bulk Provisioning Example		Figure 10: Bulk Provisioning Example
	9. Extensibility		9. Extensibility
	This section lists a few common extension points provided by PSKC:		This section lists a few common extension points provided by PSKC:
	New PSKC Version: Whenever it is necessary to define a new version		New PSKC Version: Whenever it is necessary to define a new version
	of this document then a new version number has to be allocated to		of this document then a new version number has to be allocated to
	refer to the new specification version. The version number is		refer to the new specification version. The version number is
	carried inside the 'Algorithm' attribute, as described in		carried inside the 'Algorithm' attribute, as described in
	Section 4, and rules for extensibililty are defined in Section 12.		Section 4, and rules for extensibililty are defined in Section 12.
	skipping to change at page 33, line 28 ¶		skipping to change at page 36, line 28 ¶
	offered. In some places the <Extensions> element can be used and		offered. In some places the <Extensions> element can be used and
	elsewhere the "<xs:any namespace="##other" processContents="lax"		elsewhere the "<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>" XML extension point is		minOccurs="0" maxOccurs="unbounded"/>" XML extension point is
	utilized.		utilized.
	New XML Attributes: The XML schema allows new XML attributes to be		New XML Attributes: The XML schema allows new XML attributes to be
	added where XML extension points have been defined (see "<xs:		added where XML extension points have been defined (see "<xs:
	anyAttribute namespace="##other"/>" in Section 11).		anyAttribute namespace="##other"/>" in Section 11).
	New PSKC Algorithm Profiles: This document defines two PSKC		New PSKC Algorithm Profiles: This document defines two PSKC
	algorithm profiles, see Section 10. Further PSKC algorithm		algorithm profiles, see Section 10. The following informational
	profiles can be registered as described in Section 12.4.		draft describes additional profiles [PSKC-ALGORITHM-PROFILES].
			Further PSKC algorithm profiles can be registered as described in
			Section 12.4.
	Algorithm URIs: Section 6 defines how keys and related data can be		Algorithm URIs: Section 6 defines how keys and related data can be
	protected. A number of algorithms can be used. The usage of new		protected. A number of algorithms can be used. The usage of new
	algorithms can be used by pointing to a new algorithm URI.		algorithms can be used by pointing to a new algorithm URI.
	Policy: Section 5 defines policies that can be attached to a key and		Policy: Section 5 defines policies that can be attached to a key and
	keying related data. The <Policy> element is one such item that		keying related data. The <Policy> element is one such item that
	allows to restrict the usage of the key to certain functions, such		allows to restrict the usage of the key to certain functions, such
	as "OTP usage only". Further values may be registered as		as "OTP usage only". Further values may be registered as
	described in Section 12.		described in Section 12.
	skipping to change at page 34, line 23 ¶		skipping to change at page 37, line 23 ¶
	URN: urn:ietf:params:xml:ns:keyprov:pskc#hotp		URN: urn:ietf:params:xml:ns:keyprov:pskc#hotp
	Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt		Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt
	Identifier Definition: (this RFC)		Identifier Definition: (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
	Profiling:		Profiling:
	The <Usage> element MUST be present. The <ResponseFormat>		The <KeyPackage> element MUST be present and the
	element of the <Usage> element MUST be used to indicate the OTP		<ResponseFormat> element, which is a child element of the
			<AlgorithmParameters> element, MUST be used to indicate the OTP
	length and the value format.		length and the value format.
	The <Counter> element (see Section 4.2) MUST be provided as		The <Counter> element (see Section 4.1) MUST be provided as
	meta-data for the key.		meta-data for the key.
	The following additional constraints apply:		The following additional constraints apply:
	+ The value of the <Secret> element MUST contain key material		+ The value of the <Secret> element MUST contain key material
	with a length of at least 16 octets (128 bits), if it is		with a length of at least 16 octets (128 bits), if it is
	present.		present.
	+ The <ResponseFormat> element MUST have the 'Format'		+ The <ResponseFormat> element MUST have the 'Format'
	attribute set to "DECIMAL", and the 'Length' attribute MUST		attribute set to "DECIMAL", and the 'Length' attribute MUST
	indicate a length value between 6 and 9.		indicate a length value between 6 and 9.
	+ The <PINPolicy> element MAY be present but the		+ The <PINPolicy> element MAY be present but the
	'PINUsageMode' attribute cannot be set to "Algorithmic".		'PINUsageMode' attribute cannot be set to "Algorithmic".
	An example can be found in Figure 2.		An example can be found in Figure 3.
	10.2. KEYPROV-PIN		10.2. KEYPROV-PIN
	Common Name: KEYPROV-PIN		Common Name: KEYPROV-PIN
	Class: Symmetric static credential comparison		Class: Symmetric static credential comparison
	URN: urn:ietf:params:xml:ns:keyprov:pskc#pin		URN: urn:ietf:params:xml:ns:keyprov:pskc#pin
	Algorithm Definition: (this document)		Algorithm Definition: (this document)
	Identifier Definition (this document)		Identifier Definition (this document)
	Registrant Contact: IESG		Registrant Contact: IESG
	Profiling:		Profiling:
	The <Usage> element MAY be present but no attribute of the		The <Usage> element MAY be present but no attribute of the
	<Usage> element is required. The <ResponseFormat> element MAY		<Usage> element is required. The <ResponseFormat> element MAY
	be used to indicate the PIN value format.		be used to indicate the PIN value format.
	The <Secret> element (see Section 4.2) MUST be provided.		The <Secret> element (see Section 4.1) MUST be provided.
	See the example in Figure 3		See the example in Figure 5
	11. XML Schema		11. XML Schema
	This section defines the XML schema for PSKC.		This section defines the XML schema for PSKC.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		elementFormDefault="qualified"
	elementFormDefault="qualified"		attributeFormDefault="unqualified">
	attributeFormDefault="unqualified">		<!-- Please note that the first schemaLocation URI has a
	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"		linebreak inserted to make it with into the 72-character
	schemaLocation=		wide IETF documents. -->
	"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/		<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
	xmldsig-core-schema.xsd"/>		schemaLocation=
	<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"		"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
	schemaLocation=		xmldsig-core-schema.xsd"/>
	"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/		<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
	xenc-schema.xsd"/>		schemaLocation=
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>		"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
			<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
	<xs:complexType name="KeyContainerType">		<xs:complexType name="KeyContainerType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="EncryptionKey" type="ds:KeyInfoType"		<xs:element name="EncryptionKey"
	minOccurs="0"/>		type="ds:KeyInfoType" minOccurs="0"/>
	<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"		<xs:element name="MACMethod"
	minOccurs="0"/>		type="pskc:MACMethodType" minOccurs="0"/>
	<xs:element name="Device" type="pskc:DeviceType"		<xs:element name="KeyPackage"
	minOccurs="1" maxOccurs="unbounded"/>		type="pskc:KeyPackageType" maxOccurs="unbounded"/>
	<xs:element name="Signature" type="ds:SignatureType"		<xs:element name="Signature"
	minOccurs="0"/>		type="ds:SignatureType" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType"
	maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="pskc:VersionType"		<xs:attribute name="Version"
	use="required"/>		type="pskc:VersionType" 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:simpleType name="VersionType" final="restriction">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:pattern value="\d{1,2}\.\d{1,3}"/>		<xs:pattern value="\d{1,2}\.\d{1,3}"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</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="AlgorithmParameters"
	type="pskc:UsageType"/>		type="pskc:AlgorithmParametersType"
	<xs:element name="KeyProfileId"		minOccurs="0"/>
	type="xs:string" minOccurs="0"/>		<xs:element name="KeyProfileId"
	<xs:element name="KeyReference"		type="xs:string" minOccurs="0"/>
	type="xs:string" minOccurs="0"/>		<xs:element name="KeyReference"
	<xs:element name="FriendlyName"		type="xs:string" minOccurs="0"/>
	type="xs:string" minOccurs="0"/>		<xs:element name="FriendlyName"
	<xs:element name="Data" type="pskc:KeyDataType"		type="xs:string" minOccurs="0"/>
	minOccurs="0" maxOccurs="1"/>		<xs:element name="Data"
	<xs:element name="UserId" type="xs:string"		type="pskc:KeyDataType" minOccurs="0"/>
	minOccurs="0"/>		<xs:element name="UserId"
	<xs:element name="Policy"		type="xs:string" minOccurs="0"/>
	type="pskc:PolicyType" minOccurs="0"/>		<xs:element name="Policy"
	<xs:element name="Extensions"		type="pskc:PolicyType" minOccurs="0"/>
	type="pskc:ExtensionsType" minOccurs="0"		<xs:element name="Extensions"
	maxOccurs="unbounded"/>		type="pskc:ExtensionsType" minOccurs="0"
	</xs:sequence>		maxOccurs="unbounded"/>
	<xs:attribute name="KeyId"		</xs:sequence>
	type="xs:string" use="required"/>		<xs:attribute name="Id"
	<xs:attribute name="KeyAlgorithm"		type="xs:string" use="required"/>
	type="pskc:KeyAlgorithmType"		<xs:attribute name="Algorithm"
	use="optional"/>		type="pskc:KeyAlgorithmType" use="optional"/>
	<xs:attribute name="KeyProperties"
	type="xs:IDREF" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<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"
	<xs:element name="NumberOfTransactions"		minOccurs="0" maxOccurs="unbounded"/>
	type="xs:nonNegativeInteger" minOccurs="0"/>		<xs:element name="NumberOfTransactions"
	<xs:any namespace="##other"		type="xs:nonNegativeInteger" minOccurs="0"/>
	minOccurs="0" maxOccurs="unbounded"/>		<xs:any namespace="##other"
	</xs:sequence>		minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
			<xs:complexType name="KeyDataType">
			<xs:sequence>
			<xs:element name="Secret"
			type="pskc:binaryDataType" minOccurs="0"/>
			<xs:element name="Counter"
			type="pskc:longDataType" minOccurs="0"/>
			<xs:element name="Time"
			type="pskc:intDataType" minOccurs="0"/>
			<xs:element name="TimeInterval"
			type="pskc:intDataType" minOccurs="0"/>
			<xs:element name="TimeDrift"
			type="pskc:intDataType" minOccurs="0"/>
			<xs:any namespace="##other"
			processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyDataType">
	<xs:sequence>
	<xs:element name="Secret"
	type="pskc:binaryDataType"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="Counter"
	type="pskc:longDataType"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="Time"
	type="pskc:intDataType"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="TimeInterval"
	type="pskc:intDataType"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="TimeDrift"
	type="pskc:intDataType"
	minOccurs="0" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="binaryDataType">		<xs:complexType name="binaryDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue"		<xs:element name="PlainValue"
	type="xs:base64Binary"/>		type="xs:base64Binary"/>
	<xs:element name="EncryptedValue"		<xs:element name="EncryptedValue"
	type="xenc:EncryptedDataType"/>		type="xenc:EncryptedDataType"/>
	</xs:choice>		</xs:choice>
	<xs:element name="ValueMAC"		<xs:element name="ValueMAC"
	type="xs:base64Binary" minOccurs="0"/>		type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="intDataType">		<xs:complexType name="intDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue"		<xs:element name="PlainValue" type="xs:int"/>
	type="xs:int"/>		<xs:element name="EncryptedValue"
	<xs:element name="EncryptedValue"		type="xenc:EncryptedDataType"/>
	type="xenc:EncryptedDataType"/>		</xs:choice>
	</xs:choice>		<xs:element name="ValueMAC"
	<xs:element name="ValueMAC"		type="xs:base64Binary" minOccurs="0"/>
	type="xs:base64Binary" minOccurs="0"/>		</xs:sequence>
	</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="stringDataType">		<xs:complexType name="stringDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue"		<xs:element name="PlainValue" type="xs:string"/>
	type="xs:string"/>		<xs:element name="EncryptedValue"
	<xs:element name="EncryptedValue"		type="xenc:EncryptedDataType"/>
	type="xenc:EncryptedDataType"/>		</xs:choice>
	</xs:choice>		<xs:element name="ValueMAC"
	<xs:element name="ValueMAC"		type="xs:base64Binary" minOccurs="0"/>
	type="xs:base64Binary" minOccurs="0"/>		</xs:sequence>
	</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="longDataType">		<xs:complexType name="longDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue"		<xs:element name="PlainValue" type="xs:long"/>
	type="xs:long"/>		<xs:element name="EncryptedValue"
	<xs:element name="EncryptedValue"		type="xenc:EncryptedDataType"/>
	type="xenc:EncryptedDataType"/>		</xs:choice>
	</xs:choice>		<xs:element name="ValueMAC"
	<xs:element name="ValueMAC"		type="xs:base64Binary" minOccurs="0"/>
	type="xs:base64Binary" minOccurs="0"/>		</xs:sequence>
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name="DerivedKeyType">
	<xs:sequence>
	<xs:element name="KeyDerivationMethod"
	type="pskc:KeyDerivationMethodType" minOccurs="0"/>
	<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
	<xs:element name="CarriedKeyName" type="xs:string"
	minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="id" type="xs:ID" use="optional"/>
	<xs:attribute name="Type" type="xs:anyURI" use="optional"/>
	</xs:complexType>
	<xs:complexType name="KeyDerivationMethodType">
	<xs:sequence>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0"
	maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="Algorithm" type="xs:anyURI"
	use="required"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="PINPolicyType">		<xs:complexType name="PINPolicyType">
	<xs:attribute name="PINKeyId" type="xs:string"		<xs:attribute name="PINKeyId"
	use="optional"/>		type="xs:string" use="optional"/>
	<xs:attribute name="PINUsageMode"		<xs:attribute name="PINUsageMode"
	type="pskc:PINUsageModeType"/>		type="pskc:PINUsageModeType"/>
	<xs:attribute name="MaxFailedAttempts" type="xs:unsignedInt"		<xs:attribute name="MaxFailedAttempts"
	use="optional"/>		type="xs:unsignedInt" use="optional"/>
	<xs:attribute name="MinLength"		<xs:attribute name="MinLength"
	type="xs:unsignedInt" use="optional"/>		type="xs:unsignedInt" use="optional"/>
			<xs:attribute name="MaxLength"
	<xs:attribute name="MaxLength"		type="xs:unsignedInt" use="optional"/>
	type="xs:unsignedInt" use="optional"/>		<xs:attribute name="PINEncoding"
	<xs:attribute name="PINEncoding"		type="pskc:ValueFormatType" use="optional"/>
	type="pskc:ValueFormatType" use="optional"/>		<xs:anyAttribute namespace="##other"/>
	<xs:anyAttribute namespace="##other"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="PINUsageModeType">		<xs:simpleType name="PINUsageModeType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="Local"/>		<xs:enumeration value="Local"/>
	<xs:enumeration value="Prepend"/>		<xs:enumeration value="Prepend"/>
	<xs:enumeration value="Append"/>		<xs:enumeration value="Append"/>
	<xs:enumeration value="Algorithmic"/>		<xs:enumeration value="Algorithmic"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="KeyUsageType">		<xs:simpleType name="KeyUsageType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="OTP"/>		<xs:enumeration value="OTP"/>
	<xs:enumeration value="CR"/>		<xs:enumeration value="CR"/>
	<xs:enumeration value="Encrypt"/>		<xs:enumeration value="Encrypt"/>
	<xs:enumeration value="Integrity"/>		<xs:enumeration value="Integrity"/>
	<xs:enumeration value="Unlock"/>		<xs:enumeration value="Verify"/>
	<xs:enumeration value="Decrypt"/>		<xs:enumeration value="Unlock"/>
	<xs:enumeration value="KeyWrap"/>		<xs:enumeration value="Decrypt"/>
	</xs:restriction>		<xs:enumeration value="KeyWrap"/>
			<xs:enumeration value="Unwrap"/>
			<xs:enumeration value="Derive"/>
			<xs:enumeration value="Generate"/>
			</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="DeviceInfoType">		<xs:complexType name="DeviceInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Manufacturer" type="xs:string"		<xs:element name="Manufacturer"
	minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="SerialNo" type="xs:string"		<xs:element name="SerialNo"
	minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Model" type="xs:string"		<xs:element name="Model"
	minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="IssueNo" type="xs:string"		<xs:element name="IssueNo"
	minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="DeviceBinding" type="xs:string"		<xs:element name="DeviceBinding"
	minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="StartDate" type="xs:dateTime"		<xs:element name="StartDate"
	minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="ExpiryDate" type="xs:dateTime"		<xs:element name="ExpiryDate"
	minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="UserId"
	type="pskc:ExtensionsType" minOccurs="0"		type="xs:string" minOccurs="0"/>
	maxOccurs="unbounded"/>		<xs:element name="Extensions"
	</xs:sequence>		type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="DeviceType">		<xs:complexType name="CryptoModuleInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceInfo" type="pskc:DeviceInfoType"		<xs:element name="Id" type="xs:string"/>
	minOccurs="0"/>		<xs:element name="Extensions"
	<xs:element name="Key" type="pskc:KeyType"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:element name="User" type="xs:string"		</xs:sequence>
	minOccurs="0"/>
	<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="UsageType">		<xs:complexType name="KeyPackageType">
	<xs:choice>		<xs:sequence>
	<xs:element name="ChallengeFormat" minOccurs="0">		<xs:element name="DeviceInfo"
	<xs:complexType>		type="pskc:DeviceInfoType" minOccurs="0"/>
	<xs:attribute name="Encoding"		<xs:element name="CryptoModuleInfo"
	type="pskc:ValueFormatType" use="required"/>		type="pskc:CryptoModuleInfoType" minOccurs="0"/>
	<xs:attribute name="Min" type="xs:unsignedInt"		<xs:element name="Key"
	use="required"/>		type="pskc:KeyType" minOccurs="0"/>
	<xs:attribute name="Max" type="xs:unsignedInt"		<xs:element name="Extensions"
	use="required"/>		type="pskc:ExtensionsType" minOccurs="0"
	<xs:attribute name="CheckDigits" type="xs:boolean"		maxOccurs="unbounded"/>
	default="false"/>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		<xs:complexType name="AlgorithmParametersType">
	<xs:element name="ResponseFormat" minOccurs="0">		<xs:choice>
	<xs:complexType>		<xs:element name="ChallengeFormat" minOccurs="0">
	<xs:attribute name="Encoding"		<xs:complexType>
	type="pskc:ValueFormatType" use="required"/>		<xs:attribute name="Encoding"
	<xs:attribute name="Length" type="xs:unsignedInt"		type="pskc:ValueFormatType"
	use="required"/>		use="required"/>
	<xs:attribute name="CheckDigits" type="xs:boolean"		<xs:attribute name="Min"
	default="false"/>		type="xs:unsignedInt" use="required"/>
	</xs:complexType>		<xs:attribute name="Max"
	</xs:element>		type="xs:unsignedInt" use="required"/>
	<xs:element name="Extensions"		<xs:attribute name="CheckDigits"
	type="pskc:ExtensionsType" minOccurs="0"		type="xs:boolean" default="false"/>
	maxOccurs="unbounded"/>		</xs:complexType>
	</xs:choice>		</xs:element>
			<xs:element name="ResponseFormat" minOccurs="0">
			<xs:complexType>
			<xs:attribute name="Encoding"
			type="pskc:ValueFormatType"
			use="required"/>
			<xs:attribute name="Length"
			type="xs:unsignedInt" use="required"/>
			<xs:attribute name="CheckDigits"
			type="xs:boolean" default="false"/>
			</xs:complexType>
			</xs:element>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:choice>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="ExtensionsType">		<xs:complexType name="ExtensionsType">
	<xs:sequence>		<xs:sequence>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other"
	maxOccurs="unbounded"/>		processContents="lax" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="definition" type="xs:anyURI"		<xs:attribute name="definition"
	use="optional"/>		type="xs:anyURI" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="KeyAlgorithmType">		<xs:simpleType name="KeyAlgorithmType">
	<xs:restriction base="xs:anyURI"/>		<xs:restriction base="xs:anyURI"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="ValueFormatType">		<xs:simpleType name="ValueFormatType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="DECIMAL"/>		<xs:enumeration value="DECIMAL"/>
	<xs:enumeration value="HEXADECIMAL"/>		<xs:enumeration value="HEXADECIMAL"/>
	<xs:enumeration value="ALPHANUMERIC"/>		<xs:enumeration value="ALPHANUMERIC"/>
	<xs:enumeration value="BASE64"/>		<xs:enumeration value="BASE64"/>
	<xs:enumeration value="BINARY"/>		<xs:enumeration value="BINARY"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
			<xs:complexType name="MACMethodType">
	<xs:element name="DerivedKey" type="pskc:DerivedKeyType"/>		<xs:sequence>
			<xs:choice>
			<xs:element name="MACKey"
			type="xenc:EncryptedDataType" minOccurs="0"/>
			<xs:element name="MACKeyReference"
			type="xs:string" minOccurs="0"/>
			</xs:choice>
			<xs:any namespace="##other"
			processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
			</xs:complexType>
	<xs:element name="EncryptionScheme"		<xs:element name="EncryptionScheme"
	type="xenc:EncryptionMethodType"/>		type="xenc:EncryptionMethodType"/>
	<xs:element name="KeyContainer" type="pskc:KeyContainerType"/>		<xs:element name="KeyContainer"
	</xs:schema>		type="pskc:KeyContainerType"/>
			</xs:schema>
	12. IANA Considerations		12. IANA Considerations
	12.1. Content-type registration for 'application/pskc+xml'		12.1. Content-type registration for 'application/pskc+xml'
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	skipping to change at page 45, line 17 ¶		skipping to change at page 48, line 17 ¶
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>PSKC Namespace</title>		<title>PSKC Namespace</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for PSKC</h1>		<h1>Namespace for PSKC</h1>
	<h2>urn:ietf:params:xml:ns:keyprov:pskc:1.0</h2>		<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	12.4. PSKC Algorithm Profile Registry		12.4. PSKC Algorithm Profile Registry
	skipping to change at page 46, line 24 ¶		skipping to change at page 49, line 24 ¶
	IANA is asked to add an initial value to the registry based on the		IANA is asked to add an initial value to the registry based on the
	PSKC HOTP algorithm profile described in Section 10.		PSKC HOTP algorithm profile described in Section 10.
	12.5. PSKC Version Registry		12.5. PSKC Version Registry
	IANA is requested to create a registry for PSKC version numbers. The		IANA is requested to create a registry for PSKC version numbers. The
	registry has the following structure:		registry has the following structure:
	PSKC Version | Specification		PSKC Version | Specification
	+---------------------------+----------------		+---------------------------+----------------
	| 1 | [This document]		| 1.0 | [This document]
	Standards action is required to define new versions of PSKC. It is		Standards action is required to define new versions of PSKC. It is
	not envisioned to depreciate, delete, or modify existing PSKC		not envisioned to depreciate, delete, or modify existing PSKC
	versions.		versions.
	12.6. Key Usage Registry		12.6. Key Usage Registry
	IANA is requested to create a registry for key usage. A description		IANA is requested to create a registry for key usage. A description
	of the 'KeyUsage' element can be found in Section 5. The registry		of the 'KeyUsage' element can be found in Section 5. The registry
	has the following structure:		has the following structure:
	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]
			| Verify | [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]		| Unwrap | [Section 5 of this document]
	| Derive | [Section 5 of this document]		| Derive | [Section 5 of this document]
	| Generate | [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
	skipping to change at page 48, line 27 ¶		skipping to change at page 51, line 27 ¶
	By design, the container allows two main approaches to guaranteeing		By design, the container allows two main approaches to guaranteeing
	the confidentiality of the information it contains while transported.		the confidentiality of the information it contains while transported.
	First, the container key data payload may be encrypted.		First, the container key data payload may be encrypted.
	In this case no transport layer security is required. However,		In this case no transport layer security is required. However,
	standard security best practices apply when selecting the strength of		standard security best practices apply when selecting the strength of
	the cryptographic algorithm for payload encryption. Symmetric		the cryptographic algorithm for payload encryption. Symmetric
	cryptographic cipher should be used - the longer the cryptographic		cryptographic cipher should be used - the longer the cryptographic
	key, the stronger the protection. At the time of this writing both		key, the stronger the protection. Please see Section 6.1 for
	3DES and AES are mandatory algorithms but 3DES may be dropped in the		recommendations of payload protection using symmetric cryptographic
	relatively near future. Applications concerned with algorithm		ciphers. In cases where the exchange of key encryption keys between
	longevity are advised to use AES-256-CBC. In cases where the		the sender and the receiver is not possible, asymmetric encryption of
	exchange of key encryption keys between the sender and the receiver		the secret key payload may be employed, see Section 6.3 . Similarly
	is not possible, asymmetric encryption of the secret key payload may		to symmetric key cryptography, the stronger the asymmetric key, the
	be employed. Similarly to symmetric key cryptography, the stronger		more secure the protection is.
	the asymmetric key, the more secure the protection is.
	If the payload is encrypted with a method that uses one of the		If the payload is encrypted with a method that uses one of the
	password-based encryption methods provided above, the payload may be		password-based encryption methods provided above, the payload may be
	subjected to password dictionary attacks to break the encryption		subjected to password dictionary attacks to break the encryption
	password and recover the information. Standard security best		password and recover the information. Standard security best
	practices for selection of strong encryption passwords apply.		practices for selection of strong encryption passwords apply.
	Practical implementations should use PBESalt and PBEIterationCount		Practical implementations should use PBESalt and PBEIterationCount
	when PBE encryption is used. Different PBESalt value per key		when PBE encryption is used. Different PBESalt value per key
	container should be used for best protection.		container should be used for best protection.
	skipping to change at page 52, line 39 ¶		skipping to change at page 55, line 39 ¶
	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,		URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
	W3C Recommendation, February 2002.		W3C Recommendation, February 2002.
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/,		URL: http://www.w3.org/TR/xmlenc-core/,
	W3C Recommendation, December 2002.		W3C Recommendation, December 2002.
	16.2. Informative References		16.2. Informative References
			[AESKWPAD]
			Housley, R. and M. Dworkin, "Advanced Encryption Standard
			(AES) Key Wrap with Padding Algorithm", March 2009, <http:
			//www.ietf.org/internet-drafts/
			draft-housley-aes-key-wrap-with-pad-02.txt>.
	[CAP] MasterCard International, "Chip Authentication Program		[CAP] MasterCard International, "Chip Authentication Program
	Functional Architecture", September 2004.		Functional Architecture", September 2004.
	[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,		[NIST800-57]
			Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
	"NIST Special Publication 800-57, Recommendation for Key		"NIST Special Publication 800-57, Recommendation for Key
	Management - Part 1: General (Revised)", NIST Special		Management - Part 1: General (Revised)", NIST Special
	Publication 800-57, March 2007.		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.
			[PSKC-ALGORITHM-PROFILES]
			Hoyer, P., Pei, M., Machani, S., and A. Doherty,
			"Additional Portable Symmetric Key Container (PSKC)
			Algorithm Profiles", Internet Draft Informational, URL:
			http://tools.ietf.org/html/
			draft-hoyer-keyprov-pskc-algorithm-profiles-00,
			December 2008.
			[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.
			Masinter, "Uniform Resource Identifiers (URI): Generic
			Syntax", BCP 26, RFC 2396, August 1998.
	[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.
			[W3C-DKEY]
			Nystrom, M., "XML Security Derived Keys",
			W3C Informational, February 2009,
			<http://www.w3.org/TR/xmlsec-derivedkeys>.
			[XMLNS] "Namespaces in XML", W3C Recommendation ,
			URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
			January 1999.
	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
	inspired the development of this specification. These requirements		inspired the development of this specification. These requirements
	were used to derive the primary requirement that drove the design.		were used to derive the primary requirement that drove the design.
	These requirements are covered in the next section.		These requirements are covered in the next section.
	These use cases also help in understanding the applicability of this		These use cases also help in understanding the applicability of this
	specification to real world situations.		specification to real world situations.
End of changes. 185 change blocks.
	850 lines changed or deleted		1064 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/