< draft-ietf-keyprov-portable-symmetric-key-container-02.txt		draft-ietf-keyprov-portable-symmetric-key-container-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: May 9, 2008 VeriSign		Expires: August 25, 2008 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	S. Chang		February 22, 2008
	Gemalto
	November 6, 2007
	Portable Symmetric Key Container		Portable Symmetric Key Container
	draft-ietf-keyprov-portable-symmetric-key-container-02.txt		draft-ietf-keyprov-portable-symmetric-key-container-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 37 ¶
	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 May 9, 2008.		This Internet-Draft will expire on August 25, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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 (One Time Password (OTP) shared		provisioning of symmetric keys (One Time Password (OTP) shared
	secrets or symmetric cryptographic keys) to different types of strong		secrets or symmetric cryptographic keys) to different types of strong
	authentication devices. The standard token format enables		authentication devices. The standard token format enables
	enterprises to deploy best-of-breed solutions combining components		enterprises to deploy best-of-breed solutions combining components
	from different vendors into the same infrastructure.		from different vendors into the same infrastructure.
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	common and shared specification will facilitate adoption of two-		common and shared specification will facilitate adoption of two-
	factor authentication on the Internet by enabling interoperability		factor authentication on the Internet by enabling interoperability
	between commercial and open-source implementations.		between commercial and open-source implementations.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions used in this document . . . . . . . . . . . . . . 5		2. Conventions used in this document . . . . . . . . . . . . . . 5
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6		3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Credential migration by end-user . . . . . . . . . . . 6		3.1.1. Key migration by end-user . . . . . . . . . . . . . . 6
	3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6		3.1.2. Bulk import of new keys . . . . . . . . . . . . . . . 6
	3.1.3. Bulk migration of existing credentials . . . . . . . . 6		3.1.3. Bulk migration of existing keys . . . . . . . . . . . 7
	3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7		3.1.4. Key upload case . . . . . . . . . . . . . . . . . . . 7
	3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7		3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. Online provisioning a credential to end-user's		3.2.1. Online provisioning a key to end-user's
	authentication token . . . . . . . . . . . . . . . . . 7		authentication token . . . . . . . . . . . . . . . . . 7
	3.2.2. Server to server provisioning of credentials . . . . . 8		3.2.2. Server to server provisioning of keys . . . . . . . . 8
	3.2.3. Online update of an existing authentication token		3.2.3. Online update of an existing authentication token
	credential . . . . . . . . . . . . . . . . . . . . . . 8		key . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11		5. Portable Key container definition . . . . . . . . . . . . . . 11
	5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11		5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11		5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11		5.2.1. DeviceId . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 12		5.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 13		5.3.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17
	5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 13		5.3.2. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 17
	5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 13		5.3.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 21
	5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 13		5.3.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 22
	5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute		6. Usage and profile of algorithms for the portable symmetric
	is encrypted)) . . . . . . . . . . . . . . . . . . . . 13		key container . . . . . . . . . . . . . . . . . . . . . . . . 24
	5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 14		6.1. Usage of EncryptionKey to protect keys in transit . . . . 24
	5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 14		6.1.1. Protecting keys using a pre-shared key via
	5.1.11. Logo (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17		symmetric algorithms . . . . . . . . . . . . . . . . . 24
	6. Key container XML schema definitions . . . . . . . . . . . . . 18		6.1.2. Protecting keys using passphrase based encryption
	6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 18		keys . . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 19		6.2. Protecting keys using asymmetric algorithms . . . . . . . 27
	6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 21		6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 28
	6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22		6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 28
	6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 23		6.3.2. PIN key value compare algorithm identifier . . . . . . 28
	6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 24		7. Reserved data attribute names . . . . . . . . . . . . . . . . 30
	6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 25		8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 26		9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 28		9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 35
	6.2. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 29		9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 36
	6.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . . . 29		9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 36
	6.4. Data elements . . . . . . . . . . . . . . . . . . . . . . 29		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
	6.4.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 29		11. Appendix A - Example Symmetric Key Containers . . . . . . . . 38
	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31		11.1. Symmetric Key Container with a single Non-Encrypted
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 39		HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 38
	8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 39		11.2. Symmetric Key Container with a single PIN protected
	8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 40		Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 38
	8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 40		11.3. Symmetric Key Container with a single AES-256-CBC
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41		Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 39
	10. Appendix A - Example Symmetric Key Containers . . . . . . . . 42		11.4. Symmetric Key Container with signature and a single
	10.1. Symmetric Key Container with a single Non-Encrypted		Password-based Encrypted HOTP Secret Key . . . . . . . . . 40
	HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 42		11.5. Symmetric Key Container with a single RSA 1.5
	10.2. Symmetric Key Container with a single Password-based
	Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 42		Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 42
	11. Normative References . . . . . . . . . . . . . . . . . . . . . 44		12. Normative References . . . . . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
	Intellectual Property and Copyright Statements . . . . . . . . . . 47		Intellectual Property and Copyright Statements . . . . . . . . . . 47
	1. Introduction		1. Introduction
	With increasing use of symmetric key based authentication systems		With increasing use of symmetric key based authentication systems
	such as systems based one time password (OTP) and challenge response		such as systems based one time password (OTP) and challenge response
	mechanisms, there is a need for vendor interoperability and a		mechanisms, there is a need for vendor interoperability and a
	standard format for importing, exporting or provisioning symmetric		standard format for importing, exporting or provisioning symmetric
	key based credentials from one system to another. Traditionally		keys from one system to another. Traditionally authentication server
	authentication server vendors and service providers have used		vendors and service providers have used proprietary formats for
	proprietary formats for importing, exporting and provisioning these		importing, exporting and provisioning these keys into their systems
	credentials into their systems making it hard to use tokens from		making it hard to use tokens from vendor A with a server from vendor
	vendor A with a server from vendor B.		B.
	This Internet draft describes a standard format for serializing		This Internet draft describes a standard format for serializing
	symmetric key based credentials such as OTP shared secrets for system		symmetric keys such as OTP shared secrets for system import, export
	import, export or network/protocol transport. The goal is that the		or network/protocol transport. The goal is that the format will
	format will facilitate dynamic provisioning and transfer of a		facilitate dynamic provisioning and transfer of a symmetric keys such
	symmetric key such as an OTP shared secret or an encryption key of		as an OTP shared secret or an encryption key of different types. In
	different types. In the case of OTP shared secrets, the format will		the case of OTP shared secrets, the format will facilitate dynamic
	facilitate dynamic provisioning using an OTP provisioning protocol to		provisioning using an online provisioning protocol to different
	different flavors of embedded tokens for OTP credentials or allow		flavors of embedded tokens or allow customers to import new or
	customers to import new or existing tokens in batch or single		existing tokens in batch or single instances into a compliant system.
	instances into a compliant system.
	This draft also specifies the token attributes required for		This draft also specifies the key attributes required for computation
	interoperability such as the initial event counter used in the HOTP		such as the initial event counter used in the HOTP algorithm [HOTP].
	algorithm [HOTP]. It is also applicable for other time-based or		It is also applicable for other time-based or proprietary algorithms.
	proprietary algorithms.
	To provide an analogy, in public key environments the PKCS#12 format		To provide an analogy, in public key environments the PKCS#12 format
	[PKCS12] is commonly used for importing and exporting private keys		[PKCS12] is commonly used for importing and exporting private keys
	and certificates between systems. In the environments outlined in		and certificates between systems. In the environments outlined in
	this document where OTP credentials may be transported directly down		this document where OTP keys may be transported directly down to
	to smartcards or devices with limited computing capabilities, a		smartcards or devices with limited computing capabilities, a format
	format with small (size in bytes) and explicit shared secret		with small (size in bytes) and explicit shared secret configuration
	configuration attribute information is desirable, avoiding complexity		attribute information is desirable, avoiding complexity of PKCS#12.
	of PKCS#12. For example, one would have to use opaque data within		For example, one would have to use opaque data within PKCS#12 to
	PKCS#12 to carry shared secret attributes used for OTP calculations,		carry shared secret attributes used for OTP calculations, whereas a
	whereas a more explicit attribute schema definition is better for		more explicit attribute schema definition is better for
	interoperability and efficiency.		interoperability and efficiency.
	2. Conventions used in this document		2. Conventions used in this document
	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].
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	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.
	3.1. Offline Use Cases		3.1. Offline Use Cases
	This section describes the use cases relating to offline transport of		This section describes the use cases relating to offline transport of
	credentials from one system to another, using some form of export and		keys from one system to another, using some form of export and import
	import model.		model.
	3.1.1. Credential migration by end-user		3.1.1. Key migration by end-user
	A user wants to migrate a credential from one authentication token		A user wants to migrate a key from one authentication token
	(container) to a different authentication token. For example, the		(container) to a different authentication token. For example, the
	authentication tokens may be soft tokens on two different systems		authentication tokens may be soft tokens on two different systems
	(computers or mobile phones). The user can export the credential in		(computers or mobile phones). The user can export the key and
	a standard format for import into the other authentication token.		related data in a standard format for import into the other
			authentication token.
	The key protection mechanism may rely on password-based encryption		The key protection mechanism may rely on password-based encryption
	for soft tokens, a pre-placed hardware-protected transfer key shared		for soft tokens, a pre-placed hardware-protected transfer key shared
	between the two systems or may also rely on asymmetric keys/ PKI if		between the two systems or may also rely on asymmetric keys/ PKI if
	available.		available.
	3.1.2. Bulk import of new credentials		3.1.2. Bulk import of new keys
	Tokens are manufactured in bulk and associated credentials (key		Tokens are manufactured in bulk and associated keys and algorithm
	records) need to be loaded into the validation system through a file		data need to be loaded into the validation system through a file on
	on portable media. The manufacturer provides the credentials in the		portable media. The manufacturer provides the keys and related data
	form of a file containing records in standard format, typically on a		in the form of a file containing records in standard format,
	CD. Note that the token manufacturer and the vendor for the		typically on a CD. Note that the token manufacturer and the vendor
	validation system may be the same or different.		for the validation system may be the same or different.
	In this case the file usually is protected by a symmetric transport		In this case the file usually is protected by a symmetric transport
	key which was communicated separately outside of the file between the		key which was communicated separately outside of the file between the
	two parties.		two parties.
	3.1.3. Bulk migration of existing credentials		Some devices will allow local PIN management (the device will have a
			PIN pad) hence random initial PINs set at manufacturing should be
			transmitted together with the respective keys they protect.
	An enterprise wants to port credentials from an existing validation		3.1.3. Bulk migration of existing keys
	system A into a different validation system B. The existing
	validation system provides the enterprise with a functionality that
	enables export of credentials (OTP tokens) in a standard format.
	Since the OTP tokens are in the standard format, the enterprise can		An enterprise wants to port keys and related data from an existing
	import the token records into the new validation system B and start		validation system A into a different validation system B. The
	using the existing tokens. Note that the vendors for the two		existing validation system provides the enterprise with a
	validation systems may be the same or different.		functionality that enables export of keys and related data (e.g. for
			OTP tokens) in a standard format. Since the OTP tokens are in the
			standard format, the enterprise can import the token records into the
			new validation system B and start using the existing tokens. Note
			that the vendors for the two validation systems may be the same or
			different.
	In this case the file usually is protected by a symmetric transport		In this case the file usually is protected by a symmetric transport
	key which was communicated separately outside of the file between the		key which was communicated separately outside of the file between the
	two validation systems.		two validation systems.
	3.1.4. Credential upload case		In this case it is also important to be able to communicate the
			existing assignment (binding) of a device to a specific user.
	User wants to activate and use a new credential against a validation		3.1.4. Key upload case
	system that is not aware of this credential. This credential may be
			User wants to activate and use a new key and related data against a
			validation system that is not aware of this key. This key may be
	embedded in the authentication token (e.g. SD card, USB drive) that		embedded in the authentication token (e.g. SD card, USB drive) that
	the user has purchased at the local electronics retailer. Along with		the user has purchased at the local electronics retailer. Along with
	the authentication token, the user may get the credential on a CD or		the authentication token, the user may get the key on a CD or a
	a floppy in a standard format. The user can now upload via a secure		floppy in a standard format. The user can now upload via a secure
	online channel or import this credential into the new validation		online channel or import this key and related data into the new
	system and start using the credential.		validation system and start using the key.
	The key protection mechanism may rely on password-based encryption,		The key protection mechanism may rely on password-based encryption,
	or a pre-placed hardware-protected transfer key shared between the		or a pre-placed hardware-protected transfer key shared between the
	token manufacturer and the validation system(s) if available.		token manufacturer and the validation system(s) if available.
	3.2. Online Use Cases		3.2. Online Use Cases
	This section describes the use cases related to provisioning the		This section describes the use cases related to provisioning the keys
	credentials using some form of a online provisioning protocol.		using some form of a online provisioning protocol.
	3.2.1. Online provisioning a credential to end-user's authentication		3.2.1. Online provisioning a key to end-user's authentication token
	token
	A mobile device user wants to obtain an OTP credential (shared		A mobile device user wants to obtain an OTP key for use with an OTP
	secret) for use with an OTP soft token on the device. The soft token		soft token on the device. The soft token client from vendor A
	client from vendor A initiates the provisioning process against a		initiates the provisioning process against a provisioning system from
	provisioning system from vendor B using a standards-based		vendor B using a standards-based provisioning protocol such as
	provisioning protocol such as [DSKPP]. The provisioning system		[DSKPP]. The provisioning system delivers one or more keys in a
	delivers one or more OTP credential(s) in a standard format that can		standard format that can be processed by the mobile device. The user
	be processed by the mobile device. The user can download a payload		can download a payload that contains more than one key.
	that contains more than one credential.
	In a variation of the above, instead of the user's mobile phone, a		In a variation of the above, instead of the user's mobile phone, a
	credential is provisioned in the user's soft token application on a		key is provisioned in the user's soft token application on a laptop
	laptop using a network-based online protocol. As before, the		using a network-based online protocol. As before, the provisioning
	provisioning system delivers an OTP credential in a standard format		system delivers an OTP key in a standard format that can be processed
	that can be processed by the soft token on the PC.		by the soft token on the PC.
	3.2.2. Server to server provisioning of credentials		3.2.2. Server to server provisioning of keys
	Sometimes, instead of importing token information from manufacturer		Sometimes, instead of importing keys from a manufacturer using a
	using a file, an OTP validation server may download the credential		file, an OTP validation server may download the keys using an online
	seed records using an online protocol. The credentials can be		protocol. The keys can be downloaded in a standard format that can
	downloaded in a standard format that can be processed by a validation		be processed by a validation system.
	system.
	In another scenario, an OTA (over-the-air) credential provisioning		In another scenario, an OTA (over-the-air) key provisioning gateway
	gateway that provisions credentials to mobile phones may obtain		that provisions keys to mobile phones may obtain key material from a
	credentials from the credential issuer using an online protocol. The		key issuer using an online protocol. The keys are delivered in a
	credentials are delivered in a standard format that can be processed		standard format that can be processed by the OTA key provisioning
	by the OTA credential provisioning gateway and subsequently sent to		gateway and subsequently sent to the end-user's mobile phone.
	the end-user's mobile phone.
	3.2.3. Online update of an existing authentication token credential		3.2.3. Online update of an existing authentication token key
	The end-user or the credential issuer wants to update or configure an		The end-user or the key issuer wants to update or configure an
	existing credential in the authentication token and requests a		existing key in the authentication token and requests a replacement
	replacement credential container. The container may or may not		key container. The container may or may not include a new key and
	include a new secret key and may include new or updated secret key		may include new or updated key attributes such as a new counter value
	attributes such as a new counter value in HOTP credential case, a new		in HOTP key case, a modified response format or length, a new
	logo, a modified response format or length, a new friendly name, etc.		friendly name, etc.
	4. Requirements		4. Requirements
	This section outlines the most relevant requirements that are the		This section outlines the most relevant requirements that are the
	basis of this work. Several of the requirements were derived from		basis of this work. Several of the requirements were derived from
	use cases described above.		use cases described above.
	R1: The format MUST support transport of multiple types of		R1: The format MUST support transport of multiple types of
	symmetric key credentials including HOTP, other OTP, challenge-		symmetric keys and related attributes for algorithms including
	response, etc.		HOTP, other OTP, challenge-response, etc.
	R2: The format MUST handle the symmetric key itself as well of		R2: The format MUST handle the symmetric key itself as well of
	attributes that are typically associated with symmetric keys.		attributes that are typically associated with symmetric keys.
	Some of these attributes may be		Some of these attributes may be
	* Unique Key Identifier		* Unique Key Identifier
	* Issuer information		* Issuer information
	* Algorithm ID		* Algorithm ID
	* Algorithm mode		* Algorithm mode
	* Issuer Name		* Issuer Name
	* Issuer logo		* Key friendly name
	* Credential friendly name
	* Event counter value (moving factor for OTP algorithms)		* Event counter value (moving factor for OTP algorithms)
	* Time value		* Time value
	R3: The format SHOULD support both offline and online scenarios.		R3: The format SHOULD support both offline and online scenarios.
	That is it should be serializable to a file as well as it		That is it should be serializable to a file as well as it
	should be possible to use this format in online provisioning		should be possible to use this format in online provisioning
	protocols		protocols
	R4: The format SHOULD allow bulk representation of symmetric key		R4: The format SHOULD allow bulk representation of symmetric keys
	credentials.
	R5: The format SHOULD be portable to various platforms.		R5: The format SHOULD allow bulk representation of PINs related to
			specific keys
			R6: The format SHOULD be portable to various platforms.
	Furthermore, it SHOULD be computationally efficient to process.		Furthermore, it SHOULD be computationally efficient to process.
	R6: The format MUST provide appropriate level of security in terms		R7: The format MUST provide appropriate level of security in terms
	of data encryption and data integrity.		of data encryption and data integrity.
	R7: For online scenarios the format SHOULD NOT rely on transport		R8: For online scenarios the format SHOULD NOT rely on transport
	level security (e.g., SSL/TLS) for core security requirements.		level security (e.g., SSL/TLS) for core security requirements.
	R8: The format SHOULD be extensible. It SHOULD enable extension		R9: The format SHOULD be extensible. It SHOULD enable extension
	points allowing vendors to specify additional attributes in the		points allowing vendors to specify additional attributes in the
	future.		future.
	R9: The format SHOULD allow for distribution of key derivation data		R10: The format SHOULD allow for distribution of key derivation data
	without the actual symmetric key itself. This is to support		without the actual symmetric key itself. This is to support
	symmetric key management schemes that rely on key derivation		symmetric key management schemes that rely on key derivation
	algorithms based on a pre-placed master key. The key		algorithms based on a pre-placed master key. The key
	derivation data typically consists of a reference to the key,		derivation data typically consists of a reference to the key,
	rather than the key value itself.		rather than the key value itself.
	R10: The format SHOULD allow for additional lifecycle management		R11: The format SHOULD allow for additional lifecycle management
	operations such as counter resynchronization. Such processes		operations such as counter resynchronization. Such processes
	require confidentiality between client and server, thus could		require confidentiality between client and server, thus could
	use a common secure container format, without the transfer of		use a common secure container format, without the transfer of
	key material.		key material.
	R11: The format MUST support the use of pre-shared symmetric keys to		R12: The format MUST support the use of pre-shared symmetric keys to
	ensure confidentiality of sensitive data elements.		ensure confidentiality of sensitive data elements.
	R12: The format MUST support a password-based encryption (PBE)		R13: The format MUST support a password-based encryption (PBE)
	[PKCS5] scheme to ensure security of sensitive data elements.		[PKCS5] scheme to ensure security of sensitive data elements.
	This is a widely used method for various provisioning		This is a widely used method for various provisioning
	scenarios.		scenarios.
	R13: The format SHOULD support asymmetric encryption algorithms such		R14: The format SHOULD support asymmetric encryption algorithms such
	as RSA to ensure end-to-end security of sensitive data		as RSA to ensure end-to-end security of sensitive data
	elements. This is to support scenarios where a pre-set shared		elements. This is to support scenarios where a pre-set shared
	encryption key is difficult to use.		encryption key is difficult to use.
	5. Symmetric Key Attributes		5. Portable Key container definition
	The symmetric key includes a number of data attributes that define
	the type of the key its usage and associated meta-information
	required during the provisioning, configuration, access or usage in
	the host device.
	5.1. Common Attributes
	5.1.1. Data (OPTIONAL)
	Defines the data attributes of the symmetric key. Each is a name
	value pair which has both a base64 encoded value and a base 64
	encoded ValueDigest. The value can be encrypted. If the container
	has been encrypted the ValueDigest MUST be populated with the digest
	of the unencrypted value.
	This is also where the key value is held, therefore the following
	list of attribute names have been reserved:
	SECRET: the shared secret key value in binary, base64 encoded
	COUNTER: the event counter for event based OTP algorithms. 8 bytes
	unsigned integer in big endian (i.e. network byte order) form
	base64 encoded
	TIME: the time for time based OTP algorithms. 8 bytes unsigned
	integer in big endian (i.e. network byte order) form base64
	encoded (Number of seconds since 1970)
	TIME_INTERVAL: the time interval value for time based OTP
	algorithms. 8 bytes unsigned integer in big endian (i.e. network
	byte order) form base64 encoded.
	TIME_DRIFT: the device clock drift value for time based OTP		The portable key container is based on an XML schema definition and
	algorithms. The value indicates number of seconds that the device		contains the following main entities:
	clock may drift each day. 2 bytes unsigned integer in big endian
	(i.e. network byte order) form base64 encoded.
	5.1.2. KeyAlgorithm (MANDATORY)		1. KeyContainer entity as defined in Section 5.1
	Defines the type of algorithm of the secret key. The following		2. Device entity as defined in Section 5.2
	algorithm URIs are among the default support list.
	o http://www.w3.org/2001/04/xmlenc#tripledes-cbc		3. Key entity as defined in Section 5.3
	o http://www.w3.org/2001/04/xmlenc#aes128-cbc		Additionally other XML schema types have been defined and are
	o http://www.w3.org/2001/04/xmlenc#aes192-cbc		detailed in the relevant subsections of this document
	o http://www.w3.org/2001/04/xmlenc#aes256-cbc		A KeyContainer MAY contain one or more Device entities. A Device MAY
			contain one or more Key entities
	o http://www.ietf.org/keyprov/pskc#hotp		The figure below indicates a possible relationship diagram of a
			container.
	5.1.2.1. OTP Key Algorithm Identifiers		--------------------------------------------
			| KeyContainer |
			| |
			| ------------------ ----------------- |
			| | Device 1 | | Device n | |
			| | | | | |
			| | ------------ | | ------------ | |
			| | | Key 1 | | | | Key n | | |
			| | ------------ | | ------------ | |
			| | | | | |
			| | | | | |
			| | ------------ | | ------------ | |
			| | | Key m | | | | Key p | | |
			| | ------------ | | ------------ | |
			| ------------------ ----------------- |
			| |
			--------------------------------------------
	OTP key algorithm URIs have not been defined in a commonly available		The following section describe in detail all the entities and related
	standard specification. This document defines the following URIs for		XML schema elements and attributes:
	the known open standard OTP algorithms.
	5.1.2.1.1. HOTP		5.1. KeyContainer
	Standard document: RFC4226		The KeyContainer represents the key container entity. A Container
			MAY contain more than one Device entity; each Device entity MAY
			contain more than one Key entity.
	Identifier: http://www.ietf.org/keyprov/pskc#hotp		The KeyContainer is defined as follows:
	Note that the actual URL will be finalized once a URL for this		<xs:complexType name="KeyContainerType">
	document is determined.		<xs:sequence>
			<xs:element name="EncryptionKey"
			type="ds:KeyInfoType" minOccurs="0"/>
			<xs:element name="MACAlgorithm"
			type="pskc:KeyAlgorithmType" minOccurs="0"/>
			<xs:element name="Device"
			type="pskc:DeviceType" maxOccurs="unbounded"/>
			<xs:element name="Signature"
			type="ds:SignatureType" minOccurs="0"/>
			</xs:sequence>
			<xs:attribute name="Version" type="pskc:VersionType" use="required"/>
			</xs:complexType>
	5.1.2.1.2. Other OTP Algorithms		The elements of the KeyContainer have the following meanings:
	An implementation should refer to vendor supplied OTP key algorithm		o <EncryptionKey (OPTIONAL)>, Identifies the encryption key,
	URIs for proprietary algorithms.		algorithm and possible parameters used to protect the Secret Key
			data in the container, for profile and usage please see
			Section 6.1
	5.1.3. Usage (MANDATORY)		o <MACAlgorithm (OPTIONAL)>, Identifies the algorithm used to
			generate a keyed digest of the the Secret Key data values when
			protection algorithms are used that do not have integrity checks.
			The digest guarantees the integrity and the authenticity of the
			key data. for profile and usage please see Section 6.1.1
	Defines the intended usage of the key and is a combination of one or		o <Device>, the host Device for one or more Keys as defined in
	more of the following (set to true):		Section 5.2 The KeyContainer MAY contain multiple Device data
			elements, allowing for bulk provisioning of keys.
	OTP: the key will be used for OTP generation		o <Signature (OPTIONAL)>, the signature value of the Container.
			When the signature is applied to the entire container, it MUST use
			XML Signature methods as defined in [XMLSIG]. It MAY be omitted
			when application layer provisioning or transport layer
			provisioning protocols provide the integrity and authenticity of
			the payload between the sender and the recipient of the container.
			When required, this specification recommends using a symmetric key
			based signature with the same key used in the encryption of the
			secret key data. The signature is enveloped.
	CR: the key will be used for Challenge/Response purposes		o <Version (MANDATORY)>, the version number for the portable key
			container format (the XML schema defined in this document).
	Encrypt: the key will be used for data encryption purposes		5.2. Device
	Sign: the key will be used to generate a signature or keyed		The Device represents the Device entity in the Container. A Device
	hashing for data integrity or authentication purposes.		MAY be bound to a user and MAY contain more than one keys. It is
			recommended that a key is bound to one and only one Device.
	Unlock: the key will be used for an inverse challenge response in		The Device is defined as follows:
	the case a user has locked the device by entering a wrong PIN too
	many times (for devices with PIN-input capability)
	Additional attributes that are specific to the usage type MAY be		<xs:complexType name="DeviceType">
	required. Section 6.1 describes OTP and CR specific attributes.		<xs:sequence>
			<xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>
			<xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>
			<xs:element name="UserId" type="xs:string" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
	5.1.4. KeyId (MANDATORY)		The elements of the Device have the following meanings:
	A unique and global identifier of the symmetric key. The identifier		o <DeviceId>, a unique identifier for the device, defined in
	is defined as a string of alphanumeric characters.		Section 5.2.1
	5.1.5. Issuer (MANDATORY)		o <Key>, represents the key entity as defined in Section 5.3
	The key issuer name, this is normally the name of the organization		o <UserId>, optionally identifies the owner or the user of the
	that issues the key to the end user of the key. For example MyBank		Device TODO
	issuing hardware tokens to their retail banking users 'MyBank' would
	be the issuer. The Issuer is defined as a String.
	5.1.6. FriendlyName (OPTIONAL)		5.2.1. DeviceId
	The user friendly name that is assigned to the secret key for easy		The DeviceId represents the identifying criteria to uniquely identify
	reference. The FriendlyName is defined as a String.		the device that contains the associated keys. Since devices can come
			in different form factors such as hardware tokens, smartcards, soft
			tokens in a mobile phone or PC etc this type 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 will uniquely identify a device but not
			SerialNo alone since two different token manufacturers might issue
			devices with the same serial number (similar to the IssuerDN and
			serial number of a certificate). For keys hold on banking cards the
			identification of the device is often done via the Primary Account
			Number (PAN, the big number printed on the front of the card) and an
			expiry date of the card. DeviceId is an extensible type that allows
			all these different ways to uniquely identify a specific key
			containing device.
	5.1.7. AccessRules (OPTIONAL)		The DeviceId is defined as follows:
	Defines a set of access rules and policies for the protection of the		<xs:complexType name="DeviceIdType">
	key on the host Device. Currently only the UserPIN policy is		<xs:sequence>
	defined. The UserPIN policy specifies whether the user MUST enter a		<xs:element name="Manufacturer" type="xs:string"/>
	PIN (for devices with PIN input capability) in order to unlock or		<xs:element name="SerialNo" type="xs:string"/>
	authenticate to the device hosting the key container. The UserPIN is		<xs:element name="Model" type="xs:string" minOccurs="0"/>
	defined as a Boolean (TRUE or FALSE). When the user PIN is required,		<xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
	the policy MUST be set to TRUE. If the UserPIN is NOT provided,		<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
	implementations SHALL default the value to FALSE.		<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
	5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted))		The elements of DeviceId have the following meanings:
	Identifies the encryption algorithm and possible parameters used to		o <Manufacturer>, the manufacturer of the device.
	protect the Secret Key data in the container. The encryption
	algorithm URI can be one of the following.
	o http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2		o <SerialNo>, the serial number of the device or the PAN (primary
			account number) in case of EMV (Europay-MasterCard-Visa) smart
			cards.
	o http://www.w3.org/2001/04/xmlenc#tripledes-cbc		o <Model>, the model of the device (e.g one-button-HOTP-token-V1)
	o http://www.w3.org/2001/04/xmlenc#aes128-cbc		o <IssueNo>, the issue number in case of smart cards with the same
			PAN, equivalent to a PSN (PAN Sequence Number).
	o http://www.w3.org/2001/04/xmlenc#aes192-cbc		o <ExpiryDate>, the expiry date of a device (such as the one on an
			EMV card,used when issue numbers are not printed on cards).
	o http://www.w3.org/2001/04/xmlenc#aes256-cbc		o <StartDate>, the start date of a device (such as the one on an EMV
			card,used when issue numbers are not printed on cards).
	o http://www.w3.org/2001/04/xmlenc#rsa-1_5		5.3. Key
	o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p		The Key represents the key entity in the KeyContainer. The Key is
	o http://www.w3.org/2001/04/xmlenc#kw-tripledes		defined as follows:
	o http://www.w3.org/2001/04/xmlenc#kw-aes128		<xs:complexType name="KeyType">
			<xs:sequence>
			<xs:element name="Issuer" type="xs:string" minOccurs="0"/>
			<xs:element name="Usage" type="pskc:UsageType"/>
			<xs:element name="CardAppPersoProfileId" type="xs:string"
			minOccurs="0"/>
			<xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>
			<xs:element name="Data" type="pskc:DataType" minOccurs="0"
			maxOccurs="unbounded"/>
			<xs:element name="PINPolicy" type="pskc:PINPolicyType"
			minOccurs="0"/>
			<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
			<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
			</xs:sequence>
			<xs:attribute name="KeyId" type="xs:string" use="required"/>
			<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
			use="required"/>
			</xs:complexType>
	o http://www.w3.org/2001/04/xmlenc#kw-aes256		The attributes of the Key entity have the following meanings:
	o http://www.w3.org/2001/04/xmlenc#kw-aes512		o KeyId (MANDATORY), a unique and global identifier of the symmetric
			key. The identifier is defined as a string of alphanumeric
			characters.
	When an PBE algorithm is used for encryption, the URI		o <KeyAlgorithm (MANDATORY)>, the unique URI of the type of
	http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 and the		algorithm to use with the secret key, for profiles are described
	encryption algorithm in PBEEncryptionParamType defines the exact PBE		in Section 6.3
	key derivation and encryption algorithms.
	When the value is not provided, implementations SHALL ensure the		The elements of the Key entity have the following meanings:
	privacy of the key data through other standard mechanisms e.g.
	transport level encryption.
	When the container (payload) contains more than one key and		o <Issuer (OPTIONAL)>, The key issuer name, this is normally the
	EncryptionMethod is specified, the same encryption key MUST be used		name of the organization that issues the key to the end user of
	to encrypt all the key data elements in the container.		the key. For example MyBank issuing hardware tokens to their
			retail banking users 'MyBank' would be the issuer. The Issuer is
			defined as a String.
	5.1.9. DigestMethod (MANDATORY when Digest is present)		o <Usage (MANDATORY)>, defines the intended usage of the key and
			related metadata as defined in Section 5.3.2
	Identifies the algorithm and possible parameters used to generate a		o <CardAppPersoProfileId (OPTIONAL)>, A uniquie identifier used
	digest of the the Secret Key data. The digest guarantees the		between the sending and receiving party of the container to
	integrity and the authenticity of the key data.		establish a set of constant values related to a key that are not
			transmitted via the container. 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. An example could be an EMV MasterCard CAP
			[CAP] application on a card personalised with data for a specific
			batch of cards such as:
	See Section 6.1.8 for more information on Digest data value type.		IAF Internet authentication flag
	5.1.10. OTP and CR specific Attributes (OPTIONAL)		CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
			VISA 13, VISA14)
	When the key usage is set to OTP or CR, additional attributes MUST be		AIP (Application Interchange Profile), 2 bytes
	provided to support the OTP and/or the response computation as
	required by the underlying algorithm and to customize or configure
	the outcome of the computation (format, length and usage modes).
	5.1.10.1. ChallengeFormat (MANDATORY)		TVR Terminal Verification Result, 5 bytes
	The ChallengeFormat attribute defines the characteristics of the		CVR The card verification result
	challenge in a CR usage scenario. The Challenge attribute is defined
	by the following sub-attributes:
	1. Format (MANDATORY)		AmountOther
	Defines the format of the challenge accepted by the device and		TransactionDate
	MUST be one of the values defined in Section 6.3
	2. CheckDigit (OPTIONAL)		TerminalCountryCode
	Defines if the device needs to check the appended Luhn check		TransactionCurrencyCode
	digit contained in a provided challenge. This is only valid
	if the Format attribute is 'DECIMAL'. Value MUST be:
	TRUE device will check the appended Luhn check digit in a		AmountAuthorised
	provided challenge
	FALSE device will not check appended Luhn check digit in		IIPB
	challenge
	3. Min (MANDATORY)		These values are not contained within attributes in the container
			but are shared between the manufacturing and the validation
			service through this unique CardAppPersoProfileId. The
			CardAppPersoProfileId is defined as a String.
	Defines the minimum size of the challenge accepted by the		o <FriendlyName (OPTIONAL)>, The user friendly name that is assigned
	device for CR mode.		to the secret key for easy reference. The FriendlyName is defined
			as a String.
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or		o <Data (OPTIONAL)>, the element carrying the data related to the
	'ALPHANUMERIC' this value indicates the minimum number of		key as defined in Section 5.3.1
	digits/characters.
	If the Format attribute is 'BASE64' or 'BINARY', this value		o <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the
	indicates the minimum number of bytes of the unencoded value.		usage of this key as defined in Section 5.3.4
	Value MUST be:		o <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not
			be possible to use this key after this date
	Unsigned integer.		o <StartDate (OPTIONAL)>, the start date of the key, it MUST not be
			possible to use this key before this date
	4. Max (MANDATORY)		5.3.1. Data (OPTIONAL)
	Defines the maximum size of the challenge accepted by the		Defines the data attributes of the symmetric key. Each is a name
	device for CR mode.		value pair which has either a plain value (in case of no encryption)
			or an encrypted value as defined in EncryptedDataType in XML
			Encryption.
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or		This is also where the key value is transported, Section 7 defines a
	'ALPHANUMERIC' this value indicates the maximum number of		list of reserved attribute names.
	digits/characters.
	If the Format attribute is 'BASE64' or 'BINARY', this value		Data element is defined as follows:
	indicates the maximum number of bytes of the unencoded value.
	Value MUST be:		<xs:complexType name="DataType">
			<xs:sequence>
			<xs:choice>
			<xs:element name="PlainValue" type="xs:base64Binary"/>
			<xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>
			</xs:sequence>
			<xs:attribute name="Name" type="xs:string" use="required"/>
			</xs:complexType>
	Unsigned integer.		The attributes of the Data element have the following meanings:
	5.1.10.2. ResponseFormat (MANDATORY)		o Name, defines the name of the name-value pair, Section 7 defines a
			list of reserved attribute names
	The ResponseFormat attribute defines the characteristics of the		The elements of the Data element have the following meanings:
	result of a computation. This defines the format of the OTP or of
	the response to a challenge. The Response attribute is defined by
	the following sub-attributes:
	1. Format (MANDATORY)		o The <PlainValue> conveys an unencrypted value of the name-value
			pair in base 64 encoding.
	Defines the format of the response generated by the device and		o The <EncryptedValue> element in the DataType conveys an encrypted
	MUST be one of the values defined in Section 6.3		value of the name-value pair inside an EncryptedDataType as
			defined in XML Encryption.
	2. CheckDigit (OPTIONAL)		o The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed
			MAC value of the unencrypted data for the cases where the key
			protection algorithm does not support integrity checks
	Defines if the device needs to append a Luhn check digit to		5.3.2. Usage (MANDATORY)
	the response. This is only valid if the Format attribute is
	'DECIMAL'. Value MUST be:
	TRUE device will append a Luhn check digit to the response.		The Usage element defines the usage attribute(s) of the key entity.
			Usage is defined as follows:
	FALSE device will not append a Luhn check digit to the		<xs:complexType name="UsageType">
	response.		<xs:sequence>
			<xs:element name="ResponseFormat">
			<xs:complexType>
			<xs:attribute name="Format"
			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="ChallengeFormat" minOccurs="0">
			<xs:complexType>
			<xs:attribute name="Format"
			type="pskc:ValueFormatType" use="required"/>
			<xs:attribute name="Min"
			type="xs:unsignedInt" use="required"/>
			<xs:attribute name="Max"
			type="xs:unsignedInt" use="required"/>
			<xs:attribute name="CheckDigits"
			type="xs:boolean" default="false"/>
			</xs:complexType>
			</xs:element>
			</xs:sequence>
			<xs:attribute name="OTP" type="xs:boolean" default="false"/>
			<xs:attribute name="CR" type="xs:boolean" default="false"/>
			<xs:attribute name="Integrity" type="xs:boolean" default="false"/>
			<xs:attribute name="Encrypt" type="xs:boolean" default="false"/>
			<xs:attribute name="Unlock" type="xs:boolean" default="false"/>
			</xs:complexType>
	3. Length (MANDATORY)		The attributes of the Usage element define the intended usage of the
			key and are a combination of one or more of the following (set to
			true):
	Defines the length of the response generated by the device.		o OTP, the key will be used for OTP generation
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or		o CR, the key will be used for Challenge/Response purposes
	'ALPHANUMERIC' this value indicates the number of digits/
	characters.
	If the Format attribute is 'BASE64' or 'BINARY', this value		o Encrypt, the key will be used for data encryption purposes
	indicates the number of bytes of the unencoded value.
	Value MUST be:		o Integrity, the key will be used to generate a keyed message digest
			for data integrity or authentication purposes.
	Unsigned integer.		o Unlock, the key will be used for an inverse challenge response in
			the case a user has locked the device by entering a wrong PIN too
			many times (for devices with PIN-input capability)
	5.1.10.3. AppProfileId (OPTIONAL)		5.3.2.1. OTP and CR specific Usage elements (OPTIONAL)
	Defines the application profile id related to attributes present on a		When the key usage is set to OTP or CR, additional attributes MUST be
	smart card that have influence when computing a response. An example		provided to support the OTP and/or the response computation as
	could be an EMV MasterCard CAP [CAP] application on a card that		required by the underlying algorithm and to customize or configure
	contains attributes or uses fixed data for a specific batch of cards		the outcome of the computation (format, length and usage modes).
	such as:
	IAF Internet authentication flag		5.3.2.1.1. ChallengeFormat element (MANDATORY)
	CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA		The ChallengeFormat element defines the characteristics of the
	13, VISA14)		challenge in a CR usage scenario. The Challenge element is defined
			by the following attributes:
	AIP (Application Interchange Profile), 2 bytes		o Format (MANDATORY)
	TVR Terminal Verification Result, 5 bytes		Defines the format of the challenge accepted by the device and
			MUST be one of the values defined in Section 5.3.3
	CVR The card verification result		o CheckDigit (OPTIONAL)
	AmountOther		Defines if the device needs to check the appended Luhn check
			digit contained in a provided challenge. This is only valid if
			the Format attribute is 'DECIMAL'. Value MUST be:
	TransactionDate		TRUE device will check the appended Luhn check digit in a
			provided challenge
	TerminalCountryCode		FALSE device will not check appended Luhn check digit in
			challenge
	TransactionCurrencyCode		o Min (MANDATORY)
	AmountAuthorised		Defines the minimum size of the challenge accepted by the
			device for CR mode.
	IIPB		If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
			'ALPHANUMERIC' this value indicates the minimum number of
			digits/characters.
	These values are not contained within attributes in the container but		If the Format attribute is 'BASE64' or 'BINARY', this value
	are shared between the manufacturing and the validation service		indicates the minimum number of bytes of the unencoded value.
	through this unique AppProfileId.
	5.1.11. Logo (OPTIONAL)		Value MUST be:
	Specifies the logo image information associated with a key. The logo		Unsigned integer.
	type is defined in a separate schema file with namespace
	urn:ietf:params:xml:ns:keyprov:logo:1.0.
	6. Key container XML schema definitions		o Max (MANDATORY)
	The portable key container is defined by the following entities:		Defines the maximum size of the challenge accepted by the
			device for CR mode.
	1. KeyContainer entity		If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
			'ALPHANUMERIC' this value indicates the maximum number of
			digits/characters.
	2. Device entity		If the Format attribute is 'BASE64' or 'BINARY', this value
			indicates the maximum number of bytes of the unencoded value.
	3. Key entity		Value MUST be:
	4. User entity		Unsigned integer.
	A KeyContainer MAY contain one or more Device entities. A Device MAY		5.3.2.1.2. ResponseFormat element (MANDATORY)
	contain one or more Key entities and may be associated to one or more
	User entities.
	The figure below indicates a possible relationship diagram of a		The ResponseFormat element defines the characteristics of the result
	container.		of a computation. This defines the format of the OTP or of the
			response to a challenge. The Response attribute is defined by the
			following attributes:
	--------------------------------------------		o Format (MANDATORY)
	| KeyContainer |
	| |
	| ------------------ ----------------- |
	| | Device 1 | | Device n | |
	| | | | | |
	| | ------------ | | ------------ | |
	| | | Key 1 | | | | Key n | | |
	| | ------------ | | ------------ | |
	| | | | | |
	| | | | | |
	| | ------------ | | ------------ | |
	| | | Key m | | | | Key p | | |
	| | ------------ | | ------------ | |
	| ------------------ ----------------- |
	| | | | |
	| | | | |
	| ---------- ---------- ---------- |
	| | User 1 | | User 1 | | User n | |
	| ---------- ---------- ---------- |
	| |
	--------------------------------------------
	6.1. XML Schema Types		Defines the format of the response generated by the device and
			MUST be one of the values defined in Section 5.3.3
	The following types are defined to represent the portable key		o CheckDigit (OPTIONAL)
	container entities and associated attributes.
	6.1.1. KeyType		Defines if the device needs to append a Luhn check digit to the
			response. This is only valid if the Format attribute is
			'DECIMAL'. Value MUST be:
	The KeyType represents the key entity in the KeyContainer. The		TRUE device will append a Luhn check digit to the response.
	KeyType is defined as follows:
	<complexType name="KeyType">		FALSE device will not append a Luhn check digit to the
	<sequence>		response.
	<element name="Issuer" type="string"/>
	<element name="Usage" type="pskc:UsageType"/>
	<element name="FriendlyName" type="string" minOccurs="0"/>
	<element name="Data" type="pskc:DataType" minOccurs="0"
	maxOccurs="unbounded"/>
	<element name="AccessRules" minOccurs="0">
	<complexType>
	<simpleContent>
	<extension base="string">
	<attribute name="UserPIN" type="boolean"
	default="false"/>
	</extension>
	</simpleContent>
	</complexType>
	</element>
	<element name="Logo" type="logo:LogoType" minOccurs="0"/>
	<element name="Expiry" type="string" minOccurs="0"/>
	</sequence>
	<attribute name="KeyId" type="string" use="required"/>
	<attribute name="KeyAlgorithm" type=
	"pskc:KeyAlgorithmType" use="required"/>
	</complexType>
	The components of the KeyType have the following meanings (see		o Length (MANDATORY)
	Section 5 for further information):		Defines the length of the response generated by the device.
	o <Usage> of type UsageType defines the usage of the Secret Key. The		If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
	Usage attribute is described in Section 5.1.3.		'ALPHANUMERIC' this value indicates the number of digits/
			characters.
	o <Issuer> identifies the issuer of the Secret Key. The Issuer		If the Format attribute is 'BASE64' or 'BINARY', this value
	attribute is described in Section 5.1.5.		indicates the number of bytes of the unencoded value.
	o <FriendlyName> is a user friendly name that is assigned to the		Value MUST be:
	Secret Key for easy reference.
	o <Data> conveys the data attributes (eg the Secret Key) in name		Unsigned integer.
	(string) value (base64 encoded) pairs. The value can be
	encrypted, in this case a digest of the non-encrypted data is
	present. The <Data> component is further described below.
	o <AccessRules> Defines the rules for accessing the credential on		5.3.3. ValueFormat
	the device e.g. a password must be provided by the user to view
	credential info or use the credential to generate an OTP response
	o KeyId is a global identifier of the Secret Key. See Section 5.1.4.		The ValueFormat element defines allowed formats for challenges or
			responses in OTP algorithms.
	o KeyAlgorithm defines the algorithm used with the Secret Key. The		ValueFormat is defined as follows:
	type values are defined in Section 6.2.
	o Logo of type LogoType associates display logos with this Secret		<simpleType name="ValueFormat">
	Key		<restriction base="string">
			<enumeration value="DECIMAL"/>
			<enumeration value="HEXADECIMAL"/>
			<enumeration value="ALPHANUMERIC"/>
			<enumeration value="BASE64"/>
			<enumeration value="BINARY"/>
			</restriction>
			</simpleType>
	o Expiry defines the expiry date of the Secret Key in format DD/MM/		DECIMAL Only numerical digits
	YYYY
	The <Data> element is of type <DataType> and is defined as follows:		HEXADECIMAL Hexadecimal response
	<complexType name="DataType">		ALPHANUMERIC All letters and numbers (case sensitive)
	<sequence>
	<element name="Value" type="base64Binary"/>
	<element name="ValueDigest" type="base64Binary" minOccurs="0"/>
	<attribute name="Name" type="string" use="required"/>
	</sequence>
	</complexType>
	The 'Name' attribute defines the name of the name-value pair, the		BASE64 Base 64 encoded
	following list of attribute names have been reserved:
	SECRET: the key key value in binary, base64 encoded		BINARY Binary data, this is mainly used in case of connected
			devices
	COUNTER: the event counter for event based OTP algorithms. 8 bytes		5.3.4. PINPolicy
	unsigned integer in big endian (i.e. network byte order) form
	base64 encoded
	TIME: the time for time based OTP algorithms. 8 bytes unsigned		The PINPolicy element defines a mean to define how the usage of a
	integer in big endian (i.e. network byte order) form base64		specific key is protected by a PIN. The PIN itself can be
	encoded (Number of seconds since 1970)		transmitted using the container as another Key
	TIME_INTERVAL: the time interval value for time based OTP		PINPolicy is defined as follows:
	algorithms. 8 bytes unsigned integer in big endian (i.e. network
	byte order) form base64 encoded.
	The <Value> element in the DataType conveys the value of the name-		<xs:complexType name="PINPolicyType">
	value pair in base 64 encoding. The value MAY be encrypted or in		<xs:sequence>
	clear text as per the EncryptionMethod data element in the		<xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
	KeyContainer (see Section 6.1.6 for details about KeyContainerType).		<xs:element name="WrongPINtry" type="xs:unsignedInt"
	When the value is encrypted, the digest value in 'ValueDigest' MUST		minOccurs="0"/>
	be provided. The digest MUST be calculated on the unencrypted value		</xs:sequence>
	and MUST use the Digest algorithms specified in DigestMethodType		<xs:attribute name="PINKeyId" type="xs:string" use="required"/>
	element of the KeyContainer. The MAC key for the MAC calculation		</xs:complexType>
	should use the same key as the encryption key specified in the
	EncryptionMethod unless a separate MAC key is specified. When PBE
	method is used for encryption, a different password is recommended
	for the MAC key derivation. When the key data is in clear text, the
	KeyContainer payload signature MAY be used to check the integrity of
	the key octets.
	6.1.2. UsageType		The attributes of PINPolicy have the following meaning
	The UsageType defines the usage attribute of the key entity. The		o PINKeyId, the unique key Id within this container that contains
	UsageType is defined as follows:		the value of the PIN that protects the key
	<complexType name="UsageType">		The elements of PINPolicy have the following meaning
	<sequence>
	<element name="ResponseFormat">
	<complexType>
	<attribute name="Format" type="pskc:ValueFormat"
	use="required"/>
	<attribute name="Length" type="unsignedInt"
	use="required"/>
	<attribute name="CheckDigits" type="boolean"
	default="false"/>
	</complexType>
	</element>
	<element name="ChallengeFormat" minOccurs="0">
	<complexType>
	<attribute name="Format" type="pskc:ValueFormat"
	use="required"/>
	<attribute name="Min" type="unsignedInt" use="required"/>
	<attribute name="Max" type="unsignedInt" use="required"/>
	<attribute name="CheckDigits" type="boolean"
	default="false"/>
	</complexType>
	</element>
	<element name="AppProfileId" type="string" minOccurs="0"/>
	</sequence>
	<attribute name="OTP" type="boolean"
	default="false"/>
	<attribute name="CR" type="boolean"
	default="false"/>
	<attribute name="Sign" type="boolean" default="false"/>
	<attribute name="Encrypt" type="boolean" default="false"/>
	<attribute name="Unlock" type="boolean" default="false"/>
	</complexType>
	The UsageType components have the following meanings:		o <PINUsageMode>, the way the PIN is used during the usage of the
			key as defined in Section 5.3.4.1
	o <ResponseFormat> holds the algorithm response attributes.		o <WrongPINtry>, the number of times the PIN can be entered wrongly
			before it MUST not be possible to use the key anymore
	o <ChallengeFormat> hold the challenge attributes in CR based		5.3.4.1. PINUsageMode
	algorithm computations.
	o <AppProfileId> Is the unique shared identifier for out of band		The PINUsageMode element defines how the PIN is used with a specific
	shared common parameters.		key
	6.1.3. DeviceType		PINUsageMode is defined as follows:
	The DeviceType type represents the Device entity in the Container. A		<xs:complexType name="PINUsageModeType">
	Device MAY be bound to a user and MAY contain more than one keys. It		<xs:choice maxOccurs="unbounded">
	is recommended that a key is bound to one and only one Device.		<xs:element name="Local"/>
			<xs:element name="Prepend"/>
			<xs:element name="InAlgo"/>
			</xs:choice>
			</xs:complexType>
	The DeviceType is defined as follows:		The elements of PINPolicy have the following meaning
	<complexType name="DeviceType">		o <Local>, the PIN is checked locally on the device before allowing
	<sequence>		the key to be used in executing the algorithm
	<element name="DeviceId" type="pskc:DeviceIdType"
	minOccurs="0"/>
	<element name="Key" type="pskc:KeyType"
	maxOccurs="unbounded"/>
	<element name="User" type="pskc:UserType" minOccurs="0"/>
	</sequence>
	</complexType>
	The components of the DeviceType have the following meanings:		o <Prepend>, the PIN is prepended to the OTP or response hance it
			MUST be chacked by the validation server
	o <DeviceId>, a unique identifier for the device, defined by the		o <InAlgo>, the PIN is used as part of the algorithm computation
	DeviceId type.
	o <Key>, represents the key entity defined by the KeyType.		6. Usage and profile of algorithms for the portable symmetric key
			container
	o <User>, optionally identifies the owner or the user of the Device,		This section details the use of the XML encryption and XML signature
	as defined by the UserType .		elements to protect the keys transported in the cotainer. It also
			profiles the number of algorithms supported by XML encryption and XML
			signature to a mandatory subset for interoperability.
	6.1.4. DeviceIdType		When no algorithm is provided the values within the container are
			unencrypted, implementations SHALL ensure the privacy of the key data
			through other standard mechanisms e.g. transport level encryption.
	The DeviceId type represents the identifying criteria to uniquely		6.1. Usage of EncryptionKey to protect keys in transit
	identify the device that contains the associated keys. Since devices
	can come in different form factors such as hardware tokens,
	smartcards, soft tokens in a mobile phone or PC etc this type 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 will uniquely identify a
	device but not SerialNo alone since two different token manufacturers
	might issue devices with the same serial number (similar to the
	IssuerDN and serial number of a certificate). For keys hold on
	banking cards the identification of the device is often done via the
	Primary Account Number (PAN, the big number printed on the front of
	the card) and an expiry date of the card. DeviceId is an extensible
	type that allows all these different ways to uniquely identify a
	specific key containing device.
	The DeviceIdType is defined as follows:		The EncryptionKey element in the KeyContainer defines the key,
			algorithm and parameters used to encrypt the Secret Key data
			attributes in the Container. The encryption is applied on each
			individual Secret Key data in the Container. The encryption method
			MUST be the same for all Secret Key data in the container.
	<complexType name="DeviceIdType">		The following sections define specifically the different supported
	<sequence>		means to protect the keys:
	<element name="Manufacturer" type="string"/>
	<element name="SerialNo" type="string"/>
	<element name="Model" type="string" minOccurs="0"/>
	<element name="IssueNo" type="string" minOccurs="0"/>
	<element name="Expiry" type="string" minOccurs="0"/>
	</sequence>
	</complexType>
	The components of the DeviceId type have the following meanings:		6.1.1. Protecting keys using a pre-shared key via symmetric algorithms
	o <Manufacturer>, the manufacturer of the device.		When protecting the payload with pre-shared keys implementations
			SHOULD set the name of the specific pre-shared key in the KeyName
			element of the EncryptionKey of the KeyContainer. For example:
	o <Model>, the model of the device (e.g one-button-HOTP-token-V1)		<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
			<EncryptionKey>
			<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
			</EncryptionKey>
			....
	o <SerialNo>, the serial number of the device or the PAN (primary		The following is the list of symmetric key encryption algorithm and
	account number) in case of EMV (Europay-MasterCard-Visa) smart		possible parameters used to protect the Secret Key data in the
	cards.		container. Systems implementing PSKC MUST support the MANDATORY
			algorithms detailed below.
	o <IssueNo>, the issue number in case of smart cards with the same		The encryption algorithm URI can be one of the following.
	PAN, equivalent to a PSN (PAN Sequence Number).
	o <Expiry>, the expiry date of a device (such as the one on an EMV		o http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY
	card,used when issue numbers are not printed on cards). In format		o http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY
	DD/MM/YYYY
	6.1.5. UserType Type		o http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL
	The UserType represents the identifying criteria to uniquely identify		o http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY
	the user who is bound to this device.
	The UserType is defined as follows:		o http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY
	<complexType name="UserType">		o http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY
	<sequence>
	<sequence>
	<element name="UserId" type="string" minOccurs="0"/>
	<element name="FirstName" type="string" minOccurs="0"/>
	<element name="LastName" minOccurs="0"/>
	</sequence>
	<element name="Org" type="string" minOccurs="0"/>
	</sequence>
	</complexType>
	The components of the UserType type have the following meanings:		o http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY
	o <FirstName>, user first name.		o http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL
	o <LastName>, user last name.		When algorithms without integrity checks are used (e.g.
			http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value using
			the same key as the encryption key SHOULD be placed in the ValueMAC
			element of the Data element. In this case the MAC algorithm type
			MUST be set in the MACAlgorithm element in the key container entity
			as defined in Section 5.1. Implementations of PSKC MUST support the
			MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be
			one of the following:
	o <UserId>, user id (UID) or user name.		o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY
	o <Org>, user organization name.		For example:
	6.1.6. KeyContainerType		<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
			<EncryptionKey>
			<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
			</EncryptionKey>
			<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
			</MACAlgorithm>
			.....
	The KeyContainerType represents the key container entity. A		6.1.2. Protecting keys using passphrase based encryption keys
	Container MAY contain more than one Device entity; each Device entity
	MAY contain more than one Key entity.
	The KeyContainerType is defined as follows:		To be able to support passphrase based encryption keys as defined in
			PKCS#5 the following XML representation of the PBE relates parameters
			have been introduced in the schema. Although the approach is
			extensible implementations of PSKC MUST support the
			KeyDerivationMethod algorithm URI of
			http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2.
	<complexType name="KeyContainerType">		<xs:complexType name="DerivedKeyType">
	<sequence>		<xs:sequence>
	<element name="EncryptionMethod" minOccurs="0">		<xs:element name="KeyDerivationMethod"
	<complexType>		type="pskc:KeyDerivationMethodType" minOccurs="0"/>
	<complexContent>		<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
	<extension base="pskc:EncryptionMethodType"/>		<xs:element name="CarriedKeyName" type="xs:string"
	</complexContent>		minOccurs="0"/>
	</complexType>		</xs:sequence>
	</element>		<xs:attribute name="Id" type="xs:ID" use="optional"/>
	<element name="DigestMethod">		<xs:attribute name="Type" type="xs:anyURI" use="optional"/>
	<complexType>		</xs:complexType>
	<complexContent>		<xs:complexType name="KeyDerivationMethodType">
	<extension base="pskc:DigestMethodType"/>		<xs:sequence>
	</complexContent>		<xs:any namespace="##other" minOccurs="0"
	</complexType>
	</element>
	<element name="Device" type="pskc:DeviceType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<element name="Signature" type="ds:SignatureType"		</xs:sequence>
	minOccurs="0"/>		<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
	</sequence>		</xs:complexType>
	<attribute name="Version" type="pskc:VersionType" use="required"/>
	</complexType>
	The components of the KeyContainer have the following meanings:
	o Version, the version number for the portable key container format
	(the XML schema defined in this document).
	o <EncryptionMethod>, the encryption method used to protect the Key
	data attributes
	o <DigestMethod>, the digest method used to sign the unencrypted the
	Secret Key data attributes
	o <Device>, the host Device for one or more Keys.
	o <Signature>, contains the signature value of the Container. When
	the signature is applied to the entire container, it MUST use XML
	Signature methods as defined in [XMLSIG]. The signature is
	enveloped.
	6.1.7. EncryptionMethodType		The attributes of the DerivedKey have the following meanings:
	The EncryptionMethodType defines the algorithm and parameters used to		o ID (OPTIONAL), the unique ID for this key
	encrypt the Secret Key data attributes in the Container. The
	encryption is applied on each individual Secret Key data in the
	Container. The encryption method MUST be the same for all Secret Key
	data in the container.
	The EncryptionMethodType is defined as follows:		o Type (OPTIONAL), TODO
	<complexType name="EncryptionMethodType">		The elements of the DerivedKey have the following meanings:
	<sequence>
	<element name="EncKeyLabel" minOccurs="0"/>
	<choice>
	<sequence>
	<element name="KeyInfo"
	type="ds:KeyInfoType" minOccurs="0"/>
	<element name="OAEPParams"
	type="base64Binary" minOccurs="0"/>
	</sequence>
	<sequence>
	<element name="PBEEncryptionParam"
	type="pskc:PBEEncryptionParamType" minOccurs="0"/>
	<element name="IV" type="base64Binary" minOccurs="0"/>
	</sequence>
	<any namespace="##other" processContents="strict"/>
	</choice>
	</sequence>
	<attribute name="Algorithm"
	type="anyURI" use="required"/>
	</complexType>
	<complexType name="PBEEncryptionParamType">		o <KeyDerivationMethod>: URI of the algorithms used to derive the
	<sequence>		key e.g.
	<element name="PBESalt" type="base64Binary"		(http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)
	minOccurs="0"/>
	<element name="PBEIterationCount" type="int"
	minOccurs="0"/>
	</sequence>
	<attribute name="EncryptionAlgorithm" type="anyURI"/>
	</complexType>
	The components of the EncryptionMethodType have the following		o <ReferenceList (OPTIONAL)>: a list of IDs of the elements that
	meanings:		have been encrypted by this key
	o <EncKeyLabel>: identifies a unique label for a pre-shared		o <CarriedKeyName (OPTIONAL)>: friendly name of the key
	encryption key.
	o Algorithm: identifies the encryption algorithm used to protect the		When using the PKCS5 PBE algorithm
	Secret Key data. If EncryptionMethod is absent in		(URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
	KeyContainerType, implementations MUST guarantee the privacy of		and related parameters, the DerivedKey element MUST be used within
	the Secret Key Data through other mechanisms e.g. through		the EncryptionKey element of the KeyContainer in exactly the form as
	transport level security.		shown below:
	o <KeyInfo>: conveys the information of the key if an RSA algorithm		<?xml version="1.0" encoding="UTF-8"?>
	has been used.		<KeyContainer
			xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:pkcs-5=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
			Version="1.0">
			<EncryptionKey>
			<DerivedKey Id="#Passphrase1">
			<CarriedKeyName>Passphrase1</CarriedKeyName>
			<KeyDerivationMethod
			Algorithm=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
			<Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
			<Salt>
			<Specified>Df3dRAhjGh8=</Specified>
			</Salt>
			<IterationCount>2000</IterationCount>
			<KeyLength>16</KeyLength>
			<PRF/>
			</Parameters>
			</KeyDerivationMethod>
			</DerivedKey>
			</EncryptionKey>
			....
	o <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has		6.2. Protecting keys using asymmetric algorithms
	been used.
	o <PBEEncryptionParam>: conveys the PBE parameters if a password-		The following is the list of asymmetric key encryption algorithm and
	based encryption (PBE) algorithm has been used.		possible parameters used to protect the Secret Key data in the
			container. Systems implementing PSKC MUST support the MANDATORY
			algorithms detailed below. The encryption algorithm URI can be one
			of the following.
	o		o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY
	* <PBESalt>: conveys the Salt when [PKCS5] password-based		o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL
	encryption is applied.
	* <PBEIterationCount>: conveys the iteration count value in		For example:
	[PKCS5] password-based encryption if it is different from the
	default value.
	* <EncryptionAlgorithm>: specifies the encryption algorithm after		TODO
	a PBE key is derived. For example, PBE-AES128-CBC should use
	URI http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc
	o <IV>: conveys the initialization vector for CBC based encryption		6.3. Profile of Key Algorithm
	algorithms. It is recommended for security reasons to transmit
	this value out of band and treat it the same manner as the key
	value.
	6.1.8. DigestMethodType		This section profiles the type(s) of algorithm of that can be used by
			the key(s) transported in the container. The following algorithm
			URIs are among the default support list.
	The DigestMethodType defines the algorithm and parameters used to		o http://www.w3.org/2001/04/xmlenc#tripledes-cbc
	create the digest on the unencrypted Secret Key data in the
	Container. The digest is applied on each individual Secret Key data
	in the Container before encryption. The digest method MUST be the
	same for all Secret Key data in the container. Unless a different
	digest key is specified it is assumed that keyed digest algorithms
	will use the same key as for encryption
	The DigestMethodType is defined as follows:		o http://www.w3.org/2001/04/xmlenc#aes128-cbc
	<complexType name="DigestMethodType">		o http://www.w3.org/2001/04/xmlenc#aes192-cbc
	<sequence>
	<element name="DigestKeyLabel" minOccurs="0"/>
	</sequence>
	<attribute name="Algorithm"
	type="anyURI" use="required"/>
	</complexType>
	The components of the DigestMethodType have the following meanings:		o http://www.w3.org/2001/04/xmlenc#aes256-cbc
	o Algorithm, identifies the digest algorithm used to protect the		o http://www.ietf.org/keyprov/pskc#hotp
	Secret Key data.
	o <DigestKeyLabel>: identifies a unique label for a pre-shared		o http://www.ietf.org/keyprov/pskc#valuecompare
	digest key.
	6.2. KeyAlgorithmType		6.3.1. OTP Key Algorithm Identifiers
	The KeyAlgorithmType defines the algorithms in which the Secret Key		OTP key algorithm URIs have not been defined in a commonly available
	data is used. It refers to anyURI.		standard specification. This document defines the following URIs for
			the known open standard OTP algorithms.
	6.3. ValueFormat		6.3.1.1. HOTP
	The ValueFormat defines allowed formats for challenges or responses		Standard document: RFC4226
	in the OTP algorithms.
	The ValueFormat is defined as follows:		Identifier: http://www.ietf.org/keyprov/pskc#hotp
	<simpleType name="ValueFormat">		Note that the actual URL will be finalized once a URL for this
	<restriction base="string">		document is determined.
	<enumeration value="DECIMAL"/>
	<enumeration value="HEXADECIMAL"/>
	<enumeration value="ALPHANUMERIC"/>
	<enumeration value="BASE64"/>
	<enumeration value="BINARY"/>
	</restriction>
	</simpleType>
	DECIMAL Only numerical digits		6.3.1.2. Other OTP Algorithms
	HEXADECIMAL Hexadecimal response		An implementation should refer to vendor supplied OTP key algorithm
			URIs for proprietary algorithms.
	ALPHANUMERIC All letters and numbers (case sensitive)		6.3.2. PIN key value compare algorithm identifier
	BASE64 Base 64 encoded		PIN key algorithm URIs have not been defined in a commonly available
			standard specification. This document defines the following URIs for
			a straight value comaprison of the transported secret key data as
			when required to compare a PIN.
	BINARY Binary data, this is mainly used in case of connected		Identifier: http://www.ietf.org/keyprov/pskc#valuecompare
	devices
	6.4. Data elements		Note that the actual URL will be finalized once a URL for this
			document is determined.
	6.4.1. KeyContainer		7. Reserved data attribute names
	The KeyContainer data element is defined as:		The following key data attribute names have been reserved:
	<element name="KeyContainer" type="pskc:KeyContainerType"/>		SECRET: the shared secret key value in binary, base64 encoded
	The KeyContainer data element is of type KeyContainerType defined in		COUNTER: the event counter for event based OTP algorithms. 8 bytes
	Section 6.1.6.		unsigned integer in big endian (i.e. network byte order) form
			base64 encoded
	The EncryptionMethod data element in the KeyContainer defines the		TIME: the time for time based OTP algorithms. 8 bytes unsigned
	encryption algorithm used to protect the Key data. In a multi-key		integer in big endian (i.e. network byte order) form base64
	KeyContainer, the same encryption method and the same encryption key		encoded (Number of seconds since 1970)
	MUST be used for all key data elements.
	The KeyContainer data element MAY contain multiple Device data		TIME_INTERVAL: the time interval value for time based OTP
	elements, allowing for bulk provisioning of keys.		algorithms. 8 bytes unsigned integer in big endian (i.e. network
			byte order) form base64 encoded.
	The Signature data element is of type <ds:Signature> as defined in		TIME_DRIFT: the device clock drift value for time based OTP
	[XMLSIG] and MAY be omitted in the KeyContainer data element when		algorithms. The value indicates number of seconds that the device
	application layer provisioning or transport layer provisioning		clock may drift each day. 2 bytes unsigned integer in big endian
	protocols provide the integrity and authenticity of the payload		(i.e. network byte order) form base64 encoded.
	between the sender and the recipient of the container. When
	required, this specification recommends using a symmetric key based
	signature with the same key used in the encryption of the secret key
	data. The signature is enveloped.
	7. Formal Syntax		8. Formal Syntax
	The following syntax specification uses the widely adopted XML schema		The following syntax specification uses the widely adopted XML schema
	format as defined by a W3C recommendation		format as defined by a W3C recommendation
	(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax		(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
	definition in the XML Schema Definition format (XSD)		definition in the XML Schema Definition format (XSD)
	All implementations of this standard must comply with the schema		All implementations of this standard must comply with the schema
	below.		below.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	skipping to change at page 31, line 16 ¶		skipping to change at page 31, line 16 ¶
	The following syntax specification uses the widely adopted XML schema		The following syntax specification uses the widely adopted XML schema
	format as defined by a W3C recommendation		format as defined by a W3C recommendation
	(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax		(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
	definition in the XML Schema Definition format (XSD)		definition in the XML Schema Definition format (XSD)
	All implementations of this standard must comply with the schema		All implementations of this standard must comply with the schema
	below.		below.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
	xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.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#"
	targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0"		targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0"
	elementFormDefault="qualified" attributeFormDefault="unqualified"		elementFormDefault="qualified" attributeFormDefault="unqualified"
	version="1.0">		version="1.0">
			<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"		schemaLocation=
	schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/		"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
	xmldsig-core-schema.xsd"/>		xmldsig-core-schema.xsd"/>
			<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
			schemaLocation="http://www.w3.org/TR/2002/
			REC-xmlenc-core-20021210/xenc-schema.xsd"/>
	<xs:import namespace="urn:ietf:params:xml:ns:keyprov:logo:1.0"		<xs:complexType name="KeyContainerType">
	schemaLocation="keyprov-logo-1.0.xsd"/>
	<xs:complexType name="KeyContainerType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="EncryptionMethod" minOccurs="0">		<xs:element name="EncryptionKey" type="ds:KeyInfoType"
	<xs:complexType>		minOccurs="0"/>
	<xs:complexContent>		<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
	<xs:extension base="pskc:EncryptionMethodType"/>		minOccurs="0"/>
	</xs:complexContent>		<xs:element name="Device" type="pskc:DeviceType"
	</xs:complexType>		maxOccurs="unbounded"/>
	</xs:element>		<xs:element name="Signature" type="ds:SignatureType"
	<xs:element name="DigestMethod" minOccurs="0">		minOccurs="0"/>
	<xs:complexType>
	<xs:complexContent>
	<xs:extension base="pskc:DigestMethodType"/>
	</xs:complexContent>
	</xs:complexType>
	</xs:element>
	<xs:element name="Device" type="pskc:DeviceType"
	maxOccurs="unbounded"/>
	<xs:element name="Signature" type="ds:SignatureType"
	minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="pskc:VersionType"		<xs:attribute name="Version" type="pskc:VersionType"
	use="required"/>		use="required"/>
	</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:sequence>
	<xs:complexType name="KeyType">		<xs:element name="Issuer" type="xs:string" minOccurs="0"/>
	<xs:sequence>		<xs:element name="Usage" type="pskc:UsageType"/>
	<xs:element name="Issuer" type="xs:string"/>		<xs:element name="CardAppPersoProfileId" type="xs:string"
	<xs:element name="Usage" type="pskc:UsageType"/>		minOccurs="0"/>
	<xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>		<xs:element name="FriendlyName" type="xs:string"
	<xs:element name="Data" type="pskc:DataType"		minOccurs="0"/>
	minOccurs="0" maxOccurs="unbounded"/>		<xs:element name="Data" type="pskc:DataType" minOccurs="0"
	<xs:element name="AccessRules" minOccurs="0">		maxOccurs="unbounded"/>
	<xs:complexType>		<xs:element name="PINPolicy" type="pskc:PINPolicyType"
	<xs:simpleContent>		minOccurs="0"/>
	<xs:extension base="xs:string">		<xs:element name="ExpiryDate" type="xs:dateTime"
	<xs:attribute name="UserPIN" type="xs:boolean"		minOccurs="0"/>
	default="false"/>		<xs:element name="StartDate" type="xs:dateTime"
	</xs:extension>		minOccurs="0"/>
	</xs:simpleContent>		</xs:sequence>
	</xs:complexType>		<xs:attribute name="KeyId" type="xs:string" use="required"/>
	</xs:element>		<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
	<xs:element name="Logo" type="logo:LogoType" minOccurs="0"/>		use="required"/>
	<xs:element name="Expiry" type="xs:string" minOccurs="0"/>		</xs:complexType>
	</xs:sequence>		<xs:complexType name="DerivedKeyType">
	<xs:attribute name="KeyId" type="xs:string" use="required"/>		<xs:sequence>
	<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"		<xs:element name="KeyDerivationMethod"
	use="required"/>		type="pskc:KeyDerivationMethodType" minOccurs="0"/>
	</xs:complexType>		<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
			<xs:element name="CarriedKeyName" type="xs:string"
	<xs:complexType name="DeviceIdType">		minOccurs="0"/>
	<xs:sequence>		</xs:sequence>
	<xs:element name="Manufacturer" type="xs:string"/>		<xs:attribute name="Id" type="xs:ID" use="optional"/>
	<xs:element name="SerialNo" type="xs:string"/>		<xs:attribute name="Type" type="xs:anyURI" use="optional"/>
	<xs:element name="Model" type="xs:string" minOccurs="0"/>		</xs:complexType>
	<xs:element name="IssueNo" type="xs:string" minOccurs="0"/>		<xs:complexType name="KeyDerivationMethodType">
	<xs:element name="Expiry" type="xs:string" minOccurs="0"/>		<xs:sequence>
	</xs:sequence>		<xs:any namespace="##other" minOccurs="0"
	</xs:complexType>		maxOccurs="unbounded"/>
			</xs:sequence>
	<xs:complexType name="DeviceType">		<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
	<xs:sequence>		</xs:complexType>
	<xs:element name="DeviceId" type="pskc:DeviceIdType"		<xs:complexType name="PINPolicyType">
	minOccurs="0"/>		<xs:sequence>
	<xs:element name="Key" type="pskc:KeyType"		<xs:element name="PINUsageMode"
	maxOccurs="unbounded"/>		type="pskc:PINUsageModeType"/>
	<xs:element name="User" type="pskc:UserType"		<xs:element name="WrongPINtry" type="xs:unsignedInt"
	minOccurs="0"/>		minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		<xs:attribute name="PINKeyId" type="xs:string"
			use="required"/>
	<xs:complexType name="UserType">		</xs:complexType>
	<xs:sequence>		<xs:complexType name="PINUsageModeType">
			<xs:choice maxOccurs="unbounded">
			<xs:element name="Local"/>
			<xs:element name="Prepend"/>
			<xs:element name="Embed"/>
			</xs:choice>
			</xs:complexType>
			<xs:complexType name="DeviceIdType">
			<xs:sequence>
			<xs:element name="Manufacturer" type="xs:string"/>
			<xs:element name="SerialNo" type="xs:string"/>
			<xs:element name="Model" type="xs:string" minOccurs="0"/>
			<xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
			<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
			<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			<xs:complexType name="DeviceType">
	<xs:sequence>		<xs:sequence>
			<xs:element name="DeviceId" type="pskc:DeviceIdType"
			minOccurs="0"/>
			<xs:element name="Key" type="pskc:KeyType"
			maxOccurs="unbounded"/>
	<xs:element name="UserId" type="xs:string" minOccurs="0"/>		<xs:element name="UserId" type="xs:string" minOccurs="0"/>
	<xs:element name="FirstName" type="xs:string" minOccurs="0"/>
	<xs:element name="LastName" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	<xs:element name="Org" type="xs:string" minOccurs="0"/>		</xs:complexType>
	</xs:sequence>		<xs:complexType name="UsageType">
	</xs:complexType>
	<xs:complexType name="UsageType">
	<xs:sequence>
	<xs:element name="ResponseFormat">
	<xs:complexType>
	<xs:attribute name="Format" 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="ChallengeFormat" minOccurs="0">
	<xs:complexType>
	<xs:attribute name="Format" type="pskc:ValueFormatType"
	use="required"/>
	<xs:attribute name="Min" type="xs:unsignedInt"
	use="required"/>
	<xs:attribute name="Max" type="xs:unsignedInt"
	use="required"/>
	<xs:attribute name="CheckDigits" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	</xs:element>
	<xs:element name="AppProfileId" type="xs:string" minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="OTP" type="xs:boolean"
	default="false"/>
	<xs:attribute name="CR" type="xs:boolean"
	default="false"/>
	<xs:attribute name="Sign" type="xs:boolean"
	default="false"/>
	<xs:attribute name="Encrypt" type="xs:boolean"
	default="false"/>
	<xs:attribute name="Unlock" type="xs:boolean"
	default="false"/>
	</xs:complexType>
	<xs:complexType name="EncryptionMethodType">
	<xs:sequence>
	<xs:element name="EncKeyLabel" minOccurs="0"/>
	<xs:choice>
	<xs:sequence>		<xs:sequence>
	<xs:element name="KeyInfo"		<xs:element name="ResponseFormat">
	type="ds:KeyInfoType" minOccurs="0"/>		<xs:complexType>
	<xs:element name="OAEPParams"		<xs:attribute name="Format"
	type="xs:base64Binary" minOccurs="0"/>		type="pskc:ValueFormatType" use="required"/>
	</xs:sequence>		<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="ChallengeFormat" minOccurs="0">
			<xs:complexType>
			<xs:attribute name="Format"
			type="pskc:ValueFormatType" use="required"/>
			<xs:attribute name="Min" type="xs:unsignedInt"
			use="required"/>
			<xs:attribute name="Max" type="xs:unsignedInt"
			use="required"/>
			<xs:attribute name="CheckDigits" type="xs:boolean"
			default="false"/>
			</xs:complexType>
			</xs:element>
			</xs:sequence>
			<xs:attribute name="OTP" type="xs:boolean" default="false"/>
			<xs:attribute name="CR" type="xs:boolean" default="false"/>
			<xs:attribute name="Integrity" type="xs:boolean"
			default="false"/>
			<xs:attribute name="Encrypt" type="xs:boolean"
			default="false"/>
			<xs:attribute name="Unlock" type="xs:boolean"
			default="false"/>
			</xs:complexType>
			<xs:complexType name="DataType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="PBEEncryptionParam"		<xs:choice>
	type="pskc:PBEEncryptionParamType" minOccurs="0"/>		<xs:element name="PlainValue" type="xs:base64Binary"/>
	<xs:element name="IV" type="xs:base64Binary" minOccurs="0"/>		<xs:element name="EncryptedValue"
			type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC" type="xs:base64Binary"
			minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	<xs:any namespace="##other" processContents="strict"/>		<xs:attribute name="Name" type="xs:string" use="required"/>
	</xs:choice>		</xs:complexType>
	</xs:sequence>		<xs:simpleType name="KeyAlgorithmType">
	<xs:attribute name="Algorithm"		<xs:restriction base="xs:anyURI"/>
	type="xs:anyURI" use="required"/>		</xs:simpleType>
	</xs:complexType>		<xs:simpleType name="ValueFormatType">
			<xs:restriction base="xs:string">
	<xs:complexType name="PBEEncryptionParamType">		<xs:enumeration value="DECIMAL"/>
	<xs:sequence>		<xs:enumeration value="HEXADECIMAL"/>
	<xs:element name="PBESalt" type="xs:base64Binary"		<xs:enumeration value="ALPHANUMERIC"/>
	minOccurs="0"/>		<xs:enumeration value="BASE64"/>
	<xs:element name="PBEIterationCount" type="xs:int"		<xs:enumeration value="BINARY"/>
	minOccurs="0"/>		</xs:restriction>
	</xs:sequence>		</xs:simpleType>
	<xs:attribute name="EncryptionAlgorithm" type="xs:anyURI"/>		<xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
	</xs:complexType>
	<xs:complexType name="DigestMethodType">
	<xs:sequence>
	<xs:element name="DigestKeyLabel" minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="Algorithm"
	type="xs:anyURI" use="required"/>
	</xs:complexType>
	<xs:simpleType name="KeyAlgorithmType">
	<xs:restriction base="xs:anyURI"/>
	</xs:simpleType>
	<xs:simpleType name="ValueFormatType">
	<xs:restriction base="xs:string">
	<xs:enumeration value="DECIMAL"/>
	<xs:enumeration value="HEXADECIMAL"/>
	<xs:enumeration value="ALPHANUMERIC"/>
	<xs:enumeration value="BASE64"/>
	<xs:enumeration value="BINARY"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:element name="KeyContainer"
	type="pskc:KeyContainerType"/>
	<xs:complexType name="DataType">
	<xs:sequence>
	<xs:element name="Value" type="xs:base64Binary"/>
	<xs:element name="ValueDigest"
	type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="Name" type="xs:string"
	use="required"/>
	</xs:complexType>
	</xs:schema>		</xs:schema>
			9. Security Considerations
	LogoType is defined in the following schema.
	<?xml version="1.0" encoding="UTF-8"?>
	<schema xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.0"
	targetNamespace="urn:ietf:params:xml:ns:keyprov:logo:1.0"
	elementFormDefault="qualified" attributeFormDefault="unqualified"
	version="1.0">
	<!-- LogoType -->
	<complexType name="LogoType">
	<annotation>
	<documentation xml:lang="en">
	Type to include logo information.
	</documentation>
	</annotation>
	<sequence>
	<element name="CommunityLogos" type="logo:LogoInfoType"
	minOccurs="0" maxOccurs="unbounded"/>
	<element name="IssuerLogo" type="logo:LogoInfoType"
	minOccurs="0"/>
	<element name="OtherLogos" type="logo:LogoInfoType"
	minOccurs="0" maxOccurs="unbounded"/>
	</sequence>
	</complexType>
	<complexType name="LogoInfoType">
	<annotation>
	<documentation xml:lang="en">
	Define logo information for a given logo. It can either embed
	full logo data information, or includes only a reference URI
	where the full log data information with type LogoDataType
	can be downloaded.
	</documentation>
	</annotation>
	<sequence>
	<choice>
	<element name="LogoData" type="logo:LogoDataType"/>
	<element name="LogReference" type="anyURI"/>
	</choice>
	</sequence>
	</complexType>
	<complexType name="LogoDataType">
	<annotation>
	<documentation xml:lang="en">
	Define logo data information for a given logo image.
	</documentation>
	</annotation>
	<sequence>
	<element name="LogoImageDetails"
	type="logo:LogoImageDetailsType"/>
	<element name="LogoImageInfo" type="logo:LogoImageInfoType"
	minOccurs="0"/>
	</sequence>
	</complexType>
	<complexType name="LogoImageDetailsType">
	<annotation>
	<documentation xml:lang="en">
	Define logo image data for a given logo image.
	</documentation>
	</annotation>
	<sequence>
	<choice>
	<element name="ImageData" type="base64Binary"/>
	<element name="ImageReference" type="anyURI"/>
	</choice>
	</sequence>
	<attribute name="MIMEType" type="logo:MIMETypeType"
	use="required"/>
	</complexType>
	<complexType name="LogoImageInfoType">
	<annotation>
	<documentation xml:lang="en">
	Define logo image parameters for a given logo image.
	</documentation>
	</annotation>
	<sequence>
	<element name="Size" type="integer" minOccurs="0"/>
	<element name="xSize" type="integer" minOccurs="0"/>
	<element name="ySize" type="integer" minOccurs="0"/>
	<element name="Resolution" type="logo:LogoImageResolutionType"
	minOccurs="0"/>
	</sequence>
	<attribute name="colored" type="boolean" default="true"/>
	<attribute name="lang" type="string" use="optional"/>
	</complexType>
	<complexType name="LogoImageResolutionType">
	<annotation>
	<documentation xml:lang="en">
	Define logo image resolution parameters.
	</documentation>
	</annotation>
	<sequence>
	<element name="NumBits" type="integer"/>
	<element name="TableSize" type="integer"/>
	</sequence>
	</complexType>
	<!-- MimeTypeType -->
	<simpleType name="MIMETypeType">
	<annotation>
	<documentation xml:lang="en">
	Can be one of the following supported image content types.
	</documentation>
	</annotation>
	<restriction base="string">
	<enumeration value="image/gif"/>
	<enumeration value="image/jpeg"/>
	</restriction>
	</simpleType>
	</schema>
	8. Security Considerations
	The portable key container carries sensitive information (e.g.,		The portable key container carries sensitive information (e.g.,
	cryptographic keys) and may be transported across the boundaries of		cryptographic keys) and may be transported across the boundaries of
	one secure perimeter to another. For example, a container residing		one secure perimeter to another. For example, a container residing
	within the secure perimeter of a back-end provisioning server in a		within the secure perimeter of a back-end provisioning server in a
	secure room may be transported across the internet to an end-user		secure room may be transported across the internet to an end-user
	device attached to a personal computer. This means that special care		device attached to a personal computer. This means that special care
	must be taken to ensure the confidentiality, integrity, and		must be taken to ensure the confidentiality, integrity, and
	authenticity of the information contained within.		authenticity of the information contained within.
	8.1. Payload confidentiality		9.1. Payload confidentiality
	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
	skipping to change at page 39, line 44 ¶		skipping to change at page 35, line 43 ¶
	key, the more secure the protection is.		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
	[Schneier].		[Schneier].
	Practical implementations should use PBESalt and PBEIterationCount		Practical implementations should use PBESalt and PBEIterationCount
	when PBE encryption is used. Different PBESalt value per credential		when PBE encryption is used. Different PBESalt value per key
	record should be used for best protection.		container should be used for best protection.
	The second approach to protecting the confidentiality of the payload		The second approach to protecting the confidentiality of the payload
	is based on using transport layer security. The secure channel		is based on using transport layer security. The secure channel
	established between the source secure perimeter (the provisioning		established between the source secure perimeter (the provisioning
	server from the example above) and the target perimeter (the device		server from the example above) and the target perimeter (the device
	attached to the end-user computer) utilizes encryption to transport		attached to the end-user computer) utilizes encryption to transport
	the messages that travel across. No payload encryption is required		the messages that travel across. No payload encryption is required
	in this mode. Secure channels that encrypt and digest each message		in this mode. Secure channels that encrypt and digest each message
	provide an extra measure of security, especially when the signature		provide an extra measure of security, especially when the signature
	of the payload does not encompass the entire payload.		of the payload does not encompass the entire payload.
	Because of the fact that the plain text payload is protected only by		Because of the fact that the plain text payload is protected only by
	the transport layer security, practical implementation must ensure		the transport layer security, practical implementation must ensure
	protection against man-in-the-middle attacks [Schneier]. Validating		protection against man-in-the-middle attacks [Schneier]. Validating
	the secure channel end-points is critically important for eliminating		the secure channel end-points is critically important for eliminating
	intruders that may compromise the confidentiality of the payload.		intruders that may compromise the confidentiality of the payload.
	8.2. Payload integrity		9.2. Payload integrity
	The portable symmetric key container provides a mean to guarantee the		The portable symmetric key container provides a mean to guarantee the
	integrity of the information it contains through digital signatures.		integrity of the information it contains through digital signatures.
	For best security practices, the digital signature of the container		For best security practices, the digital signature of the container
	should encompass the entire payload. This provides assurances for		should encompass the entire payload. This provides assurances for
	the integrity of all attributes. It also allows verification of the		the integrity of all attributes. It also allows verification of the
	integrity of a given payload even after the container is delivered		integrity of a given payload even after the container is delivered
	through the communication channel to the target perimeter and channel		through the communication channel to the target perimeter and channel
	message integrity check is no longer possible.		message integrity check is no longer possible.
	8.3. Payload authenticity		9.3. Payload authenticity
	The digital signature of the payload is the primary way of showing		The digital signature of the payload is the primary way of showing
	its authenticity. The recipient of the container may use the public		its authenticity. The recipient of the container may use the public
	key associated with the signature to assert the authenticity of the		key associated with the signature to assert the authenticity of the
	sender by tracing it back to a preloaded public key or certificate.		sender by tracing it back to a preloaded public key or certificate.
	Note that the digital signature of the payload can be checked even		Note that the digital signature of the payload can be checked even
	after the container has been delivered through the secure channel of		after the container has been delivered through the secure channel of
	communication.		communication.
	A weaker payload authenticity guarantee may be provided by the		A weaker payload authenticity guarantee may be provided by the
	transport layer if it is configured to digest each message it		transport layer if it is configured to digest each message it
	transports. However, no authenticity verification is possible once		transports. However, no authenticity verification is possible once
	the container is delivered at the recipient end. This approach may		the container is delivered at the recipient end. This approach may
	be useful in cases where the digital signature of the container does		be useful in cases where the digital signature of the container does
	not encompass the entire payload.		not encompass the entire payload.
	9. Acknowledgements		10. Acknowledgements
	The authors of this draft would like to thank the following people		The authors of this draft would like to thank the following people
	for their contributions and support to make this a better		for their contributions and support to make this a better
	specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu		specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
	Veath, Kevin Lewis, Philip Hallam-Baker, Hannes Tschofenig, Andrea		Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
	Doherty, Magnus Nystrom, Tim Moses, and Anders Rundgren.		Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders
			Rundgren.
	10. Appendix A - Example Symmetric Key Containers		11. Appendix A - Example Symmetric Key Containers
	All examples are syntactically correct and compatible with the XML		All examples are syntactically correct and compatible with the XML
	schema in section 7. However, <Signature>, Key <Value> and Key		schema in section 7.
	<ValueDigest> data values are fictitious
	10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret		11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
	Key		Key
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0
	keyprov-pskc-1.0.xsd" Version="1.0">
	<Device>		<Device>
	<DeviceId>		<DeviceId>
	<Manufacturer>Token Manufacturer</Manufacturer>		<Manufacturer>ACME</Manufacturer>
	<SerialNo>98765432188</SerialNo>		<SerialNo>0755225266</SerialNo>
	<Expiry>12/31/2012</Expiry>		</DeviceId>
	</DeviceId>		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		KeyId="0755225266">
	KeyId="77654321871">		<Issuer>AnIssuer</Issuer>
	<Issuer>Credential Issuer</Issuer>		<Usage OTP="true">
	<Usage OTP="true">		<ResponseFormat Length="6" Format="DECIMAL"/>
	<ResponseFormat Format="DECIMAL" Length="6"/>		</Usage>
	</Usage>		<Data Name="COUNTER">
	<FriendlyName>MyFirstToken</FriendlyName>		<PlainValue>AprkuA==</PlainValue>
	<Data Name="SECRET">		</Data>
	<Value>		<Data Name="SECRET">
	zOkqJENSsh6b2hdXz1WBK/oprbY=		<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
	</Value>		</Data>
	</Data>		<ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
	<Data Name="COUNTER">		</Key>
	<Value>AAAAAAAAAAA=</Value>
	</Data>
	<Expiry>10/30/2012</Expiry>
	</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	10.2. Symmetric Key Container with a single Password-based Encrypted		11.2. Symmetric Key Container with a single PIN protected Non-Encrypted
	HOTP Secret Key		HOTP Secret Key
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		<Device>
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		<DeviceId>
	xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0		<Manufacturer>ACME</Manufacturer>
	keyprov-pskc-1.0.xsd" Version="1.0">		<SerialNo>0755225266</SerialNo>
	<EncryptionMethod Algorithm=		</DeviceId>
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	<PBEEncryptionParam EncryptionAlgorithm=		KeyId="0755225266">
	"http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc">		<Issuer>AnIssuer</Issuer>
	<PBESalt>y6TzckeLRQw=</PBESalt>		<Usage OTP="true">
	<PBEIterationCount>1024</PBEIterationCount>		<ResponseFormat Length="6" Format="DECIMAL"/>
	</PBEEncryptionParam>		</Usage>
	<IV>c2FtcGxlaXY=</IV>		<Data Name="COUNTER">
	</EncryptionMethod>		<PlainValue>AprkuA==</PlainValue>
	<DigestMethod		</Data>
	Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>		<Data Name="SECRET">
	<Device>		<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
			</Data>
			<PINPolicy PINKeyId="07552252661">
			<PINUsageMode>
			<Local/>
			</PINUsageMode>
			</PINPolicy>
			</Key>
			<Key KeyId="07552252661"
			KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
			<Usage>
			<ResponseFormat Length="4" Format="DECIMAL"/>
			</Usage>
			<Data Name="SECRET">
			<PlainValue>MTIzNA==</PlainValue>
			</Data>
			</Key>
			</Device>
			</KeyContainer>
			11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
			Secret Key
			<?xml version="1.0" encoding="UTF-8"?>
			<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
			<EncryptionKey>
			<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
			</EncryptionKey>
			<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
			</MACAlgorithm>
			<Device>
	<DeviceId>		<DeviceId>
	<Manufacturer>Token Manufacturer</Manufacturer>		<Manufacturer>ACME</Manufacturer>
	<SerialNo>98765432187</SerialNo>		<SerialNo>0755225266</SerialNo>
	<Expiry>12/31/2012</Expiry>
	</DeviceId>		</DeviceId>
	<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="77654321870">		KeyId="0755225266">
	<Issuer>Credential Issuer</Issuer>		<Issuer>AnIssuer</Issuer>
	<Usage OTP="true">		<Usage OTP="true">
	<ResponseFormat Format="DECIMAL" Length="6"/>		<ResponseFormat Length="8" Format="DECIMAL"/>
	</Usage>		</Usage>
	<FriendlyName>MyFirstToken</FriendlyName>		<Data Name="COUNTER">
	<Data Name="SECRET">		<PlainValue>AprkuA==</PlainValue>
	<Value>		</Data>
	JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg==		<Data Name="SECRET">
	</Value>		<EncryptedValue>
	<ValueDigest>		<xenc:EncryptionMethod
	i8j+kpbfKQsSlwmJYS99lQ==		Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
	</ValueDigest>		<xenc:CipherData>
	</Data>		<xenc:CipherValue>
	<Data Name="COUNTER">		kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
	<Value>AAAAAAAAAAA=</Value>		</xenc:CipherValue>
	</Data>		</xenc:CipherData>
	<Expiry>10/30/2012</Expiry>		</EncryptedValue>
			<ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>
			</Data>
	</Key>		</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	11. Normative References		11.4. Symmetric Key Container with signature and a single Password-
			based Encrypted HOTP Secret Key
			<?xml version="1.0" encoding="UTF-8"?>
			<pskc:KeyContainer
			xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:pkcs-5=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
			Version="1.0">
			<pskc:EncryptionKey>
			<pskc:DerivedKey Id="#Passphrase1">
			<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
			<pskc:KeyDerivationMethod
			Algorithm=
			"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
			<pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
			<Salt>
			<Specified>Df3dRAhjGh8=</Specified>
			</Salt>
			<IterationCount>2000</IterationCount>
			<KeyLength>16</KeyLength>
			<PRF/>
			</pkcs-5:Parameters>
			</pskc:KeyDerivationMethod>
			<xenc:ReferenceList>
			<xenc:DataReference URI="#ED"/>
			</xenc:ReferenceList>
			</pskc:DerivedKey>
			</pskc:EncryptionKey>
			<pskc:Device>
			<pskc:DeviceId>
			<pskc:Manufacturer>ACME</pskc:Manufacturer>
			<pskc:SerialNo>0755225266</pskc:SerialNo>
			</pskc:DeviceId>
			<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
			KeyId="0755225266">
			<pskc:Issuer>AnIssuer</pskc:Issuer>
			<pskc:Usage OTP="true">
			<pskc:ResponseFormat Length="6" Format="DECIMAL"/>
			</pskc:Usage>
			<pskc:Data Name="COUNTER">
			<pskc:PlainValue>AprkuA==</pskc:PlainValue>
			</pskc:Data>
			<pskc:Data Name="SECRET">
			<pskc:EncryptedValue Id="ED">
			<xenc:EncryptionMethod Algorithm=
			"http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
			<xenc:CipherData>
			<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
			</xenc:CipherValue>
			</xenc:CipherData>
			</pskc:EncryptedValue>
			</pskc:Data>
			</pskc:Key>
			</pskc:Device>
			<pskc:Signature>
			<ds:SignedInfo>
			<ds:CanonicalizationMethod
			Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<ds:SignatureMethod
			Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
			<ds:Reference URI="">
			<ds:DigestMethod Algorithm=
			"http://www.w3.org/2000/09/xmldsig#sha1"/>
			<ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
			</ds:Reference>
			</ds:SignedInfo>
			<ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue>
			<ds:KeyInfo>
			<ds:X509Data>
			<ds:X509IssuerSerial>
			<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US
			</ds:X509IssuerName>
			<ds:X509SerialNumber>12345678</ds:X509SerialNumber>
			</ds:X509IssuerSerial>
			</ds:X509Data>
			</ds:KeyInfo>
			</pskc:Signature>
			</pskc:KeyContainer>
			11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
			Secret Key
			<?xml version="1.0" encoding="UTF-8"?>
			<pskc:KeyContainer Version="1.0"
			xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
			xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
			<pskc:EncryptionKey>
			<ds:X509Data>
			<ds:X509Certificate>miib</ds:X509Certificate>
			</ds:X509Data>
			</pskc:EncryptionKey>
			<pskc:Device>
			<pskc:DeviceId>
			<pskc:Manufacturer>ACME</pskc:Manufacturer>
			<pskc:SerialNo>0755225266</pskc:SerialNo>
			</pskc:DeviceId>
			<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
			KeyId="0755225266">
			<pskc:Issuer>AnIssuer</pskc:Issuer>
			<pskc:Usage OTP="true">
			<pskc:ResponseFormat Length="8" Format="DECIMAL"/>
			</pskc:Usage>
			<pskc:Data Name="COUNTER">
			<pskc:PlainValue>AprkuA==</pskc:PlainValue>
			</pskc:Data>
			<pskc:Data Name="SECRET">
			<pskc:EncryptedValue Id="ED">
			<xenc:EncryptionMethod
			Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
			<xenc:CipherData>
			<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
			</xenc:CipherValue>
			</xenc:CipherData>
			</pskc:EncryptedValue>
			</pskc:Data>
			</pskc:Key>
			</pskc:Device>
			</pskc:KeyContainer>
			12. Normative References
	[CAP] MasterCard International, "Chip Authentication Program		[CAP] MasterCard International, "Chip Authentication Program
	Functional Architecture", September 2004.		Functional Architecture", September 2004.
	[DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet		[DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet
	Draft Informational, URL: http://tools.ietf.org/wg/		Draft Informational, URL: http://tools.ietf.org/wg/
	keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.		keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.
	[HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password		[HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226,		Algorithm", RFC 4226,
	skipping to change at page 46, line 8 ¶		skipping to change at page 46, line 8 ¶
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/, December 2002.		URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
	[XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLSIG] 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.
	Authors' Addresses		Authors' Addresses
	Philip Hoyer		Philip Hoyer
	ActivIdenity, Inc.		ActivIdentity, Inc.
	109 Borough High Street		109 Borough High Street
	London, SE1 1NL		London, SE1 1NL
	UK		UK
	Phone: +44 (0) 20 7744 6455		Phone: +44 (0) 20 7744 6455
	Email: Philip.Hoyer@actividentity.com		Email: Philip.Hoyer@actividentity.com
	Mingliang Pei		Mingliang Pei
	VeriSign, Inc.		VeriSign, Inc.
	487 E. Middlefield Road		487 E. Middlefield Road
	skipping to change at page 46, line 35 ¶		skipping to change at page 47, line 5 ¶
	Salah Machani		Salah Machani
	Diversinet, Inc.		Diversinet, Inc.
	2225 Sheppard Avenue East		2225 Sheppard Avenue East
	Suite 1801		Suite 1801
	Toronto, Ontario M2J 5C2		Toronto, Ontario M2J 5C2
	Canada		Canada
	Phone: +1 416 756 2324 Ext. 321		Phone: +1 416 756 2324 Ext. 321
	Email: smachani@diversinet.com		Email: smachani@diversinet.com
	Shuh Chang
	Gemalto Inc.
	Email: shuh.chang@gemalto.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 300 change blocks.
	1183 lines changed or deleted		1129 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/