< draft-ietf-keyprov-portable-symmetric-key-container-04.txt		draft-ietf-keyprov-portable-symmetric-key-container-05.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: October 23, 2008 VeriSign		Expires: January 15, 2009 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	April 21, 2008		July 14, 2008
	Portable Symmetric Key Container		Portable Symmetric Key Container
	draft-ietf-keyprov-portable-symmetric-key-container-04.txt		draft-ietf-keyprov-portable-symmetric-key-container-05.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 37 ¶		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 October 23, 2008.		This Internet-Draft will expire on January 15, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		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 (for example One Time Password (OTP)		provisioning of symmetric keys (for example One Time Password (OTP)
	shared secrets or symmetric cryptographic keys) to different types of		shared secrets or symmetric cryptographic keys) to different types of
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	between commercial and open-source implementations.		between commercial and open-source implementations.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8		3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. Transport of keys from Server to Crypto Module . . . . 8		3.1.1. Transport of keys from Server to Cryptomodule . . . . 8
	3.1.2. Transport of keys from Crypto Module to Crypto		3.1.2. Transport of keys from Cryptomodule to Cryptomodule . 8
	Module . . . . . . . . . . . . . . . . . . . . . . . . 8		3.1.3. Transport of keys from Cryptomodule to Server . . . . 9
	3.1.3. Transport of keys from Crypto Module to Server . . . . 9
	3.1.4. Server to server Bulk import/export of keys . . . . . 9		3.1.4. Server to server Bulk import/export of keys . . . . . 9
	3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9		3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. Server to server Bulk import/export of keys . . . . . 9		3.2.1. Server to server Bulk import/export of keys . . . . . 9
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Portable Key container definition . . . . . . . . . . . . . . 13		5. Portable Key container definition . . . . . . . . . . . . . . 13
	5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16
	5.2.1. DeviceId . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.3. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16		5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18
	5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	5.4.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 20		5.4.1. KeyData . . . . . . . . . . . . . . . . . . . . . . . 23
	5.4.2. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 21		5.4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . 25
	5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 25		5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 29
	5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 26		5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 29
	6. Usage and profile of algorithms for the portable symmetric		6. Usage and profile of algorithms for the portable symmetric
	key container . . . . . . . . . . . . . . . . . . . . . . . . 28		key container . . . . . . . . . . . . . . . . . . . . . . . . 33
	6.1. Usage of EncryptionKey to protect keys in transit . . . . 28		6.1. Usage of EncryptionKey to protect keys in transit . . . . 33
	6.1.1. Protecting keys using a pre-shared key via		6.1.1. Protecting keys using a pre-shared key via
	symmetric algorithms . . . . . . . . . . . . . . . . . 28		symmetric algorithms . . . . . . . . . . . . . . . . . 33
	6.1.2. Protecting keys using passphrase based encryption		6.1.2. Protecting keys using passphrase based encryption
	keys . . . . . . . . . . . . . . . . . . . . . . . . . 29		keys . . . . . . . . . . . . . . . . . . . . . . . . . 34
	6.2. Protecting keys using asymmetric algorithms . . . . . . . 31		6.2. Protecting keys using asymmetric algorithms . . . . . . . 36
	6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 32		6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 37
	6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 33		6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 38
	6.3.2. PIN key value compare algorithm identifier . . . . . . 33		6.3.2. PIN key value compare algorithm identifier . . . . . . 38
	7. Reserved data attribute names . . . . . . . . . . . . . . . . 34		7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 39
	8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		8.1. Content-type registration for 'application/pskc+xml' . . . 46
	9.1. Content-type registration for 'application/pskc+xml' . . . 40		8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
	9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 41		8.3. URN Sub-Namespace Registration for
	9.3. URN Sub-Namespace Registration for		urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . . . . 47
	urn:ietf:params:xml:ns:keyprov:container:1.0 . . . . . . . 41		8.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 48
	9.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 42		8.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 48
	9.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 42		8.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 49
	9.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 43		8.4.3. Registration Procedures . . . . . . . . . . . . . . . 50
	9.4.3. Registration Procedures . . . . . . . . . . . . . . . 44		8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 52
	9.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 46		9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
	9.5. XML Data Tag Identifier Registry . . . . . . . . . . . . . 49		9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 57
	9.5.1. Applicability . . . . . . . . . . . . . . . . . . . . 49		9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 58
	9.5.2. Registerable Data Tags . . . . . . . . . . . . . . . . 50		9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 58
	9.5.3. Registration Procedures . . . . . . . . . . . . . . . 50		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
	9.5.4. Initial Values . . . . . . . . . . . . . . . . . . . . 51		11. Appendix A - Example Symmetric Key Containers . . . . . . . . 60
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 53		11.1. Symmetric Key Container with a single Non-Encrypted
	10.1. Payload confidentiality . . . . . . . . . . . . . . . . . 53		HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 60
	10.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 54		11.2. Symmetric Key Container with a single PIN protected
	10.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 54		Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 60
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55		11.3. Symmetric Key Container with a single AES-256-CBC
	12. Appendix A - Example Symmetric Key Containers . . . . . . . . 56		Encrypted HOTP Secret Key and non-encrypted counter
	12.1. Symmetric Key Container with a single Non-Encrypted		value . . . . . . . . . . . . . . . . . . . . . . . . . . 62
	HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 56		11.4. Symmetric Key Container with signature and a single
	12.2. Symmetric Key Container with a single PIN protected		Password-based Encrypted HOTP Secret Key . . . . . . . . . 63
	Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 56		11.5. Symmetric Key Container with a single RSA 1.5
	12.3. Symmetric Key Container with a single AES-256-CBC		Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 65
	Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 57		11.6. Symmetric Key Container with a single AES-256-CBC
	12.4. Symmetric Key Container with signature and a single		Encrypted OCRA Secret Key and non-encrypted counter
	Password-based Encrypted HOTP Secret Key . . . . . . . . . 58		value . . . . . . . . . . . . . . . . . . . . . . . . . . 66
	12.5. Symmetric Key Container with a single RSA 1.5		11.7. Symmetric Key Container with a single AES-256-CBC
	Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 60		Encrypted TOTP Secret Key and non-encrypted time values . 68
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62		11.8. Symmetric Key Container with two devices containing a
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 62		Non-Encrypted HOTP Secret Key each sharing common
	13.2. Informative References . . . . . . . . . . . . . . . . . . 62		KeyProperties . . . . . . . . . . . . . . . . . . . . . . 69
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
	Intellectual Property and Copyright Statements . . . . . . . . . . 65		12.1. Normative References . . . . . . . . . . . . . . . . . . . 71
			12.2. Informative References . . . . . . . . . . . . . . . . . . 71
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
			Intellectual Property and Copyright Statements . . . . . . . . . . 74
	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
	keys from one system to another. Traditionally authentication server		keys from one system to another. Traditionally authentication server
	vendors and service providers have used proprietary formats for		vendors and service providers have used proprietary formats for
	importing, exporting and provisioning these keys into their systems		importing, exporting and provisioning these keys into their systems
	making it hard to use tokens from vendor A with a server from vendor		making it hard to use tokens from 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 keys such as OTP shared secrets for system import, export		symmetric keys such as OTP shared secrets for system import, export
	or network/protocol transport. The goal is that the format will		or network/protocol transport. The goal is that the format will
	facilitate dynamic provisioning and transfer of a symmetric keys such		facilitate dynamic provisioning and transfer of symmetric keys such
	as an OTP shared secret or an encryption key of different types. In		as OTP shared secrets or encryption keys of different types. In the
	the case of OTP shared secrets, the format will facilitate dynamic		case of OTP shared secrets, the format will facilitate dynamic
	provisioning using an online provisioning protocol to different		provisioning using an online provisioning protocol to different
	flavors of embedded tokens or allow customers to import new or		flavors of embedded tokens or allow customers to import new or
	existing tokens in batch or single instances into a compliant system.		existing tokens in batch or single instances into a compliant system.
	This draft also specifies the key attributes required for computation		This draft also specifies the key attributes required for computation
	such as the initial event counter used in the HOTP algorithm [HOTP].		such as the initial event counter used in the HOTP algorithm [HOTP].
	It is also applicable for other time-based or proprietary algorithms.		It is also applicable for other time-based or 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
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	cryptographic algorithm that determines its operation in such a		cryptographic algorithm that determines its operation in such a
	way that an entity with knowledge of the key can reproduce or		way that an entity with knowledge of the key can reproduce or
	reverse the operation, while an entity without knowledge of the		reverse the operation, while an entity without knowledge of the
	key cannot (see [NIST-SP800-57])		key cannot (see [NIST-SP800-57])
	Cryptographic Token: See Authentication Token		Cryptographic Token: See Authentication Token
	Device: A physical piece of hardware, or a software framework, that		Device: A physical piece of hardware, or a software framework, that
	hosts symmetric keys		hosts symmetric keys
	Device ID (DeviceId): A unique identifier for the device,		DeviceInfo: A set of elements whose values combined uniquely
	representing the identifying criteria to uniquely identify a		identify a device e.g. Manufacture 'Manufacturer and Serialnumber
	device		'12345678'
	Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a		Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a
	key container available to a recipient		key container available to a recipient
	Encryption Key: A key used to encrypt key		Encryption Key: A key used to encrypt key
	Key: See Cryptographic Key		Key: See Cryptographic Key
	Hardware Token: See Authentication Token		Hardware Token: See Authentication Token
	Key Algorithm: A well-defined computational procedure that takes		Key Algorithm: A well-defined computational procedure that takes
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	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. Online Use Cases		3.1. Online Use Cases
	This section describes the use cases related to provisioning the keys		This section describes the use cases related to provisioning the keys
	using an online provisioning protocol such as [DSKPP]		using an online provisioning protocol such as [DSKPP]
	3.1.1. Transport of keys from Server to Crypto Module		3.1.1. Transport of keys from Server to Cryptomodule
	For example, a mobile device user wants to obtain a symmetric key for		For example, a mobile device user wants to obtain a symmetric key for
	use with a cryptomodule on the device. The cryptomodule client from		use with a cryptomodule on the device. The cryptomodule client from
	vendor A initiates the provisioning process against a provisioning		vendor A initiates the provisioning process against a provisioning
	system from vendor B using a standards-based provisioning protocol		system from vendor B using a standards-based provisioning protocol
	such as [DSKPP]. The provisioning entity delivers one or more keys		such as [DSKPP]. The provisioning entity delivers one or more keys
	in a standard format that can be processed by the mobile device.		in a standard format that can be processed by the mobile device.
	For example, in a variation of the above, instead of the user's		For example, in a variation of the above, instead of the user's
	mobile phone, a key is provisioned in the user's soft token		mobile phone, a key is provisioned in the user's soft token
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	before, the provisioning system delivers a key in a standard format		before, the provisioning system delivers a key in a standard format
	that can be processed by the soft token on the PC.		that can be processed by the soft token on the PC.
	For example, the end-user or the key issuer wants to update or		For example, the end-user or the key issuer wants to update or
	configure an existing key in the cryptomodule and requests a		configure an existing key in the cryptomodule and requests a
	replacement key container. The container may or may not include a		replacement key container. The container may or may not include a
	new key and may include new or updated key attributes such as a new		new key and may include new or updated key attributes such as a new
	counter value in HOTP key case, a modified response format or length,		counter value in HOTP key case, a modified response format or length,
	a new friendly name, etc.		a new friendly name, etc.
	3.1.2. Transport of keys from Crypto Module to Crypto Module		3.1.2. Transport of keys from Cryptomodule to Cryptomodule
	For example, a user wants to transport a key from one cryptomodule to		For example, a user wants to transport a key from one cryptomodule to
	another. There may be two cryptographic modules, one on a computer		another. There may be two cryptographic modules, one on a computer
	one on a mobile phone, and the user wants to transport a key from the		one on a mobile phone, and the user wants to transport a key from the
	computer to the mobile phone. The user can export the key and		computer to the mobile phone. The user can export the key and
	related data in a standard format for input into the other		related data in a standard format for input into the other
	cryptomodule.		cryptomodule.
	3.1.3. Transport of keys from Crypto Module to Server		3.1.3. Transport of keys from Cryptomodule to Server
	For example, a user wants to activate and use a new key and related		For example, a user wants to activate and use a new key and related
	data against a validation system that is not aware of this key. This		data against a validation system that is not aware of this key. This
	key may be embedded in the cryptomodule (e.g. SD card, USB drive)		key may be embedded in the cryptomodule (e.g. SD card, USB drive)
	that the user has purchased at the local electronics retailer. Along		that the user has purchased at the local electronics retailer. Along
	with the cryptomodule, the user may get the key on a CD or a floppy		with the cryptomodule, the user may get the key on a CD or a floppy
	in a standard format. The user can now upload via a secure online		in a standard format. The user can now upload via a secure online
	channel or import this key and related data into the new validation		channel or import this key and related data into the new validation
	system and start using the key.		system and start using the key.
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	gateway and subsequently sent to the end-user's mobile phone.		gateway and subsequently sent to the end-user's mobile phone.
	3.2. Offline Use Cases		3.2. 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
	keys from one system to another, using some form of export and import		keys from one system to another, using some form of export and import
	model.		model.
	3.2.1. Server to server Bulk import/export of keys		3.2.1. Server to server Bulk import/export of keys
	For example, crypto modules such as OTP authentication tokens, may		For example, cryptomodules such as OTP authentication tokens, may
	have their symmetric keys initialized during the manufacturing		have their symmetric keys initialized during the manufacturing
	process in bulk, requiring copies of the keys and algorithm data to		process in bulk, requiring copies of the keys and algorithm data to
	be loaded into the authentication system through a file on portable		be loaded into the authentication system through a file on portable
	media. The manufacturer provides the keys and related data in the		media. The manufacturer provides the keys and related data in the
	form of a file containing records in standard format, typically on a		form of a file containing records in standard format, typically on a
	CD. Note that the token manufacturer and the vendor for the		CD. Note that the token manufacturer and the vendor for the
	validation system may be the same or different. Some crypto modules		validation system may be the same or different. Some crypto modules
	will allow local PIN management (the device will have a PIN pad)		will allow local PIN management (the device will have a PIN pad)
	hence random initial PINs set at manufacturing should be transmitted		hence random initial PINs set at manufacturing should be transmitted
	together with the respective keys they protect.		together with the respective keys they protect.
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	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. Portable Key container definition		5. Portable Key container definition
	The portable key container is based on an XML schema definition and		The portable key container is based on an XML schema definition and
	contains the following main entities:		contains the following main entities:
	1. KeyContainer entity as defined in Section 5.1		1. KeyContainer entity as defined in Section 5.1
	2. Device entity as defined in Section 5.2		2. KeyProperties entity as defined in Section 5.2
	3. Key entity as defined in Section 5.4		3. Device entity as defined in Section 5.3
			4. Key entity as defined in Section 5.4
	Additionally other XML schema types have been defined and are		Additionally other XML schema types have been defined and are
	detailed in the relevant subsections of this document		detailed in the relevant subsections of this document
	A KeyContainer MAY contain one or more Device entities. A Device MAY		A KeyContainer MAY contain one or more Device entities. A Device MAY
	contain one or more Key entities		contain one or more Key entities
	The figure below indicates a possible relationship diagram of a		The figure below indicates a possible relationship diagram of a
	container.		container.
	--------------------------------------------		--------------------------------------------
	| KeyContainer |		| KeyContainer |
	| |		| |
			| -------------------- |
			| | Keyproperties 1 | |
			| | | |
			| -------------------- |
	| ------------------ ----------------- |		| ------------------ ----------------- |
	| | Device 1 | | Device n | |		| | Device 1 | | Device n | |
	| | | | | |		| | | | | |
	| | ------------ | | ------------ | |		| | ------------ | | ------------ | |
	| | | Key 1 | | | | Key n | | |		| | | Key 1 | | | | Key n | | |
	| | ------------ | | ------------ | |		| | ------------ | | ------------ | |
	| | | | | |		| | | | | |
	| | | | | |		| | | | | |
	| | ------------ | | ------------ | |		| | ------------ | | ------------ | |
	| | | Key m | | | | Key p | | |		| | | Key m | | | | Key p | | |
	| | ------------ | | ------------ | |		| | ------------ | | ------------ | |
	| ------------------ ----------------- |		| ------------------ ----------------- |
	| |		| |
	--------------------------------------------		--------------------------------------------
	The following section describe in detail all the entities and related		The following sections describe in detail all the entities and
	XML schema elements and attributes:		related XML schema elements and attributes:
	5.1. KeyContainer		5.1. KeyContainer
	The KeyContainer represents the key container entity. A Container		The KeyContainer represents the key container entity. A Container
	MAY contain more than one Device entity; each Device entity MAY		MAY contain more than one Device entity; each Device entity MAY
	contain more than one Key entity.		contain more than one Key entity.
	The KeyContainer is defined as follows:		The KeyContainer is defined as follows:
	<xs:complexType name="KeyContainerType">		<xs:complexType name="KeyContainerType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="EncryptionKey"		<xs:element name="EncryptionKey"
	type="ds:KeyInfoType" minOccurs="0"/>		type="ds:KeyInfoType" minOccurs="0"/>
	<xs:element name="MACAlgorithm"		<xs:element name="MACAlgorithm"
	type="pskc:KeyAlgorithmType" minOccurs="0"/>		type="pskc:KeyAlgorithmType" minOccurs="0"/>
	<xs:element name="Device"		<xs:element name="KeyProperties"
	type="pskc:DeviceType" maxOccurs="unbounded"/>		type="pskc:KeyPropertiesType" minOccurs="0"
	<xs:element name="Signature"		maxOccurs="unbounded"/>
	type="ds:SignatureType" minOccurs="0"/>		<xs:element name="Device"
	</xs:sequence>		type="pskc:DeviceType" minOccurs="1"
	<xs:attribute name="Version" type="pskc:VersionType" use="required"/>		maxOccurs="unbounded"/>
	</xs:complexType>		<xs:element name="Signature"
			type="ds:SignatureType" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="Version" type="pskc:VersionType"
			use="required"/>
			<xs:attribute name="ID" type="xs:ID"
			use="optional"/>
			</xs:complexType>
			The attributes of the KeyContainer have the following meanings:
			o Version (MANDATORY), the version number for the portable key
			container format (the XML schema defined in this document).
			o ID (OPTIONAL), the unique ID for this container in case an XML
			document contains more than one container and wants to refer to
			them uniquely.
	The elements of the KeyContainer have the following meanings:		The elements of the KeyContainer have the following meanings:
	o <EncryptionKey (OPTIONAL)>, Identifies the encryption key,		o <EncryptionKey> (OPTIONAL), Identifies the encryption key,
	algorithm and possible parameters used to protect the Secret Key		algorithm and possible parameters used to protect the Secret Key
	data in the container. Please see Section 6.1 for detailed		data in the container. Please see Section 6.1 for detailed
	description of how to protect key data in transit and the usage of		description of how to protect key data in transit and the usage of
	this element.		this element.
	o <MACAlgorithm (OPTIONAL)>, Identifies the algorithm used to		o <MACAlgorithm> (OPTIONAL), Identifies the algorithm used to
	generate a keyed digest of the the Secret Key data values when		generate a keyed digest of the Secret Key data values when
	protection algorithms are used that do not have integrity checks.		protection algorithms are used that do not have integrity checks.
	The digest guarantees the integrity and the authenticity of the		The digest guarantees the integrity and the authenticity of the
	key data. for profile and usage please see Section 6.1.1		key data. for profile and usage please see Section 6.1.1
	o <Device>, the host Device for one or more Keys as defined in		o <KeyProperties> (OPTIONAL), key property entities containing key
	Section 5.2 The KeyContainer MAY contain multiple Device data		related properties that are common for keys within this container.
	elements, allowing for bulk provisioning of multiple devices each		Please see Section 5.2 for detailed description of this
	containing multiple keys.		element.The KeyContainer MAY contain multiple KeyProperties
			elements each containing a set of properties related to one or
			more keys transported within the container.
	o <Signature (OPTIONAL)>, the signature value of the Container.		o <Device> (MANDATORY), the host Device for one or more Keys as
			defined in Section 5.3 The KeyContainer MAY contain multiple
			Device data elements, allowing for bulk provisioning of multiple
			devices each containing multiple keys.
			o <Signature> (OPTIONAL), the signature value of the Container.
	When the signature is applied to the entire container, it MUST use		When the signature is applied to the entire container, it MUST use
	XML Signature methods as defined in [XMLDSIG]. It MAY be omitted		XML Signature methods as defined in [XMLDSIG]. It MAY be omitted
	when application layer provisioning or transport layer		when application layer provisioning or transport layer
	provisioning protocols provide the integrity and authenticity of		provisioning protocols provide the integrity and authenticity of
	the payload between the sender and the recipient of the container.		the payload between the sender and the recipient of the container.
	When required, this specification recommends using a symmetric key		When required, this specification recommends using a symmetric key
	based signature with the same key used in the encryption of the		based signature with the same key used in the encryption of the
	secret key data. The signature is enveloped.		secret key data. The signature is enveloped.
	o <Version (MANDATORY)>, the version number for the portable key		o <Extensions> (OPTIONAL), is the extension point for this entity.
	container format (the XML schema defined in this document).		All extensions are grouped under this element and will be of type
			pskc:ExtensionType, which contains an optional attribute
			'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
	5.2. Device		<Extensions>
			<MyExtension1
			definition="http://ACME/MyExtension1.html">blah</Myextension1>
			<YourExtension99>blahblah</YourExtension99>
			</Extensions>
	The Device represents the Device entity in the Container. A Device		5.2. KeyProperties
	MAY be bound to a user and MAY contain more than one keys. A key
	SHOULD be bound to only one Device.		The KeyProperties represents common properties shared by more than
			one key held in the container. If a value is set in the properties
			the Key element can refer to it via ID attribute. Values that are
			present in the Key element itself MUST take precedence over values
			set in KeyProperties. The KeyProperties is defined as follows:
			<xs:complexType name="KeyPropertiesType">
			<xs:sequence>
			<xs:element name="Issuer" type="xs:string"
			minOccurs="0"/>
			<xs:element name="Usage" type="pskc:UsageType"
			minOccurs="0"/>
			<xs:element name="KeyProfileId" type="xs:string"
			minOccurs="0"/>
			<xs:element name="MasterKeyId" type="xs:string"
			minOccurs="0"/>
			<xs:element name="Data" type="pskc:KeyDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="PINPolicy"
			type="pskc:PINPolicyType" minOccurs="0"/>
			<xs:element name="StartDate" type="xs:dateTime"
			minOccurs="0"/>
			<xs:element name="ExpiryDate"
			type="xs:dateTime" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="ID" type="xs:ID"
			use="required"/>
			<xs:attribute name="KeyAlgorithm"
			type="pskc:KeyAlgorithmType" use="optional"/>
			</xs:complexType>
			The attributes of the KeyProperties entity have the following
			meanings:
			o ID (MANDATORY), a unique and global identifier of set of
			KeyProperties. The identifier is defined as a string of
			alphanumeric characters.
			o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
			to use with a secret key for the profiles described in Section 6.3
			Since KeyProperties are a method to group element values that are
			common to multiple keys transported, please refer to Section 5.4 for
			detailed description of all elements.
			5.3. Device
			The Device represents an extensible Device entity in the Container.
			A Device MAY be bound to a user and MAY contain more than one key. A
			key SHOULD be bound to only one Device.
	The Device is defined as follows:		The Device is defined as follows:
	<xs:complexType name="DeviceType">		<xs:complexType name="DeviceType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>		<xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
	<xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>		minOccurs="0"/>
	<xs:element name="UserId" type="xs:string" minOccurs="0"/>		<xs:element name="Key" type="pskc:KeyType"
	</xs:sequence>		maxOccurs="unbounded"/>
	</xs:complexType>		<xs:element name="User" type="xs:string" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
	The elements of the Device have the following meanings:		The elements of the Device have the following meanings:
	o <DeviceId>, a unique identifier for the device, defined in		o <DeviceInfo> (OPTIONAL), a set of elements containing information
	Section 5.2.1		about the device, whose values uniquely identify the device,
			defined in Section 5.3.1
	o <Key>, represents the key entity as defined in Section 5.4		o <Key> (MANDATORY), represents the key entity as defined in
			Section 5.4
	o <UserId>, optionally identifies the owner or the user of the		o <User> (OPTIONAL), identifies the owner or the user of the Device,
	Device, a string representation of a Distinguished Name as defined		a string representation of a Distinguished Name as defined in
	in [RFC4514]. For example UID=jsmith,DC=example,DC=net. In		[RFC4514]. For example UID=jsmith,DC=example,DC=net. In systems
	systems where unique user Ids are used the string representation		where unique user Ids are used the string representation
	'UID=[uniqueId]' MUST be used.		'UID=[uniqueId]' SHOULD be used.
	5.2.1. DeviceId		o <Extensions> (OPTIONAL), is the extension point for this entity.
			All extensions are grouped under this element and will be of type
			pskc:ExtensionType, which contains an optional attribute
			'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
	The DeviceId represents the identifying criteria to uniquely identify		<Extensions>
	the device that contains the associated keys. Since devices can come		<MyExtension1
	in different form factors such as hardware tokens, smart-cards, soft		definition="http://ACME/MyExtension1.html">blah</Myextension1>
	tokens in a mobile phone or PC etc this element allows different		<YourExtension99>blahblah</YourExtension99>
	criteria to be used. Combined though the criteria MUST uniquely		</Extensions>
	identify the device. For example for hardware tokens the combination
	of SerialNo and Manufacturer will uniquely identify a device but not		5.3.1. DeviceInfo
	SerialNo alone since two different token manufacturers might issue
	devices with the same serial number (similar to the IssuerDN and		The DeviceInfo represents an extensible set of elements that form the
	serial number of a certificate). Symmetric Keys used in the payment		identifying criteria to uniquely identify the device that contains
	industry are usually stored on Integrated Circuit Smart Cards. These		the associated keys. Since devices can come in different form
	cards are uniquely identified via the Primary Account Number (PAN,		factors such as hardware tokens, smart-cards, soft tokens in a mobile
	the long number printed on the front of the card) and an expiry date		phone or PC etc this element allows different criteria to be used.
	of the card. DeviceId is an extensible type that allows all these		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). Symmetric Keys used in the payment industry are
			usually stored on Integrated Circuit Smart Cards. These cards are
			uniquely identified via the Primary Account Number (PAN, the long
			number printed on the front of the card) and an expiry date of the
			card. DeviceInfo is an extensible type that allows all these
	different ways to uniquely identify a specific key containing device.		different ways to uniquely identify a specific key containing device.
	The DeviceId is defined as follows:		The DeviceInfo is defined as follows:
	<xs:complexType name="DeviceIdType">		<xs:complexType name="DeviceInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Manufacturer" type="xs:string"/>		<xs:element name="Manufacturer" type="xs:string"/>
	<xs:element name="SerialNo" type="xs:string"/>		<xs:element name="SerialNo" type="xs:string"/>
	<xs:element name="Model" type="xs:string" minOccurs="0"/>		<xs:element name="Model" type="xs:string" minOccurs="0"/>
	<xs:element name="IssueNo" 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="DeviceBinding" type="xs:string" minOccurs="0"/>
	<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>		<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
			<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	The elements of DeviceId have the following meanings:		The elements of DeviceInfo have the following meanings:
	o <Manufacturer>, the manufacturer of the device.
	o <SerialNo>, the serial number of the device or the PAN (primary
	account number) in case of payment smart cards.
	o <Model>, the model of the device (e.g one-button-HOTP-token-V1)
	o <IssueNo>, the issue number in case of smart cards with the same
	PAN, equivalent to a PSN (PAN Sequence Number).
	o <ExpiryDate>, the expiry date of a device (such as the one on a		o <Manufacturer> (MANDATORY), the manufacturer of the device.
	payment card,used when issue numbers are not printed on cards).
	o <StartDate>, the start date of a device (such as the one on a		o <SerialNo> (MANDATORY), the serial number of the device or the PAN
	payment card,used when issue numbers are not printed on cards).		(primary account number) in case of payment smart cards.
	5.3. KeyProperties		o <Model> (OPTIONAL), the model of the device (e.g. one-button-HOTP-
			token-V1)
	The KeyProperties represents common properties shared by more than		o <IssueNo> (OPTIONAL), the issue number in case of smart cards with
	one key held in the container. If a value is set in the properties		the same PAN, equivalent to a PSN (PAN Sequence Number).
	the Key element can refer to it via KeyPropertiesId attribute.
	Values that are present in the Key element itself MUST take
	precendence over values set in KeyProperties. The KeyProperties is
	defined as follows:
	<xs:complexType name="KeyPropertiesType">		o <DeviceBinding> (OPTIONAL), the identifier that can be used to
	<xs:sequence>		bind keys to the device or class of device. When loading keys
	<xs:element name="Issuer" type="xs:string"		into a device, this identifier can be checked against information
	minOccurs="0"/>		obtained from the device to ensure that the correct device or
	<xs:element name="Usage" type="pskc:UsageType"		class of device is being used.
	minOccurs="0"/>
	<xs:element name="KeyProfileId" type="xs:string"
	minOccurs="0"/>
	<xs:element name="MasterKeyId" 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="KeyPropertiesId" type="xs:string"
	use="required"/>
	<xs:attribute name="KeyAlgorithm"
	type="pskc:KeyAlgorithmType" use="optional"/>
	</xs:complexType>
	The attributes of the KeyProperties entity have the following		o <StartDate> (OPTIONAL), the start date of a device (such as the
	meanings:		one on a payment card, used when issue numbers are not printed on
			cards). MUST be expressed in UTC form, with no time zone
			component. Implementations SHOULD NOT rely on time resolution
			finer than milliseconds and MUST NOT generate time instants that
			specify leap seconds.
	o KeyPropertiesId (MANDATORY), a unique and global identifier of set		o <ExpiryDate> (OPTIONAL), the expiry date of a device (such as the
	of KeyProperties. The identifier is defined as a string of		one on a payment card, used when issue numbers are not printed on
	alphanumeric characters.		cards). MUST be expressed in UTC form, with no time zone
			component. Implementations SHOULD NOT rely on time resolution
			finer than milliseconds and MUST NOT generate time instants that
			specify leap seconds.
	o <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm		o <Extensions> (OPTIONAL), is the extension point for this entity.
	to use with the secret key, for profiles are described in		All extensions are grouped under this element and will be of type
	Section 6.3		pskc:ExtensionType, which contains an optional attribute
			'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
	Since KeyProperties are a method to commonalise the elements in Key		<Extensions>
	please refer to section Section 5.4 for detailed description of all		<MyExtension1
	elements.		definition="http://ACME/MyExtension1.html">blah</Myextension1>
			<YourExtension99>blahblah</YourExtension99>
			</Extensions>
	5.4. Key		5.4. Key
	The Key represents the key entity in the KeyContainer. The Key is		The Key represents the key entity in the KeyContainer. The Key is
	defined as follows:		defined as follows:
	<xs:complexType name="KeyType">		<xs:complexType name="KeyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Issuer" type="xs:string"		<xs:element name="Issuer" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Usage" type="pskc:UsageType"		<xs:element name="Usage" type="pskc:UsageType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="KeyProfileId" type="xs:string"		<xs:element name="KeyProfileId" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="MasterKeyId" type="xs:string"		<xs:element name="MasterKeyId" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="FriendlyName" type="xs:string"		<xs:element name="FriendlyName" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Data" type="pskc:DataType"		<xs:element name="Data" type="pskc:KeyDataType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="PINPolicy"		<xs:element name="PINPolicy"
	type="pskc:PINPolicyType" minOccurs="0"/>		type="pskc:PINPolicyType" minOccurs="0"/>
			<xs:element name="StartDate" type="xs:dateTime"
			minOccurs="0"/>
	<xs:element name="ExpiryDate" type="xs:dateTime"		<xs:element name="ExpiryDate" type="xs:dateTime"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="StartDate" type="xs:dateTime"		<xs:element name="UserId" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="KeyId" type="xs:string"		<xs:attribute name="KeyId" type="xs:string"
	use="required"/>		use="required"/>
	<xs:attribute name="KeyAlgorithm"		<xs:attribute name="KeyAlgorithm"
	type="pskc:KeyAlgorithmType" use="optional"/>		type="pskc:KeyAlgorithmType" use="optional"/>
	<xs:attribute name="KeyPropertiesId" type="xs:string"		<xs:attribute name="KeyProperties" type="xs:IDREF"
	use="optional"/>		use="optional"/>
	</xs:complexType>		</xs:complexType>
	The attributes of the Key entity have the following meanings:		The attributes of the Key entity have the following meanings:
	o KeyId (MANDATORY), a unique and global identifier of the symmetric		o KeyId (MANDATORY), a unique and global identifier of the symmetric
	key. The identifier is defined as a string of alphanumeric		key. The identifier is defined as a string of alphanumeric
	characters.		characters. This identifier SHOULD be valid globally and outside
			of the instance document of the container.
	o <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm		o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
	to use with the secret key, for profiles are described in		to use with the secret key, for profiles are described in
	Section 6.3		Section 6.3
	o <KeyPropertiesId (OPTIONAL)>, the unique id of the KeyProperties		o KeyProperties (OPTIONAL), the references to the unique id of the
	whose value the instance of this key inherits. If this value is		KeyProperties whose value the instance of this key inherits. If
	set implementation MUST lookup the Keyproperties element referred		this value is set implementation MUST lookup the Keyproperties
	to by this unique Id and this instance of key will inherit all		element referred to by this unique Id and this instance of key
	values from the KeyProperties. Values held in the key instance it		will inherit all values from the KeyProperties. Values held in
	MUST take precedence over values inherited from KeyProperties."/>		the key instance MUST take precedence over values inherited from
			KeyProperties."/>
	The elements of the Key entity have the following meanings:		The elements of the Key entity have the following meanings:
	o <Issuer (OPTIONAL)>, The key issuer name, this is normally the		o <Issuer> (OPTIONAL), The key issuer name, this is normally the
	name of the organization that issues the key to the end user of		name of the organization that issues the key to the end user of
	the key. For example MyBank issuing hardware tokens to their		the key. For example MyBank issuing hardware tokens to their
	retail banking users 'MyBank' would be the issuer. The Issuer is		retail banking users 'MyBank' would be the issuer. The Issuer is
	defined as a String.		defined as a String.
	o <Usage (MANDATORY)>, defines the intended usage of the key and		o <Usage> (OPTIONAL), defines the intended usage of the key and
	related metadata as defined in Section 5.4.2		related metadata as defined in Section 5.4.2
	o <KeyProfileId (OPTIONAL)>, A unique identifier used between the		o <KeyProfileId> (OPTIONAL), A unique identifier used between the
	sending and receiving party of the container to establish a set of		sending and receiving party of the container to establish a set of
	constant values related to a key that are not transmitted via the		constant values related to a key that are not transmitted via the
	container. For example a smart card application personalisation		container. For example a smart card application personalisation
	profile id related to attributes present on a smart card		profile id related to attributes present on a smart card
	application that have influence when computing a response. An		application that have influence when computing a response. An
	example could be an EMV MasterCard CAP [CAP] application on a card		example could be an EMV MasterCard CAP [CAP] application on a card
	personalised with data for a specific batch of cards such as:		personalised with data for a specific batch of cards such as:
	IAF Internet authentication flag		IAF Internet authentication flag
	skipping to change at page 19, line 41 ¶		skipping to change at page 22, line 4 ¶
	CVR The card verification result		CVR The card verification result
	AmountOther		AmountOther
	TransactionDate		TransactionDate
	TerminalCountryCode		TerminalCountryCode
	TransactionCurrencyCode		TransactionCurrencyCode
	AmountAuthorised		AmountAuthorised
	IIPB		IIPB
	These values are not contained within attributes in the container		These values are not contained within attributes in the container
	but are shared between the manufacturing and the validation		but are shared between the manufacturing and the validation
	service through this unique KeyProfileId. The KeyProfileId is		service through this unique KeyProfileId. The KeyProfileId is
	defined as a String.		defined as a String.
	o <MasterKeyId (OPTIONAL)>, The unique reference to a master key		o <MasterKeyId> (OPTIONAL), The unique reference to an external
	when key derivation schemes are used and no specific key is		master key when key derivation schemes are used and no specific
	transported but only the reference to the master key used to		key is transported but only the reference to the master key used
	derive a specific key and some derivation data.		to derive a specific key and some derivation data (e.g. the
			PKCS#11 key label in an HSM).
	o <FriendlyName (OPTIONAL)>, The user friendly name that is assigned		o <FriendlyName> (OPTIONAL), The user friendly name that is assigned
	to the secret key for easy reference. The FriendlyName is defined		to the secret key for easy reference. The FriendlyName is defined
	as a String.		as a String.
	o <Data (OPTIONAL)>, the element carrying the data related to the		o <Data> (OPTIONAL), the element carrying the data related to the
	key as defined in Section 5.4.1		key as defined in Section 5.4.1
	o <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the		o <PINPolicy> (OPTIONAL), the policy of the PIN relating to the
	usage of this key as defined in Section 5.4.4		usage of this key as defined in Section 5.4.4
	o <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not		o <StartDate> (OPTIONAL), the start date of the key, it MUST not be
	be possible to use this key after this date		possible to use this key before this date. MUST be expressed in
			UTC form, with no time zone component. Implementations SHOULD NOT
			rely on time resolution finer than milliseconds and MUST NOT
			generate time instants that specify leap seconds.
	o <StartDate (OPTIONAL)>, the start date of the key, it MUST not be		o <ExpiryDate> (OPTIONAL), the expiry date of the key, it MUST not
	possible to use this key before this date		be possible to use this key after this date. MUST be expressed in
			UTC form, with no time zone component. Implementations SHOULD NOT
			rely on time resolution finer than milliseconds and MUST NOT
			generate time instants that specify leap seconds.
	5.4.1. Data (OPTIONAL)		o <UserId> (OPTIONAL), identifies the user account (e.g. username or
			user id) to which the key is assigned. The value MAY be a string
			representation of a Distinguished Name as defined in [RFC4514].
			For example "UID=jsmith,DC=example,DC=net". In systems where
			unique user Ids are used the string representation
			'UID=[uniqueId]' SHOULD be used.
	Defines the data attributes of the symmetric key. Each is a name		o <Extensions> (OPTIONAL), is the extension point for this entity.
	value pair which has either a plain value (in case of no encryption)		All extensions are grouped under this element and will be of type
	or a encrypted value as defined in EncryptedDataType in XML		pskc:ExtensionType, which contains an optional attribute
	Encryption.		'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
	This is also where the key value is transported, Section 7 defines a		<Extensions>
	list of reserved attribute names.		<MyExtension1
			definition="http://ACME/MyExtension1.html">blah</Myextension1>
			<YourExtension99>blahblah</YourExtension99>
			</Extensions>
	Data element is defined as follows:		5.4.1. KeyData
	<xs:complexType name="DataType">		Defines an extensible set of data elements relating to a key
	<xs:sequence>		including the key value itself (secret). After considerable
	<xs:choice>		discussions in forums and at IETF the authors needed a mean to convey
	<xs:element name="PlainValue" type="xs:base64Binary"/>		data related to a key in an extensible form. The requirements were
	<xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>		that the data elements could be encrypted but not via XML encryption
	</xs:choice>		which was deemed to complex because of canonicalization. Hence
	<xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>		earlier drafts made use of a list of name value pairs. This was not
	</xs:sequence>		considered to be very XML like and also lacked inbuilt support for
	<xs:attribute name="Name" type="xs:string" use="required"/>		typing. Hence the current apporach is to have within KeyData a set
	</xs:complexType>		of elements that have both typing and can be encrypted.
	The attributes of the Data element have the following meanings:		All elements within Data hence obey a simple structure in that they
			MUST have:
	o Name, defines the name of the name-value pair, Section 7 defines a		a choice between:
	list of reserved attribute names
			A <PlainValue> element that is typed to the specific type (e.g.
			xs:integer)
			An <EncryptedValue> element that is of type xenc:EncryptedDataType
			where the value of the specific element is placed in case it is
			encrypted
			an optional <ValueMac> element that is populated with a MAC in case
			the encryption algorithm does not support integrity checks
			For example the pskc:intDataType is defined as follows:
			<xs:complexType name="intDataType">
			<xs:sequence>
			<xs:choice>
			<xs:element name="PlainValue"
			type="xs:int"/>
			<xs:element name="EncryptedValue"
			type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC"
			type="xs:base64Binary" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			The following typed base types have been defined within the current
			schema of the PSKC spec with the naming convention <type>DataType
			(e.g. intDataType) to be able to cater transmission of key data
			elements:
			pskc:intDataType - to carry data elements of type integer,
			PlainValue sub element is of type xs:integer. When encrypted the
			binary value MUST be 4 bytes unsigned integer in big endian (i.e.
			network byte order) form
			pskc:longDataType - to carry data elements of type long,
			PlainValue sub element is of type xs:long. When encrypted the
			binary value MUST be 8 bytes unsigned integer in big endian (i.e.
			network byte order) form
			pskc:binaryDataType - to carry data elements of type binary,
			PlainValue sub element is of type xs:Base64Binary
			pskc:stringDataType - to carry data elements of type string,
			PlainValue sub element is of type xs:string. When encrypted the
			binary value MUST UTF-8 encoded string in binary form
			Therefore the KeyData element is defined as follows and contains sub
			ements to convey the values required by algorithms considered during
			the definition of this specification:
			<xs:complexType name="KeyDataType">
			<xs:sequence>
			<xs:element name="Secret" type="pskc:binaryDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="Counter" type="pskc:longDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="Time" type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="TimeInterval" type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="TimeDrift" type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:any namespace="##other" minOccurs="0"
			maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
	The elements of the Data element have the following meanings:		The elements of the Data element have the following meanings:
	o The <PlainValue> conveys an unencrypted value of the name-value		o <Secret> (OPTIONAL), the value of the key itself in binary.
	pair in base 64 encoding.
	o The <EncryptedValue> element in the DataType conveys an encrypted		o <Counter> (OPTIONAL), the event counter for event based OTP
	value of the name-value pair inside an EncryptedDataType as		algorithms.
	defined in XML Encryption.
	o The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed		o <Time> (OPTIONAL), the time for time based OTP algorithms. (If
	MAC value of the unencrypted data for the cases where the		time interval is used, this element carries the number of time
	algorithm to protect key data in transit, as described in section		intervals passed from a specific start point, normally algorithm
	Section 6.1.1 ,does not support integrity checks.		dependent)
	5.4.2. Usage (MANDATORY)		o <TimeInterval> (OPTIONAL), the time interval value for time based
			OTP algorithms.
			o <TimeDrift> (OPTIONAL), the device clock drift value for time
			based OTP algorithms. The value indicates number of seconds that
			the device clock may drift each day.
			o <xs:any ..> the extension point for carrying future elements.
			Please note that all elements added MUST carry PlainValue and
			EncryptedValue sub eleemnts as described above.
			5.4.2. Usage
	The Usage element defines the usage attribute(s) of the key entity.		The Usage element defines the usage attribute(s) of the key entity.
	Usage is defined as follows:		Usage is defined as follows:
	<xs:complexType name="UsageType">		<xs:complexType name="UsageType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="ChallengeFormat" minOccurs="0">		<xs:element name="ChallengeFormat" minOccurs="0">
	<xs:complexType>		<xs:complexType>
	<xs:attribute name="Format"		<xs:attribute name="Format"
	type="pskc:ValueFormatType"		type="pskc:ValueFormatType"
	skipping to change at page 22, line 31 ¶		skipping to change at page 26, line 31 ¶
	<xs:complexType>		<xs:complexType>
	<xs:attribute name="Format"		<xs:attribute name="Format"
	type="pskc:ValueFormatType"		type="pskc:ValueFormatType"
	use="required"/>		use="required"/>
	<xs:attribute name="Length"		<xs:attribute name="Length"
	type="xs:unsignedInt" use="required"/>		type="xs:unsignedInt" use="required"/>
	<xs:attribute name="CheckDigits"		<xs:attribute name="CheckDigits"
	type="xs:boolean" default="false"/>		type="xs:boolean" default="false"/>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="OTP" type="xs:boolean"		<xs:attribute name="OTP" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="CR" type="xs:boolean"		<xs:attribute name="CR" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="Integrity" type="xs:boolean"		<xs:attribute name="Integrity" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="Encrypt" type="xs:boolean"		<xs:attribute name="Encrypt" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="Unlock" type="xs:boolean"		<xs:attribute name="Unlock" type="xs:boolean"
	default="false"/>		default="false"/>
			<xs:anyAttribute namespace="##other"/>
	</xs:complexType>		</xs:complexType>
	The attributes of the Usage element define the intended usage of the		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		key. This list of attributes is extensible for future needs. They
	true):		are a combination of one or more of the following (set to true):
	o OTP, the key will be used for OTP generation		o OTP, the key will be used for OTP generation
	o CR, the key will be used for Challenge/Response purposes		o CR, the key will be used for Challenge/Response purposes
	o Encrypt, the key will be used for data encryption purposes		o Encrypt, the key will be used for data encryption purposes
	o Integrity, the key will be used to generate a keyed message digest		o Integrity, the key will be used to generate a keyed message digest
	for data integrity or authentication purposes.		for data integrity or authentication purposes.
	o Unlock, the key will be used for an inverse challenge response in		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		the case a user has locked the device by entering a wrong PIN too
	many times (for devices with PIN-input capability)		many times (for devices with PIN-input capability)
	5.4.2.1. OTP and CR specific Usage elements (OPTIONAL)		The <Extensions> (OPTIONAL) element, is the extension point for the
			Usage entity. All extensions are grouped under this element and will
			be of type pskc:ExtensionType, which contains an optional attribute
			'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
			<Extensions>
			<MyExtension1
			definition="http://ACME/MyExtension1.html">blah</Myextension1>
			<YourExtension99>blahblah</YourExtension99>
			</Extensions>
			5.4.2.1. OTP and CR specific Usage elements
	When the intended usage of a key usage is OTP and/or CR, the		When the intended usage of a key usage is OTP and/or CR, the
	following additional elements MUST be provided within the Usage		following additional elements MUST be provided within the Usage
	element to support the OTP and/or the response computation as		element to support the OTP and/or the response computation as
	required by the underlying algorithm. These elements also allow to		required by the underlying algorithm. These elements also allow
	customize or configure the result of the computation (e.g. format,		customizing or configuring the result of the computation (e.g.
	length).		format, length).
	5.4.2.1.1. ChallengeFormat element (MANDATORY)		5.4.2.1.1. ChallengeFormat element (OPTIONAL)
	The ChallengeFormat element defines the characteristics of the		The ChallengeFormat element defines the characteristics of the
	challenge in a CR usage scenario. The Challenge element is defined		challenge in a CR usage scenario. The Challenge element is defined
	by the following attributes:		by the following attributes:
	o Format (MANDATORY)		o Format (MANDATORY), defines the format of the challenge accepted
			by the device and MUST be one of the values defined in
	Defines the format of the challenge accepted by the device and		Section 5.4.3
	MUST be one of the values defined in Section 5.4.3
	o CheckDigit (OPTIONAL)
	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:
	TRUE device will check the appended Luhn check digit in a
	provided challenge
	FALSE device will not check appended Luhn check digit in
	challenge
	o Min (MANDATORY)
	Defines the minimum size of the challenge accepted by the
	device for CR mode.
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
	'ALPHANUMERIC' this value indicates the minimum number of
	digits/characters.
	If the Format attribute is 'BASE64' or 'BINARY', this value
	indicates the minimum number of bytes of the unencoded value.
	Value MUST be:
	Unsigned integer.
	o Max (MANDATORY)
	Defines the maximum size of the challenge accepted by the		o CheckDigit (OPTIONAL), defines if the device needs to check the
	device for CR mode.		appended Luhn check digit contained in a provided challenge. This
			is only valid if the Format attribute is 'DECIMAL'. Value MUST
			be:
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or		TRUE device will check the appended Luhn check digit in a
	'ALPHANUMERIC' this value indicates the maximum number of		provided challenge
	digits/characters.
	If the Format attribute is 'BASE64' or 'BINARY', this value		FALSE device will not check appended Luhn check digit in
	indicates the maximum number of bytes of the unencoded value.		challenge
	Value MUST be:		o Min (MANDATORY), defines the minimum size of the challenge
			accepted by the device for CR mode. If the Format attribute is
			'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
			the minimum number of digits/characters. If the Format attribute
			is 'BASE64' or 'BINARY', this value indicates the minimum number
			of bytes of the unencoded value. Value MUST be Unsigned integer.
	Unsigned integer.		o Max (MANDATORY), defines the maximum size of the challenge
			accepted by the device for CR mode. If the Format attribute is
			'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
			the maximum number of digits/characters. If the Format attribute
			is 'BASE64' or 'BINARY', this value indicates the maximum number
			of bytes of the unencoded value. Value MUST be Unsigned integer.
	5.4.2.1.2. ResponseFormat element (MANDATORY)		5.4.2.1.2. ResponseFormat element (MANDATORY)
	The ResponseFormat element defines the characteristics of the result		The ResponseFormat element defines the characteristics of the result
	of a computation. This defines the format of the OTP or of the		of a computation. This defines the format of the OTP or of the
	response to a challenge. The Response attribute is defined by the		response to a challenge. For cases where the key is a PIN value,
	following attributes:		this element contains the format of the PIN itself (e.g. DECIMAL,
			length 4 for a 4 digit PIN). The Response attribute is defined by
	o Format (MANDATORY)		the following attributes:
	Defines the format of the response generated by the device and
	MUST be one of the values defined in Section 5.4.3
	o CheckDigit (OPTIONAL)
	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:
	TRUE device will append a Luhn check digit to the response.
	FALSE device will not append a Luhn check digit to the
	response.
	o Length (MANDATORY)
	Defines the length of the response generated by the device.		o Format (MANDATORY), defines the format of the response generated
			by the device and MUST be one of the values defined in
			Section 5.4.3
	If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or		o CheckDigit (OPTIONAL), defines if the device needs to append a
	'ALPHANUMERIC' this value indicates the number of digits/		Luhn check digit to the response. This is only valid if the
	characters.		Format attribute is 'DECIMAL'. Value MUST be:
	If the Format attribute is 'BASE64' or 'BINARY', this value		TRUE device will append a Luhn check digit to the response.
	indicates the number of bytes of the unencoded value.
	Value MUST be:		FALSE device will not append a Luhn check digit to the
			response.
	Unsigned integer.		o Length (MANDATORY), defines the length of the response generated
			by the device. If the Format attribute is 'DECIMAL',
			'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
			digits/characters. If the Format attribute is 'BASE64' or
			'BINARY', this value indicates the number of bytes of the
			unencoded value. Value MUST be Unsigned integer.
	5.4.3. ValueFormat		5.4.3. ValueFormat
	The ValueFormat element defines allowed formats for challenges or		The ValueFormat element defines allowed formats for challenges or
	responses in OTP algorithms.		responses in OTP algorithms.
	ValueFormat is defined as follows:		ValueFormat is defined as follows:
	<simpleType name="ValueFormat">		<simpleType name="ValueFormat">
	<restriction base="string">		<restriction base="string">
	<enumeration value="DECIMAL"/>		<enumeration value="DECIMAL"/>
	<enumeration value="HEXADECIMAL"/>		<enumeration value="HEXADECIMAL"/>
	<enumeration value="ALPHANUMERIC"/>		<enumeration value="ALPHANUMERIC"/>
	<enumeration value="BASE64"/>		<enumeration value="BASE64"/>
	<enumeration value="BINARY"/>		<enumeration value="BINARY"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	DECIMAL Only numerical digits
	HEXADECIMAL Hexadecimal response		DECIMAL, Only numerical digits
	ALPHANUMERIC All letters and numbers (case sensitive)		HEXADECIMAL, Hexadecimal response
	BASE64 Base 64 encoded		ALPHANUMERIC, All letters and numbers (case sensitive)
	BINARY Binary data, this is mainly used in case of connected		BASE64, Base 64 encoded
			BINARY, Binary data, this is mainly used in case of connected
	devices		devices
	5.4.4. PINPolicy		5.4.4. PINPolicy
	The PINPolicy element provides a mean to define how the usage of a		The PINPolicy element provides an extensible mean to define how the
	specific key is protected by a PIN. The PIN itself can be		usage of a specific key is protected by a PIN. The PIN itself can be
	transmitted as a key using the container.		transmitted as a key using the container.
	If the PINPolicy element is present in the Key element then the key		If the PINPolicy element is present in the Key element then the key
	is protected with a PIN as defined within the PINPolicy element.		is protected with a PIN as defined within the PINPolicy element. The
			PINPolicy element also has an extension point defined as xs:any to
			allow future extensibility
	PINPolicy is defined as follows:		PINPolicy is defined as follows:
	<xs:complexType name="PINPolicyType">		<xs:complexType name="PINPolicyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>		<xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
	<xs:element name="WrongPINtry" type="xs:unsignedInt"		<xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="MinLength"
			type="xs:unsignedInt" minOccurs="0"/>
			<xs:element name="MaxLength"
			type="xs:unsignedInt" minOccurs="0"/>
			<xs:element name="Format"
			type="pskc:ValueFormatType" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="PINKeyId" type="xs:string" use="required"/>		<xs:attribute name="PINKeyId" type="xs:string" use="optional"/>
	</xs:complexType>		</xs:complexType>
	The attributes of PINPolicy have the following meaning		The attributes of PINPolicy have the following meaning
	o PINKeyId, the unique key Id within this container that contains		o PINKeyId (OPTIONAL), the unique key Id of the key held within this
	the value of the PIN that protects the key		container that contains the value of the PIN that protects the key
	The elements of PINPolicy have the following meaning		The elements of PINPolicy have the following meaning
	o <PINUsageMode (MANDATORY)> , the way the PIN is used during the		o <PINUsageMode> (MANDATORY) , the way the PIN is used during the
	usage of the key as defined in Section 5.4.4.1		usage of the key as defined in Section 5.4.4.1
	o <WrongPINtry (OPTIONAL)>, the number of times the PIN can be		o <MaxFailedAttempts> (OPTIONAL), the maximum number of times the
	entered wrongly before it MUST not be possible to use the key		PIN can be entered wrongly before it MUST not be possible to use
	anymore		the key anymore
			o <MinLength> (OPTIONAL), the minimum lenght of a PIN that can be
			set to protect this key. It MUST not be possible to set a PIN
			shorter than this value. If the Format element is 'DECIMAL',
			'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
			digits/characters. If the Format attribute is 'BASE64' or
			'BINARY', this value indicates the number of bytes of the
			unencoded value.
			o <MaxLength> (OPTIONAL), the maximum lenght of a PIN that can be
			set to protect this key. It MUST not be possible to set a PIN
			longer than this value. If the Format element is 'DECIMAL',
			'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
			digits/characters. If the Format attribute is 'BASE64' or
			'BINARY', this value indicates the number of bytes of the
			unencoded value.
			o <Format> (OPTIONAL), defines the format of the PIN and MUST be one
			of the values defined in Section 5.4.3
			o <Extensions> (OPTIONAL) element, is the extension point for the
			entity. All extensions are grouped under this element and will be
			of type pskc:ExtensionType, which contains an optional attribute
			'defintion' that can have a URI pointing at the defintion of the
			extension. In this way groups of extension can be bundled under a
			subelement. For example:
			<Extensions>
			<MyExtension1
			definition="http://ACME/MyExtension1.html">blah</Myextension1>
			<YourExtension99>blahblah</YourExtension99>
			</Extensions>
	5.4.4.1. PINUsageMode		5.4.4.1. PINUsageMode
	The PINUsageMode element defines how the PIN is used with a specific		The PINUsageMode element defines how the PIN is used with a specific
	key		key. The PINUsageMode element also has an extension point defined as
			xs:any to allow future extensibility
	PINUsageMode is defined as follows:		PINUsageMode is defined as follows:
	<xs:complexType name="PINUsageModeType">		<xs:complexType name="PINUsageModeType">
	<xs:choice maxOccurs="unbounded">		<xs:choice maxOccurs="unbounded">
	<xs:element name="Local"/>		<xs:element name="Local"/>
	<xs:element name="Prepend"/>		<xs:element name="Prepend"/>
	<xs:element name="InAlgo"/>		<xs:element name="Append"/>
			<xs:element name="Algorithmic"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
	</xs:choice>		</xs:choice>
	</xs:complexType>		</xs:complexType>
	The elements of PINPolicy have the following meaning		The elements of PINPolicy have the following meaning
	o <Local>, the PIN is checked locally on the device before allowing		o <Local>, the PIN is checked locally on the device before allowing
	the key to be used in executing the algorithm		the key to be used in executing the algorithm
	o <Prepend>, the PIN is prepended to the OTP or response hance it		o <Prepend>, the PIN is prepended to the OTP or response hence it
	MUST be chacked by the validation server		MUST be checked by the validation server
	o <InAlgo>, the PIN is used as part of the algorithm computation		o <Append>, the PIN is appended to the OTP or response hence it MUST
			be checked by the validation server
			o <Algorithmic>, the PIN is used as part of the algorithm
			computation
	6. Usage and profile of algorithms for the portable symmetric key		6. Usage and profile of algorithms for the portable symmetric key
	container		container
	This section details the use of the XML encryption and XML signature		This section details the use of the XML encryption and XML signature
	elements to protect the keys transported in the cotainer. It also		elements to protect the keys transported in the container. It also
	profiles the number of algorithms supported by XML encryption and XML		profiles the number of algorithms supported by XML encryption and XML
	signature to a mandatory subset for interoperability.		signature to a mandatory subset for interoperability.
	When no algorithm is provided the values within the container are		When no algorithm is provided the values within the container are
	unencrypted, implementations SHALL ensure the privacy of the key data		unencrypted, implementations SHALL ensure the privacy of the key data
	through other standard mechanisms e.g. transport level encryption.		through other standard mechanisms e.g. transport level encryption.
	6.1. Usage of EncryptionKey to protect keys in transit		6.1. Usage of EncryptionKey to protect keys in transit
	The EncryptionKey element in the KeyContainer defines the key,		The EncryptionKey element in the KeyContainer defines the key,
	skipping to change at page 28, line 37 ¶		skipping to change at page 33, line 37 ¶
	The following sections define specifically the different supported		The following sections define specifically the different supported
	means to protect the keys:		means to protect the keys:
	6.1.1. Protecting keys using a pre-shared key via symmetric algorithms		6.1.1. Protecting keys using a pre-shared key via symmetric algorithms
	When protecting the payload with pre-shared keys implementations		When protecting the payload with pre-shared keys implementations
	SHOULD set the name of the specific pre-shared key in the KeyName		SHOULD set the name of the specific pre-shared key in the KeyName
	element of the EncryptionKey of the KeyContainer. For example:		element of the EncryptionKey of the KeyContainer. For example:
	<KeyContainer Version="1.0"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc: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#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<EncryptionKey>		<EncryptionKey>
	<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>		<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
	</EncryptionKey>		</EncryptionKey>
	....		....
	The following is the list of symmetric key encryption algorithm and		The following is the list of symmetric key encryption algorithm and
	possible parameters used to protect the Secret Key data in the		possible parameters used to protect the Secret Key data in the
	container. Systems implementing PSKC MUST support the MANDATORY		container. Systems implementing PSKC MUST support the MANDATORY
	skipping to change at page 29, line 35 ¶		skipping to change at page 34, line 35 ¶
	MUST be set in the MACAlgorithm element in the key container entity		MUST be set in the MACAlgorithm element in the key container entity
	as defined in Section 5.1. Implementations of PSKC MUST support the		as defined in Section 5.1. Implementations of PSKC MUST support the
	MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be		MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be
	one of the following:		one of the following:
	o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY		o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY
	For example:		For example:
	<KeyContainer Version="1.0"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc: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#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<EncryptionKey>		<EncryptionKey>
	<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>		<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
	</EncryptionKey>		</EncryptionKey>
	<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1		<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
	</MACAlgorithm>		</MACAlgorithm>
	.....		.....
	6.1.2. Protecting keys using passphrase based encryption keys		6.1.2. Protecting keys using passphrase based encryption keys
	skipping to change at page 30, line 41 ¶		skipping to change at page 35, line 41 ¶
	xml encryption, it is an optional attribute identifying type		xml encryption, it is an optional attribute identifying type
	information about the plaintext form of the encrypted content.		information about the plaintext form of the encrypted content.
	Please see [XMLENC] section 3.1 Type for more details.		Please see [XMLENC] section 3.1 Type for more details.
	The elements of the DerivedKey have the following meanings:		The elements of the DerivedKey have the following meanings:
	o <KeyDerivationMethod>: URI of the algorithms used to derive the		o <KeyDerivationMethod>: URI of the algorithms used to derive the
	key e.g.		key e.g.
	(http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)		(http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)
	o <ReferenceList (OPTIONAL)>: a list of IDs of the elements that		o <ReferenceList> (OPTIONAL): a list of IDs of the elements that
	have been encrypted by this key		have been encrypted by this key
	o <CarriedKeyName (OPTIONAL)>: friendly name of the key		o <CarriedKeyName> (OPTIONAL): friendly name of the key
	When using the PKCS5 PBE algorithm		When using the PKCS5 PBE algorithm
	(URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)		(URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
	and related parameters, the DerivedKey element MUST be used within		and related parameters, the DerivedKey element MUST be used within
	the EncryptionKey element of the KeyContainer in exactly the form as		the EncryptionKey element of the KeyContainer in exactly the form as
	shown below:		shown below:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer		<KeyContainer
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
	xmlns:pkcs-5=		xmlns:pkcs-5=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"		"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	Version="1.0">		Version="1.0">
	<EncryptionKey>		<EncryptionKey>
	<DerivedKey Id="#Passphrase1">		<DerivedKey Id="#Passphrase1">
	<CarriedKeyName>Passphrase1</CarriedKeyName>		<CarriedKeyName>Passphrase1</CarriedKeyName>
	<KeyDerivationMethod		<KeyDerivationMethod
	skipping to change at page 32, line 5 ¶		skipping to change at page 37, line 5 ¶
	container. Systems implementing PSKC MUST support the MANDATORY		container. Systems implementing PSKC MUST support the MANDATORY
	algorithms detailed below. The encryption algorithm URI can be one		algorithms detailed below. The encryption algorithm URI can be one
	of the following.		of the following.
	o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY		o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY
	o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL		o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL
	For example:		For example:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<pskc:KeyContainer Version="1.0"		<pskc:KeyContainer Version="1.0"
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc: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#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<pskc:EncryptionKey>		<pskc:EncryptionKey>
	<ds:X509Data>		<ds:X509Data>
	<ds:X509Certificate>miib</ds:X509Certificate>		<ds:X509Certificate>miib</ds:X509Certificate>
	</ds:X509Data>		</ds:X509Data>
	</pskc:EncryptionKey>		</pskc:EncryptionKey>
	<pskc:Device>		<pskc:Device>
	<pskc:DeviceId>		<pskc:DeviceInfo>
	<pskc:Manufacturer>ACME</pskc:Manufacturer>		<pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
	<pskc:SerialNo>0755225266</pskc:SerialNo>		<pskc:SerialNo>0755225266</pskc:SerialNo>
	</pskc:DeviceId>		</pskc:DeviceInfo>
	<pskc:Key KeyAlgorithm=		<pskc:Key KeyAlgorithm=
	"http://www.ietf.org/keyprov/pskc#hotp"		"http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="0755225266">
	<pskc:Issuer>AnIssuer</pskc:Issuer>		<pskc:Issuer>AnIssuer</pskc:Issuer>
	<pskc:Usage OTP="true">		<pskc:Usage OTP="true">
	<pskc:ResponseFormat Length="8"		<pskc:ResponseFormat Length="8"
	Format="DECIMAL"/>		Format="DECIMAL"/>
	</pskc:Usage>		</pskc:Usage>
	<pskc:Data Name="COUNTER">		<pskc:Data>
	<pskc:PlainValue>AprkuA==</pskc:PlainValue>		<pskc:Secret>
	</pskc:Data>		<pskc:EncryptedValue Id="ED">
	<pskc:Data Name="SECRET">		<xenc:EncryptionMethod Algorithm=
	<pskc:EncryptedValue Id="ED">		"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
	<xenc:EncryptionMethod		<xenc:CipherData>
	Algorithm=		<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
	"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		</xenc:CipherValue>
	<xenc:CipherData>		</xenc:CipherData>
	<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=		</pskc:EncryptedValue>
	</xenc:CipherValue>		</pskc:Secret>
	</xenc:CipherData>		<pskc:Counter>
	</pskc:EncryptedValue>		<PlainValue>0</PlainValue>
	</pskc:Data>		</pskc:Counter>
	</pskc:Key>		</pskc:Data>
	</pskc:Device>		</pskc:Key>
	</pskc:KeyContainer>		</pskc:Device>
			</pskc:KeyContainer>
	6.3. Profile of Key Algorithm		6.3. Profile of Key Algorithm
	This section profiles the type(s) of algorithm of that can be used by		This section profiles the type(s) of algorithm of that can be used by
	the key(s) transported in the container. The following algorithm		the key(s) transported in the container. The following algorithm
	URIs are among the default support list.		URIs are among the default support list.
	o http://www.w3.org/2001/04/xmlenc#tripledes-cbc		o http://www.w3.org/2001/04/xmlenc#tripledes-cbc
	o http://www.w3.org/2001/04/xmlenc#aes128-cbc		o http://www.w3.org/2001/04/xmlenc#aes128-cbc
	skipping to change at page 33, line 20 ¶		skipping to change at page 38, line 20 ¶
	o http://www.w3.org/2001/04/xmlenc#aes256-cbc		o http://www.w3.org/2001/04/xmlenc#aes256-cbc
	o http://www.ietf.org/keyprov/pskc#hotp		o http://www.ietf.org/keyprov/pskc#hotp
	o http://www.ietf.org/keyprov/pskc#pin		o http://www.ietf.org/keyprov/pskc#pin
	6.3.1. OTP Key Algorithm Identifiers		6.3.1. OTP Key Algorithm Identifiers
	OTP key algorithm URIs have not been defined in a commonly available		OTP key algorithm URIs have not been defined in a commonly available
	standard specification. This document defines the following URIs for		standard specification. This document requests from IANA the
	the standard OTP algorithms defined in [HOTP].		creation of a registry (see Section 8.4) and defines URIs for the
			standard OTP algorithms in Section 8.4.4.
	6.3.1.1. HOTP
	Standard document: RFC4226
	Identifier: http://www.ietf.org/keyprov/pskc#hotp
	Note that the actual URL will be finalized once a URL for this
	document is determined.
	6.3.1.2. Other OTP Algorithms
	An implementation should refer to vendor registered OTP key algorithm
	URIs for other existing OTP algorithms, for example, the RSA SecurID
	OTP algorithm as follows.
	o http://www.rsa.com/rsalabs/otps/schemas/2005/09/
	otps-wst#SecurID-AES
	6.3.2. PIN key value compare algorithm identifier		6.3.2. PIN key value compare algorithm identifier
	PIN key algorithm URIs have not been defined in a commonly available		PIN key algorithm URIs have not been defined in a commonly available
	standard specification. This document defines the following URIs for		standard specification. This document defines the following URIs for
	a straight value comaprison of the transported secret key data as		a straight value comparison of the transported secret key data as
	when required to compare a PIN.		when required to compare a PIN.
	Identifier: http://www.ietf.org/keyprov/pskc#pin		Identifier: http://www.ietf.org/keyprov/pskc#pin
	Note that the actual URL will be finalized once a URL for this		Note that the actual URL will be finalized once a URL for this
	document is determined.		document is determined.
	7. Reserved data attribute names		7. Formal Syntax
	The following key data 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
	algorithms. The value indicates number of seconds that the device
	clock may drift each day. 2 bytes unsigned integer in big endian
	(i.e. network byte order) form base64 encoded.
	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"?>
	<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:pskc: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#"		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:pskc: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#"		<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
	schemaLocation="http://www.w3.org/TR/2002/		schemaLocation="http://www.w3.org/TR/
	REC-xmlenc-core-20021210/xenc-schema.xsd"/>		xmlenc-core/xenc-schema.xsd"/>
	<xs:complexType name="KeyContainerType">		<xs:complexType name="KeyContainerType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="EncryptionKey" type="ds:KeyInfoType"		<xs:element name="EncryptionKey" type="ds:KeyInfoType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"		<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="KeyProperties"
			type="pskc:KeyPropertiesType" minOccurs="0"
			maxOccurs="unbounded"/>
	<xs:element name="Device" type="pskc:DeviceType"		<xs:element name="Device" type="pskc:DeviceType"
	maxOccurs="unbounded"/>		minOccurs="1" maxOccurs="unbounded"/>
	<xs:element name="Signature" type="ds:SignatureType"		<xs:element name="Signature" type="ds:SignatureType"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version" type="pskc:VersionType"		<xs:attribute name="Version" type="pskc:VersionType"
	use="required"/>		use="required"/>
			<xs:attribute name="ID"
			type="xs:ID" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="VersionType" final="restriction">		<xs:simpleType name="VersionType" final="restriction">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:pattern value="\d{1,2}\.\d{1,3}"/>		<xs:pattern value="\d{1,2}\.\d{1,3}"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="KeyPropertiesType">		<xs:complexType name="KeyPropertiesType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Issuer"		<xs:element name="Issuer"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Usage"		<xs:element name="Usage"
	type="pskc:UsageType" minOccurs="0"/>		type="pskc:UsageType" minOccurs="0"/>
	<xs:element name="KeyProfileId"		<xs:element name="KeyProfileId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="MasterKeyId"		<xs:element name="MasterKeyId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Data" type="pskc:DataType"		<xs:element name="Data" type="pskc:KeyDataType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="PINPolicy"		<xs:element name="PINPolicy"
	type="pskc:PINPolicyType" minOccurs="0"/>		type="pskc:PINPolicyType" minOccurs="0"/>
	<xs:element name="ExpiryDate"
	type="xs:dateTime" minOccurs="0"/>
	<xs:element name="StartDate"		<xs:element name="StartDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
			<xs:element name="ExpiryDate"
			type="xs:dateTime" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="KeyPropertiesId"		<xs:attribute name="ID"
	type="xs:string" use="required"/>		type="xs:ID" use="required"/>
	<xs:attribute name="KeyAlgorithm"		<xs:attribute name="KeyAlgorithm"
	type="pskc:KeyAlgorithmType"		type="pskc:KeyAlgorithmType"
	use="optional"/>		use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyType">		<xs:complexType name="KeyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Issuer"		<xs:element name="Issuer"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Usage"		<xs:element name="Usage"
	type="pskc:UsageType"/>		type="pskc:UsageType"/>
	<xs:element name="KeyProfileId"		<xs:element name="KeyProfileId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="MasterKeyId"		<xs:element name="MasterKeyId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="FriendlyName"		<xs:element name="FriendlyName"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Data" type="pskc:DataType"		<xs:element name="Data" type="pskc:KeyDataType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="PINPolicy"		<xs:element name="PINPolicy"
	type="pskc:PINPolicyType" minOccurs="0"/>		type="pskc:PINPolicyType" minOccurs="0"/>
	<xs:element name="ExpiryDate"
	type="xs:dateTime" minOccurs="0"/>
	<xs:element name="StartDate"		<xs:element name="StartDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
			<xs:element name="ExpiryDate"
			type="xs:dateTime" minOccurs="0"/>
			<xs:element name="UserId" type="xs:string"
			minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="KeyId"		<xs:attribute name="KeyId"
	type="xs:string" use="required"/>		type="xs:string" use="required"/>
	<xs:attribute name="KeyAlgorithm"		<xs:attribute name="KeyAlgorithm"
	type="pskc:KeyAlgorithmType"		type="pskc:KeyAlgorithmType"
	use="required"/>		use="required"/>
			<xs:attribute name="KeyProperties"
			type="xs:IDREF" use="optional"/>
			</xs:complexType>
			<xs:complexType name="KeyDataType">
			<xs:sequence>
			<xs:element name="Secret"
			type="pskc:binaryDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="Counter"
			type="pskc:longDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="Time"
			type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="TimeInterval"
			type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:element name="TimeDrift"
			type="pskc:intDataType"
			minOccurs="0" maxOccurs="1"/>
			<xs:any namespace="##other"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexType>
			<xs:complexType name="binaryDataType">
			<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:complexType>
			<xs:complexType name="intDataType">
			<xs:sequence>
			<xs:choice>
			<xs:element name="PlainValue"
			type="xs:int"/>
			<xs:element name="EncryptedValue"
			type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC"
			type="xs:base64Binary" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			<xs:complexType name="stringDataType">
			<xs:sequence>
			<xs:choice>
			<xs:element name="PlainValue"
			type="xs:string"/>
			<xs:element name="EncryptedValue"
			type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC"
			type="xs:base64Binary" minOccurs="0"/>
			</xs:sequence>
			</xs:complexType>
			<xs:complexType name="longDataType">
			<xs:sequence>
			<xs:choice>
			<xs:element name="PlainValue"
			type="xs:long"/>
			<xs:element name="EncryptedValue"
			type="xenc:EncryptedDataType"/>
			</xs:choice>
			<xs:element name="ValueMAC"
			type="xs:base64Binary" minOccurs="0"/>
			</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="DerivedKeyType">		<xs:complexType name="DerivedKeyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="KeyDerivationMethod"		<xs:element name="KeyDerivationMethod"
	type="pskc:KeyDerivationMethodType" minOccurs="0"/>		type="pskc:KeyDerivationMethodType" minOccurs="0"/>
	<xs:element ref="xenc:ReferenceList" minOccurs="0"/>		<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
	<xs:element name="CarriedKeyName" type="xs:string"		<xs:element name="CarriedKeyName" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Id" type="xs:ID" use="optional"/>		<xs:attribute name="Id" type="xs:ID" use="optional"/>
	<xs:attribute name="Type" type="xs:anyURI" use="optional"/>		<xs:attribute name="Type" type="xs:anyURI" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyDerivationMethodType">		<xs:complexType name="KeyDerivationMethodType">
	<xs:sequence>		<xs:sequence>
	<xs:any namespace="##other" minOccurs="0"		<xs:any namespace="##other" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Algorithm" type="xs:anyURI"		<xs:attribute name="Algorithm" type="xs:anyURI"
	use="required"/>		use="required"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="PINPolicyType">		<xs:complexType name="PINPolicyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="PINUsageMode"		<xs:element name="PINUsageMode"
	type="pskc:PINUsageModeType"/>		type="pskc:PINUsageModeType"/>
	<xs:element name="WrongPINtry" type="xs:unsignedInt"		<xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="MinLength"
			type="xs:unsignedInt" minOccurs="0"/>
			<xs:element name="MaxLength"
			type="xs:unsignedInt" minOccurs="0"/>
			<xs:element name="Format"
			type="pskc:ValueFormatType" minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="PINKeyId" type="xs:string"		<xs:attribute name="PINKeyId" type="xs:string"
	use="required"/>		use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="PINUsageModeType">		<xs:complexType name="PINUsageModeType">
	<xs:choice maxOccurs="unbounded">		<xs:choice maxOccurs="unbounded">
	<xs:element name="Local"/>		<xs:element name="Local"/>
	<xs:element name="Prepend"/>		<xs:element name="Prepend"/>
	<xs:element name="Embed"/>		<xs:element name="Append"/>
			<xs:element name="Algorithmic"/>
			<xs:any namespace="##other"
			processContents="lax" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:choice>		</xs:choice>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="DeviceIdType">		<xs:complexType name="DeviceInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Manufacturer" type="xs:string"/>		<xs:element name="Manufacturer" type="xs:string"/>
	<xs:element name="SerialNo" type="xs:string"/>		<xs:element name="SerialNo" type="xs:string"/>
	<xs:element name="Model" type="xs:string"		<xs:element name="Model" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="IssueNo" type="xs:string"		<xs:element name="IssueNo" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="ExpiryDate" type="xs:dateTime"		<xs:element name="DeviceBinding" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="StartDate" type="xs:dateTime"		<xs:element name="StartDate" type="xs:dateTime"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="ExpiryDate" type="xs:dateTime"
			minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="DeviceType">		<xs:complexType name="DeviceType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceId" type="pskc:DeviceIdType"		<xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="Key" type="pskc:KeyType"		<xs:element name="Key" type="pskc:KeyType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	<xs:element name="UserId" type="xs:string"		<xs:element name="User" type="xs:string"
	minOccurs="0"/>		minOccurs="0"/>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="UsageType">		<xs:complexType name="UsageType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="ChallengeFormat" minOccurs="0">		<xs:element name="ChallengeFormat" minOccurs="0">
	<xs:complexType>		<xs:complexType>
	<xs:attribute name="Format"		<xs:attribute name="Format"
	type="pskc:ValueFormatType" use="required"/>		type="pskc:ValueFormatType" use="required"/>
	<xs:attribute name="Min" type="xs:unsignedInt"		<xs:attribute name="Min" type="xs:unsignedInt"
	use="required"/>		use="required"/>
	skipping to change at page 38, line 40 ¶		skipping to change at page 45, line 4 ¶
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="ResponseFormat">		<xs:element name="ResponseFormat">
	<xs:complexType>		<xs:complexType>
	<xs:attribute name="Format"		<xs:attribute name="Format"
	type="pskc:ValueFormatType" use="required"/>		type="pskc:ValueFormatType" use="required"/>
	<xs:attribute name="Length" type="xs:unsignedInt"		<xs:attribute name="Length" type="xs:unsignedInt"
	use="required"/>		use="required"/>
	<xs:attribute name="CheckDigits" type="xs:boolean"		<xs:attribute name="CheckDigits" type="xs:boolean"
	default="false"/>		default="false"/>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
			<xs:element name="Extensions"
			type="pskc:ExtensionsType" minOccurs="0"
			maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="OTP" type="xs:boolean" default="false"/>		<xs:attribute name="OTP" type="xs:boolean" default="false"/>
	<xs:attribute name="CR" type="xs:boolean" default="false"/>		<xs:attribute name="CR" type="xs:boolean" default="false"/>
	<xs:attribute name="Integrity" type="xs:boolean"		<xs:attribute name="Integrity" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="Encrypt" type="xs:boolean"		<xs:attribute name="Encrypt" type="xs:boolean"
	default="false"/>		default="false"/>
	<xs:attribute name="Unlock" type="xs:boolean"		<xs:attribute name="Unlock" type="xs:boolean"
	default="false"/>		default="false"/>
			<xs:anyAttribute namespace="##other"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="DataType">		<xs:complexType name="ExtensionsType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:any namespace="##other" processContents="lax"
	<xs:element name="PlainValue" type="xs:base64Binary"/>		maxOccurs="unbounded"/>
	<xs:element name="EncryptedValue"		</xs:sequence>
	type="xenc:EncryptedDataType"/>		<xs:attribute name="definition" type="xs:anyURI"
	</xs:choice>		use="optional"/>
	<xs:element name="ValueMAC" type="xs:base64Binary"
	minOccurs="0"/>
	</xs:sequence>
	<xs:attribute name="Name" type="xs:string" use="required"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="KeyAlgorithmType">		<xs:simpleType name="KeyAlgorithmType">
	<xs:restriction base="xs:anyURI"/>		<xs:restriction base="xs:anyURI"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="ValueFormatType">		<xs:simpleType name="ValueFormatType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="DECIMAL"/>		<xs:enumeration value="DECIMAL"/>
	<xs:enumeration value="HEXADECIMAL"/>		<xs:enumeration value="HEXADECIMAL"/>
	<xs:enumeration value="ALPHANUMERIC"/>		<xs:enumeration value="ALPHANUMERIC"/>
	<xs:enumeration value="BASE64"/>		<xs:enumeration value="BASE64"/>
	<xs:enumeration value="BINARY"/>		<xs:enumeration value="BINARY"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:element name="KeyContainer" type="pskc:KeyContainerType"/>		<xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
	</xs:schema>		</xs:schema>
	9. IANA Considerations		8. IANA Considerations
	9.1. Content-type registration for 'application/pskc+xml'		8.1. Content-type registration for 'application/pskc+xml'
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: pskc+xml		MIME subtype name: pskc+xml
	Mandatory parameters: none		Mandatory parameters: none
	skipping to change at page 41, line 15 ¶		skipping to change at page 47, line 15 ¶
	Personal and email address for further information: Philip Hoyer,		Personal and email address for further information: Philip Hoyer,
	Philip.Hoyer@actividentity.com		Philip.Hoyer@actividentity.com
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author: This specification is a work item of the IETF KEYPROV		Author: This specification is a work item of the IETF KEYPROV
	working group, with mailing list address <keyprov@ietf.org>.		working group, with mailing list address <keyprov@ietf.org>.
	Change controller: The IESG <iesg@ietf.org>		Change controller: The IESG <iesg@ietf.org>
	9.2. XML Schema Registration		8.2. XML Schema Registration
	This section registers an XML schema as per the guidelines in		This section registers an XML schema as per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:ns:keyprov:container:1.0		URI: urn:ietf:params:xml:ns:keyprov:pskc:1.0
	Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer		Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
	(Philip.Hoyer@actividentity.com).		(Philip.Hoyer@actividentity.com).
	XML Schema: The XML schema to be registered is contained in		XML Schema: The XML schema to be registered is contained in
	Section 8. Its first line is		Section 7. Its first line is
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	and its last line is		and its last line is
	</xs:schema>		</xs:schema>
	9.3. URN Sub-Namespace Registration for		8.3. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:keyprov:container:1.0		urn:ietf:params:xml:ns:keyprov:pskc:1.0
	This section registers a new XML namespace,		This section registers a new XML namespace,
	"urn:ietf:params:xml:ns:keyprov:container:1.0", per the guidelines in		"urn:ietf:params:xml:ns:keyprov:pskc:1.0", per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:ns:keyprov:container:1.0		URI: urn:ietf:params:xml:ns:keyprov:pskc:1.0
	Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer		Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
	(Philip.Hoyer@actividentity.com).		(Philip.Hoyer@actividentity.com).
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">		<html xmlns="http://www.w3.org/1999/xhtml">
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>PSKC Namespace</title>		<title>PSKC Namespace</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for PSKC</h1>		<h1>Namespace for PSKC</h1>
	<h2>urn:ietf:params:xml:ns:keyprov:container:1.0</h2>		<h2>urn:ietf:params:xml:ns:keyprov:pskc:1.0</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	9.4. Symmetric Key Algorithm Identifier Registry		8.4. Symmetric Key Algorithm Identifier Registry
	This specification requests the creation of a new IANA registry for		This specification requests the creation of a new IANA registry for
	symmetric key cryptographic algorithm identifiers in accordance with		symmetric key cryptographic algorithm identifiers in accordance with
	the principles set out in RFC 2434 [RFC2434]as follows:		the principles set out in RFC 2434 [RFC2434]as follows:
	9.4.1. Applicability		8.4.1. Applicability
	The use of URIs as algorithm identifiers provides an effectively		The use of URIs as algorithm identifiers provides an effectively
	unlimited namespace. While this eliminates the possibility of		unlimited namespace. While this eliminates the possibility of
	namespace exhaustion it creates a new concern, that divergent		namespace exhaustion it creates a new concern, that divergent
	identifiers will be employed for the same purpose in different		identifiers will be employed for the same purpose in different
	contexts.		contexts.
	The key algorithm registry is intended to provide a means of		The key algorithm registry is intended to provide a means of
	specifying the canonical identifier to be used for a given algorithm.		specifying the canonical identifier to be used for a given algorithm.
	If an algorithm has an identifier specified in the registry a		If an algorithm has an identifier specified in the registry an
	application that is conformant to a protocol specification that		application that is conformant to a protocol specification that
	specifies use of that registry to define identifiers SHOULD always		specifies use of that registry to define identifiers SHOULD always
	use that particular form of the identifier when originating data. A		use that particular form of the identifier when originating data. A
	conformant application MAY accept other identifiers in data that is		conformant application MAY accept other identifiers in data that is
	received.		received.
	For the sake of expediency, the initial registry only defines		For the sake of expediency, the initial registry only defines
	algorithm classes for symmetric algorithms plus cryptographic message		algorithm classes for symmetric algorithms plus cryptographic message
	digest functions (one-way hash). While the same principles may be		digest functions (one-way hash). While the same principles may be
	extended to asymmetric algorithms, doing so would require much		extended to asymmetric algorithms, doing so would require much
	greater consideration of issues such as key length and treatment of		greater consideration of issues such as key length and treatment of
	parameters, particularly where eliptic curve cryptography algorithms		parameters, particularly where elliptic curve cryptography algorithms
	are concerned.		are concerned.
	As part of this registry the IANA will maintain the following		As part of this registry the IANA will maintain the following
	information:		information:
	Common Name The name by which the algorithm is generally referred.		Common Name The name by which the algorithm is generally referred.
	Class The type of algorithm, encryption, Message Authentication Code		Class The type of algorithm, encryption, Message Authentication Code
	(MAC), One Time Pawword (OTP), Digest, etc.		(MAC), One Time Password (OTP), Digest, etc.
	Cannonical URI The cannonical URI to be used to identify the		Canonical URI The canonical URI to be used to identify the
	algorithm.		algorithm.
	Algorithm Definition A reference to the document in which the		Algorithm Definition A reference to the document in which the
	algorithm described by the identifier is defined.		algorithm described by the identifier is defined.
	Identifier Definition A reference to the document in which the use		Identifier Definition A reference to the document in which the use
	of the identifier to refer to the algorithm is described. This		of the identifier to refer to the algorithm is described. This
	would ideally be the document in which the algorithm is defined.		would ideally be the document in which the algorithm is defined.
	In the case where the registrant does not request a particular		In the case where the registrant does not request a particular
	URI, the IANA will assign it a Uniform Resource Name (URN) that		URI, the IANA will assign it a Uniform Resource Name (URN) that
	follows RFC 3553 [RFC3553].		follows RFC 3553 [RFC3553].
	Note that where a single algorithm has different forms distinguished		Note that where a single algorithm has different forms distinguished
	by paremeters such as key length, the algorithm class and each		by parameters such as key length, the algorithm class and each
	combination of algorithm parameters may be considered a distinct		combination of algorithm parameters may be considered a distinct
	algorithm for the purpose of assigning identifiers.		algorithm for the purpose of assigning identifiers.
	9.4.2. Registerable Algorithms		8.4.2. Registerable Algorithms
	9.4.2.1. Assigned URIs		8.4.2.1. Assigned URIs
	If the registrant wishes to have a URI assigned, then a URN of the		If the registrant wishes to have a URI assigned, then a URN of the
	form		form
	urn:ietf:params:xml:<class>:<id>		urn:ietf:params:xml:<class>:<id>
	will be assigned where <class> is the type of the algorithm being		will be assigned where <class> is the type of the algorithm being
	identified (see below). <id> is a unique id specified by the party		identified (see below). <id> is a unique id specified by the party
	making the request and will normally be either the common name of the		making the request and will normally be either the common name of the
	algorithm or an abbreviation thereof.		algorithm or an abbreviation thereof.
	NOTE: in order for a URN of this type to be assigned, the item being		NOTE: in order for a URN of this type to be assigned, the item being
	registered MUST have been through the IETF consensus process.		registered MUST have been through the IETF consensus process.
	Basically, this means that it must be documented in a RFC.		Basically, this means that it must be documented in a RFC.
	NOTE: Expert Review is sufficient in cases where the request does not		NOTE: Expert Review is sufficient in cases where the request does not
	require a URN assignment inthe IETF namespace. IETF consensus is not		require a URN assignment in the IETF namespace. IETF consensus is
	required.		not required.
	9.4.2.2. Assigned Classes		8.4.2.2. Assigned Classes
	Each algorithm MUST belong to an assigned algorithm class. In the		Each algorithm MUST belong to an assigned algorithm class. In the
	case that additional classes are required these are to be specified		case that additional classes are required these are to be specified
	by IETF Consensus action.		by IETF Consensus action.
	The initial assigned classes are:		The initial assigned classes are:
	Digest A cryptographic Digest algorithm.		Digest A cryptographic Digest algorithm.
	MAC A Message Authentication Code algorithm.		MAC A Message Authentication Code algorithm.
	Symmetric A symmetric encryption algorithm.		Symmetric A symmetric encryption algorithm.
	OTP A one time password (OTP) algorithm.		OTP A one time password (OTP) algorithm.
	9.4.3. Registration Procedures		8.4.3. Registration Procedures
	9.4.3.1. Review		8.4.3.1. Review
	Algorithm identifier registrations are to be subject to Expert Review		Algorithm identifier registrations are to be subject to Expert Review
	as per RFC 2434 [RFC2434].		as per RFC 2434 [RFC2434].
	The need for supporting documentation for the registration depends on		The need for supporting documentation for the registration depends on
	the nature of the request. In the case of a cryptographic algorithm		the nature of the request. In the case of a cryptographic algorithm
	that is being described for publication as an RFC, the request for a		that is being described for publication as an RFC, the request for a
	URI allocation would normally appear within the RFC itself. In the		URI allocation would normally appear within the RFC itself. In the
	case of a cryptographic algorithm that is fully and comprehensively		case of a cryptographic algorithm that is fully and comprehensively
	defined in another form, it would not be necessary to duplicate the		defined in another form, it would not be necessary to duplicate the
	skipping to change at page 45, line 13 ¶		skipping to change at page 51, line 13 ¶
	the notice of the proposers of the registration and the Security Area		the notice of the proposers of the registration and the Security Area
	Directors. If the proposers are not willing to accept registration		Directors. If the proposers are not willing to accept registration
	of the existing identifier the IETF Consensus policy is to apply.		of the existing identifier the IETF Consensus policy is to apply.
	In reviewing a request, the expert should consider whether the		In reviewing a request, the expert should consider whether the
	algorithm is sufficiently defined to allow successful interoperation.		algorithm is sufficiently defined to allow successful interoperation.
	In particular the expert should consider whether issues such as key		In particular the expert should consider whether issues such as key
	sizes and byte order are sufficiently defined to allow for		sizes and byte order are sufficiently defined to allow for
	interoperation.		interoperation.
	While the defintion requirement MAY be satisifed by a comprehensive		While the definition requirement MAY be satisfed by a comprehensive
	specification of the algorithm, disclosure of the algorithm is not		specification of the algorithm, disclosure of the algorithm is not
	mandatory.		mandatory.
	9.4.3.2. Canonical URI		8.4.3.2. Canonical URI
	Until the IANA requests or implements an automated process for the		Until the IANA requests or implements an automated process for the
	registration of these elements, any specifications must make that		registration of these elements, any specifications must make that
	request part of the IANA considerations section of their respective		request part of the IANA considerations section of their respective
	documents. That request must be in the form of the following		documents. That request must be in the form of the following
	template:		template:
	Common Name The name by which the algorithm is generally referred.		Common Name The name by which the algorithm is generally referred.
	Class The type of algorithm, encryption, Message Authentication Code		Class The type of algorithm, encryption, Message Authentication Code
	(MAC), One Time Pawword (OTP), Digest, etc. As specified by a		(MAC), One Time Password (OTP), Digest, etc. As specified by a
	defined algorithm class.		defined algorithm class.
	URI The cannonical URI to be used to identify the algorithm.		URI The canonical URI to be used to identify the algorithm.
	Algorithm Definition A reference to the document in which the		Algorithm Definition A reference to the document in which the
	algorithm described by the identifier is defined.		algorithm described by the identifier is defined.
	Identifier Definition A reference to the document in which the use		Identifier Definition A reference to the document in which the use
	of the identifier to refer to the algorithm is described. This		of the identifier to refer to the algorithm is described. This
	would ideally be the document in which the algorithm is defined.		would ideally be the document in which the algorithm is defined.
	Registrant Contact A reference to the document in which the use of		Registrant Contact A reference to the document in which the use of
	the identifier to refer to the algorithm is described. This would		the identifier to refer to the algorithm is described. This would
	ideally be the document in which the algorithm is defined.		ideally be the document in which the algorithm is defined.
	9.4.3.3. Alias URI		8.4.3.3. Alias URI
	In the case that multiple identifiers have been assigned to the same		In the case that multiple identifiers have been assigned to the same
	identifiers, additional identifiers MAY be registered as aliases. An		identifiers, additional identifiers MAY be registered as aliases. An
	entry for an alias contains all the entries for a canonical URI with		entry for an alias contains all the entries for a canonical URI with
	the addition of a reference to the canonical URI to be used:		the addition of a reference to the canonical URI to be used:
	Alias for URI The cannonical URI that identifies the algorithm. The		Alias for URI The canonical URI that identifies the algorithm. The
	URI referenced MUST be a canonical URI.		URI referenced MUST be a canonical URI.
	In the case of dispute as to which URI is to be considered canonical		In the case of dispute as to which URI is to be considered canonical
	the matter is to be settled by IESG action.		the matter is to be settled by IESG action.
	9.4.4. Initial Values		8.4.4. Initial Values
	The following initial values are defined. Note that these values are		The following initial values are defined. Note that these values are
	limited to identifiers that are required by KEYPROV but not specified		limited to identifiers that are required by KEYPROV but not specified
	elsewhere:		elsewhere:
	9.4.4.1. HOTP		8.4.4.1. HOTP
	Common Name: HOTP		Common Name: HOTP
	Class: OTP		Class: OTP
	URI: http://www.ietf.org/keyprov/pskc#hotp		URI: http://www.ietf.org/keyprov/pskc#hotp
	Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt		Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt
	Identifier Definition (this RFC)		Identifier Definition (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
	9.4.4.2. HOTP-HMAC-SHA-1		8.4.4.2. OCRA (OATH Chellenge Response Algorithm)
	Common Name: HOTP-HMAC-SHA-1		Common Name: OCRA
	Class: OTP		Class: OTP
	URI: http://www.ietf.org/rfc/rfc4226.txt#HOTP-HMAC-SHA-1		URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)
			- e.g.
			http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08
	Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt		Algorithm Definition: http://www.ietf.org/internet-drafts/
			draft-mraihi-mutual-oath-hotp-variants-07.txt
	Identifier Definition (this RFC)		Identifier Definition (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
	9.4.4.3. KEYPROV-PIN		8.4.4.3. TOTP (OATH Time based OTP)
			Common Name: TOTP
			Class: OTP
			URI: http://www.ietf.org/keyprov/pskc#totp
			Algorithm Definition: http://www.ietf.org/internet-drafts/
			draft-mraihi-totp-timebased-00.txt
			Identifier Definition (this RFC)
			Registrant Contact: IESG
			8.4.4.4. KEYPROV-PIN
	Common Name: KEYPROV-PIN		Common Name: KEYPROV-PIN
	Class: Symmetric static credential comparison		Class: Symmetric static credential comparison
	URI: http://www.ietf.org/keyprov/pskc#pin		URI: http://www.ietf.org/keyprov/pskc#pin
	Algorithm Definition: (this document)		Algorithm Definition: (this document)
	Identifier Definition (this document)		Identifier Definition (this document)
	Registrant Contact: IESG		Registrant Contact: IESG
	9.4.4.4. SecurID-AES		8.4.4.5. SecurID-AES
	Common Name: SecurID-AES		Common Name: SecurID-AES
	Class: OTP		Class: OTP
	URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/		URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
	otps-wst#SecurID-AES		otps-wst#SecurID-AES
	Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821		Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
	Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821		Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821
	Registrant Contact: Andrea Doherty, RSA the Security Division of		Registrant Contact: Andrea Doherty, RSA the Security Division of
	EMC, <andrea.doherty@rsa.com>		EMC, <andrea.doherty@rsa.com>
	9.4.4.5. SecurID-ALGOR		8.4.4.6. SecurID-AES-Counter
			Common Name: SecurID-AES-Counter
			Class: OTP
			URI: http://www.rsa.com/names/2008/04/algorithms/
			SecurID#SecurID-AES128-Counter
			Algorithm Definition: http://www.rsa.com/names/2008/04/algorithms/
			SecurID#SecurID-AES128-Counter
			Identifier Definition http://www.rsa.com/names/2008/04/algorithms/
			SecurID#SecurID-AES128-Counter
			Registrant Contact: Andrea Doherty, RSA the Security Division of
			EMC, <andrea.doherty@rsa.com>
			8.4.4.7. SecurID-ALGOR
	Common Name: SecurID-ALGOR		Common Name: SecurID-ALGOR
	Class: OTP		Class: OTP
	URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/		URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
	otps-wst#SecurID-ALGOR		otps-wst#SecurID-ALGOR
	Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821		Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
	Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821		Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821
	Registrant Contact: Andrea Doherty, RSA the Security Division of		Registrant Contact: Andrea Doherty, RSA the Security Division of
	EMC, <andrea.doherty@rsa.com>		EMC, <andrea.doherty@rsa.com>
	9.4.4.6. ActivIdentity-3DES		8.4.4.8. ActivIdentity-3DES
	Common Name: ActivIdentity-3DES		Common Name: ActivIdentity-3DES
	Class: OTP		Class: OTP
	URI: http://www.actividentity.com/2008/04/algorithms/		URI: http://www.actividentity.com/2008/04/algorithms/
	algorithms#ActivIdentity-3DES		algorithms#ActivIdentity-3DES
	Algorithm Definition: http://www.actividentity.com/2008/04/		Algorithm Definition: http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-3DES		algorithms/algorithms#ActivIdentity-3DES
	Identifier Definition http://www.actividentity.com/2008/04/		Identifier Definition http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-3DES		algorithms/algorithms#ActivIdentity-3DES
	Registrant Contact: Philip Hoyer, ActivIdentity Inc,		Registrant Contact: Philip Hoyer, ActivIdentity Inc,
	<philip.hoyer@actividentity.com>		<philip.hoyer@actividentity.com>
	9.4.4.7. ActivIdentity-AES		8.4.4.9. ActivIdentity-AES
	Common Name: ActivIdentity-AES		Common Name: ActivIdentity-AES
	Class: OTP		Class: OTP
	URI: http://www.actividentity.com/2008/04/algorithms/		URI: http://www.actividentity.com/2008/04/algorithms/
	algorithms#ActivIdentity-AES		algorithms#ActivIdentity-AES
	Algorithm Definition: http://www.actividentity.com/2008/04/		Algorithm Definition: http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-AES		algorithms/algorithms#ActivIdentity-AES
	Identifier Definition http://www.actividentity.com/2008/04/		Identifier Definition http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-AES		algorithms/algorithms#ActivIdentity-AES
	Registrant Contact: Philip Hoyer, ActivIdentity Inc,		Registrant Contact: Philip Hoyer, ActivIdentity Inc,
	<philip.hoyer@actividentity.com>		<philip.hoyer@actividentity.com>
	9.4.4.8. ActivIdentity-DES		8.4.4.10. ActivIdentity-DES
	Common Name: ActivIdentity-DES		Common Name: ActivIdentity-DES
	Class: OTP		Class: OTP
	URI: http://www.actividentity.com/2008/04/algorithms/		URI: http://www.actividentity.com/2008/04/algorithms/
	algorithms#ActivIdentity-DES		algorithms#ActivIdentity-DES
	Algorithm Definition: http://www.actividentity.com/2008/04/		Algorithm Definition: http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-DES		algorithms/algorithms#ActivIdentity-DES
	Identifier Definition http://www.actividentity.com/2008/04/		Identifier Definition http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-DES		algorithms/algorithms#ActivIdentity-DES
	Registrant Contact: Philip Hoyer, ActivIdentity Inc,		Registrant Contact: Philip Hoyer, ActivIdentity Inc,
	<philip.hoyer@actividentity.com>		<philip.hoyer@actividentity.com>
	9.4.4.9. ActivIdentity-EVENT		8.4.4.11. ActivIdentity-EVENT
	Common Name: ActivIdentity-EVENT		Common Name: ActivIdentity-EVENT
	Class: OTP		Class: OTP
	URI: http://www.actividentity.com/2008/04/algorithms/		URI: http://www.actividentity.com/2008/04/algorithms/
	algorithms#ActivIdentity-EVENT		algorithms#ActivIdentity-EVENT
	Algorithm Definition: http://www.actividentity.com/2008/04/		Algorithm Definition: http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-EVENT		algorithms/algorithms#ActivIdentity-EVENT
	Identifier Definition http://www.actividentity.com/2008/04/		Identifier Definition http://www.actividentity.com/2008/04/
	algorithms/algorithms#ActivIdentity-EVENT		algorithms/algorithms#ActivIdentity-EVENT
	Registrant Contact: Philip Hoyer, ActivIdentity Inc,		Registrant Contact: Philip Hoyer, ActivIdentity Inc,
	<philip.hoyer@actividentity.com>		<philip.hoyer@actividentity.com>
	9.5. XML Data Tag Identifier Registry		9. Security Considerations
	This specification requests the creation of a new IANA registry for
	XML Data Tag identifiers in accordance with the principles set out in
	RFC 2434 [RFC2434]as follows:
	[More explanation of why an escape to tag value lists is desirable
	when inserting unstructured data into an XML schema]
	9.5.1. Applicability
	As part of this registry the IANA will maintain the following
	information:
	Common Name Common name for by which the tag is referred to
	Cannonical URI The cannonical URI to be employed when citing the
	tag.
	Data Type The data type of the data that is bound to the tag.
	Definition A reference to the document in which the data tag
	defined by the identifier is defined.
	In the case where the registrant does not request a particular URI,
	the IANA will assign it a Uniform Resource Name (URN) that follows
	RFC 3553 [RFC3553].
	9.5.2. Registerable Data Tags
	9.5.2.1. Assigned URIs
	If the registrant wishes to have a URI assigned, then a URN of the
	form
	urn:ietf:params:xml:datatag:<tag>
	will be assigned where <tag> is a unique id specified by the party
	making the request and will normally be either the common name of the
	tag or an abbreviation thereof.
	NOTE: in order for a URN of this type to be assigned, the item being
	registered MUST have been through the IETF consensus process.
	Basically, this means that it must be documented in a RFC.
	NOTE: Expert Review is sufficient in cases where the request does not
	require a URN assignment inthe IETF namespace. IETF consensus is not
	required.
	9.5.3. Registration Procedures
	9.5.3.1. Review
	Data tag registrations are to be subject to Expert Review as per RFC
	2434 [RFC2434].
	9.5.3.2. Data Tag Entry
	Until the IANA requests or implements an automated process for the
	registration of these elements, any specifications must make that
	request part of the IANA considerations section of their respective
	documents. That request must be in the form of the following
	template:
	Common Name Common name for by which the tag is referred to
	Cannonical URI The cannonical URI to be employed when citing the
	tag.
	Data Type The data type of the data that is bound to the tag.
	Definition A reference to the document in which the data tag
	defined by the identifier is defined.
	9.5.4. Initial Values
	The following initial values are defined. Note that these values are
	limited to identifiers that are required by KEYPROV but not specified
	elsewhere:
	9.5.4.1. Secret
	Common Name Secret
	Cannonical URI urn:ietf:params:xml:datatag:secret
	Data Type binary, base64 encoded
	Defined in (this document)
	9.5.4.2. Counter
	Common Name Counter
	Cannonical URI urn:ietf:params:xml:datatag:counter
	Data Type 8 bytes unsigned integer in big endian (i.e. network byte
	order) form base64 encoded
	Defined in (this document)
	9.5.4.3. Time
	Common Name Time
	Cannonical URI urn:ietf:params:xml:datatag:time
	Data Type 8 bytes unsigned integer in big endian (i.e. network byte
	order) form base64 encoded (Number of seconds since 1970)
	Defined in (this document)
	9.5.4.4. Time Interval
	Common Name Time Interval
	Cannonical URI urn:ietf:params:xml:datatag:time_interval
	Data Type 8 bytes unsigned integer in big endian (i.e. network byte
	order) form base64 encoded.
	Defined in (this document)
	9.5.4.5. Time Drift
	Common Name urn:ietf:params:xml:datatag:time_drift
	Cannonical URI Time Drift
	Data Type 2 bytes unsigned integer in big endian (i.e. network byte
	order) form base64 encoded.
	Defined in (this document)
	10. 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.
	10.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 54, line 14 ¶		skipping to change at page 58, line 14 ¶
	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.
	10.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.
	10.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.
	11. 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, Shuh Chang, Jon Martinson, Siddhart		specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
	Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes		Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
	Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders		Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders
	Rundgren.		Rundgren, Sean Turner and especially Robert Philpott.
	12. 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.		schema in section 7.
	12.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 Version="1.0"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
	<Device>		<Device>
	<DeviceId>		<DeviceInfo>
	<Manufacturer>ACME</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>0755225266</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceId>		</DeviceInfo>
	<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="987654321">
	<Issuer>AnIssuer</Issuer>		<Issuer>Issuer</Issuer>
	<Usage OTP="true">		<Usage OTP="true">
	<ResponseFormat Length="6" Format="DECIMAL"/>		<ResponseFormat Length="8"
			Format="DECIMAL"/>
	</Usage>		</Usage>
	<Data Name="COUNTER">		<Data>
	<PlainValue>AprkuA==</PlainValue>		<Secret>
	</Data>		<PlainValue>
	<Data Name="SECRET">		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>		</PlainValue>
			</Secret>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
	</Data>		</Data>
	<ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
	</Key>		</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	12.2. Symmetric Key Container with a single PIN protected Non-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 Version="1.0"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
	<Device>		<Device>
	<DeviceId>		<DeviceInfo>
	<Manufacturer>ACME</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>0755225266</SerialNo>		<SerialNo>0755225266</SerialNo>
	</DeviceId>		</DeviceInfo>
	<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="0755225266">
	<Issuer>AnIssuer</Issuer>		<Issuer>AnIssuer</Issuer>
	<Usage OTP="true">		<Usage OTP="true">
	<ResponseFormat Length="6" Format="DECIMAL"/>		<ResponseFormat Length="6" Format="DECIMAL"/>
	</Usage>		</Usage>
	<Data Name="COUNTER">		<Data>
	<PlainValue>AprkuA==</PlainValue>		<Secret>
	</Data>		<PlainValue>
	<Data Name="SECRET">		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>		</PlainValue>
			</Secret>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
	</Data>		</Data>
	<PINPolicy PINKeyId="07552252661">		<PINPolicy PINKeyId="07552252661">
	<PINUsageMode>		<PINUsageMode>
	<Local/>		<Local/>
	</PINUsageMode>		</PINUsageMode>
	</PINPolicy>		</PINPolicy>
	</Key>		</Key>
	<Key KeyId="07552252661"		<Key KeyId="07552252661"
	KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">		KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
	<Usage>		<Usage>
	<ResponseFormat Length="4" Format="DECIMAL"/>		<ResponseFormat Length="4" Format="DECIMAL"/>
	</Usage>		</Usage>
	<Data Name="SECRET">		<Data>
	<PlainValue>MTIzNA==</PlainValue>		<Secret>
			<PlainValue>
			MTIzNA==
			</PlainValue>
			</Secret>
	</Data>		</Data>
	</Key>		</Key>
	</Device>		</Device>
	</KeyContainer>		</KeyContainer>
	12.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP		11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
	Secret Key		Secret Key and non-encrypted counter value
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0"		<KeyContainer Version="1.0"
	xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc: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#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<EncryptionKey>		<EncryptionKey>
	<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>		<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
	</EncryptionKey>		</EncryptionKey>
	<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1		<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
	</MACAlgorithm>		</MACAlgorithm>
	<Device>		<Device>
	<DeviceId>		<DeviceInfo>
	<Manufacturer>ACME</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>0755225266</SerialNo>		<SerialNo>0755225266</SerialNo>
	</DeviceId>		</DeviceInfo>
	<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="0755225266">
	<Issuer>AnIssuer</Issuer>		<Issuer>AnIssuer</Issuer>
	<Usage OTP="true">		<Usage OTP="true">
	<ResponseFormat Length="8" Format="DECIMAL"/>		<ResponseFormat Length="8" Format="DECIMAL"/>
	</Usage>		</Usage>
	<Data Name="COUNTER">		<Data>
	<PlainValue>AprkuA==</PlainValue>		<Secret>
	</Data>		<EncryptedValue>
	<Data Name="SECRET">		<xenc:EncryptionMethod
	<EncryptedValue>		Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
	<xenc:EncryptionMethod		<xenc:CipherData>
	Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>		<xenc:CipherValue>
	<xenc:CipherData>		gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
	<xenc:CipherValue>		</xenc:CipherValue>
	kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=		</xenc:CipherData>
	</xenc:CipherValue>		</EncryptedValue>
	</xenc:CipherData>		<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
	</EncryptedValue>		</Secret>
	<ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>		<Counter>
	</Data>		<PlainValue>0</PlainValue>
	</Key>		</Counter>
	</Device>		</Data>
	</KeyContainer>		</Key>
			</Device>
			</KeyContainer>
	12.4. Symmetric Key Container with signature and a single Password-		11.4. Symmetric Key Container with signature and a single Password-
	based Encrypted HOTP Secret Key		based Encrypted HOTP Secret Key
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<pskc:KeyContainer		<pskc:KeyContainer
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
	xmlns:pkcs-5=		xmlns:pkcs-5=
	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"		"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	Version="1.0">		Version="1.0">
	<pskc:EncryptionKey>		<pskc:EncryptionKey>
	<pskc:DerivedKey Id="#Passphrase1">		<pskc:DerivedKey Id="#Passphrase1">
	<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>		<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
	<pskc:KeyDerivationMethod		<pskc:KeyDerivationMethod
	skipping to change at page 59, line 30 ¶		skipping to change at page 64, line 32 ¶
	<KeyLength>16</KeyLength>		<KeyLength>16</KeyLength>
	<PRF/>		<PRF/>
	</pkcs-5:Parameters>		</pkcs-5:Parameters>
	</pskc:KeyDerivationMethod>		</pskc:KeyDerivationMethod>
	<xenc:ReferenceList>		<xenc:ReferenceList>
	<xenc:DataReference URI="#ED"/>		<xenc:DataReference URI="#ED"/>
	</xenc:ReferenceList>		</xenc:ReferenceList>
	</pskc:DerivedKey>		</pskc:DerivedKey>
	</pskc:EncryptionKey>		</pskc:EncryptionKey>
	<pskc:Device>		<pskc:Device>
	<pskc:DeviceId>		<pskc:DeviceInfo>
	<pskc:Manufacturer>ACME</pskc:Manufacturer>		<pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
	<pskc:SerialNo>0755225266</pskc:SerialNo>		<pskc:SerialNo>0755225266</pskc:SerialNo>
	</pskc:DeviceId>		</pskc:DeviceInfo>
	<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="0755225266">
	<pskc:Issuer>AnIssuer</pskc:Issuer>		<pskc:Issuer>AnIssuer</pskc:Issuer>
	<pskc:Usage OTP="true">		<pskc:Usage OTP="true">
	<pskc:ResponseFormat Length="6" Format="DECIMAL"/>		<pskc:ResponseFormat Length="6" Format="DECIMAL"/>
	</pskc:Usage>		</pskc:Usage>
	<pskc:Data Name="COUNTER">		<pskc:Data>
	<pskc:PlainValue>AprkuA==</pskc:PlainValue>		<pskc:Secret>
	</pskc:Data>		<pskc:EncryptedValue Id="ED">
	<pskc:Data Name="SECRET">		<xenc:EncryptionMethod Algorithm=
	<pskc:EncryptedValue Id="ED">		"http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
	<xenc:EncryptionMethod Algorithm=		<xenc:CipherData>
	"http://www.w3.org/2001/04/xmlenc#kw-aes128"/>		<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
	<xenc:CipherData>		</xenc:CipherValue>
	<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=		</xenc:CipherData>
	</xenc:CipherValue>		</pskc:EncryptedValue>
	</xenc:CipherData>
	</pskc:EncryptedValue>
			</pskc:Secret>
			<pskc:Counter>
			<pskc:PlainValue>0</pskc:PlainValue>
			</pskc:Counter>
	</pskc:Data>		</pskc:Data>
	</pskc:Key>		</pskc:Key>
	</pskc:Device>		</pskc:Device>
	<pskc:Signature>		<pskc:Signature>
	<ds:SignedInfo>		<ds:SignedInfo>
	<ds:CanonicalizationMethod		<ds:CanonicalizationMethod
	Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>		Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
	<ds:SignatureMethod		<ds:SignatureMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>		Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
	<ds:Reference URI="">		<ds:Reference URI="">
	skipping to change at page 60, line 33 ¶		skipping to change at page 65, line 37 ¶
	<ds:X509IssuerSerial>		<ds:X509IssuerSerial>
	<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US		<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US
	</ds:X509IssuerName>		</ds:X509IssuerName>
	<ds:X509SerialNumber>12345678</ds:X509SerialNumber>		<ds:X509SerialNumber>12345678</ds:X509SerialNumber>
	</ds:X509IssuerSerial>		</ds:X509IssuerSerial>
	</ds:X509Data>		</ds:X509Data>
	</ds:KeyInfo>		</ds:KeyInfo>
	</pskc:Signature>		</pskc:Signature>
	</pskc:KeyContainer>		</pskc:KeyContainer>
	12.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP		11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
	Secret Key		Secret Key
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<pskc:KeyContainer Version="1.0"		<pskc:KeyContainer Version="1.0"
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc: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#">		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
	<pskc:EncryptionKey>		<pskc:EncryptionKey>
	<ds:X509Data>		<ds:X509Data>
	<ds:X509Certificate>miib</ds:X509Certificate>		<ds:X509Certificate>miib</ds:X509Certificate>
	</ds:X509Data>		</ds:X509Data>
	</pskc:EncryptionKey>		</pskc:EncryptionKey>
	<pskc:Device>		<pskc:Device>
	<pskc:DeviceId>		<pskc:DeviceInfo>
	<pskc:Manufacturer>ACME</pskc:Manufacturer>		<pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
	<pskc:SerialNo>0755225266</pskc:SerialNo>		<pskc:SerialNo>0755225266</pskc:SerialNo>
	</pskc:DeviceId>		</pskc:DeviceInfo>
	<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"		<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	KeyId="0755225266">		KeyId="0755225266">
	<pskc:Issuer>AnIssuer</pskc:Issuer>		<pskc:Issuer>AnIssuer</pskc:Issuer>
	<pskc:Usage OTP="true">		<pskc:Usage OTP="true">
	<pskc:ResponseFormat Length="8" Format="DECIMAL"/>		<pskc:ResponseFormat Length="8" Format="DECIMAL"/>
	</pskc:Usage>		</pskc:Usage>
	<pskc:Data Name="COUNTER">		<pskc:Data>
	<pskc:PlainValue>AprkuA==</pskc:PlainValue>		<pskc:Secret>
	</pskc:Data>		<pskc:EncryptedValue Id="ED">
	<pskc:Data Name="SECRET">		<xenc:EncryptionMethod Algorithm=
	<pskc:EncryptedValue Id="ED">		"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
	<xenc:EncryptionMethod		<xenc:CipherData>
	Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
	<xenc:CipherData>		</xenc:CipherValue>
	<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=		</xenc:CipherData>
	</xenc:CipherValue>		</pskc:EncryptedValue>
	</xenc:CipherData>		</pskc:Secret>
	</pskc:EncryptedValue>		<pskc:Counter>
	</pskc:Data>		<pskc:PlainValue>0</pskc:PlainValue>
	</pskc:Key>		</pskc:Counter>
	</pskc:Device>		</pskc:Data>
	</pskc:KeyContainer>		</pskc:Key>
	13. References		</pskc:Device>
			</pskc:KeyContainer>
	13.1. Normative References		11.6. Symmetric Key Container with a single AES-256-CBC Encrypted OCRA
			Secret Key and non-encrypted counter value
			<?xml version="1.0" encoding="UTF-8"?>
			<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:pskc: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>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654321</SerialNo>
			</DeviceInfo>
			<Key KeyId="12345678"
			KeyAlgorithm="http://www.ietf.org/keyprov/
			pskc#OCRA-1:HOTP-SHA512-8:C-QN08">
			<Issuer>Issuer</Issuer>
			<Usage CR="true">
			<ChallengeFormat Min="8"
			Max="8" Format="DECIMAL"/>
			<ResponseFormat
			Length="8" Format="DECIMAL"/>
			</Usage>
			<Data>
			<Secret>
			<EncryptedValue>
			<xenc:EncryptionMethod
			Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
			<xenc:CipherData>
			<xenc:CipherValue>
			gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
			</xenc:CipherValue>
			</xenc:CipherData>
			</EncryptedValue>
			<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
			</Secret>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
			</Data>
			</Key>
			</Device>
			</KeyContainer>
			11.7. Symmetric Key Container with a single AES-256-CBC Encrypted TOTP
			Secret Key and non-encrypted time values
			<?xml version="1.0" encoding="UTF-8"?>
			<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:pskc: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>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>0755225266</SerialNo>
			</DeviceInfo>
			<Key KeyAlgorithm=
			"http://www.ietf.org/keyprov/pskc#totp"
			KeyId="0755225266">
			<Issuer>AnIssuer</Issuer>
			<Usage OTP="true">
			<ResponseFormat Length="6" Format="DECIMAL"/>
			</Usage>
			<Data>
			<Secret>
			<EncryptedValue>
			<xenc:EncryptionMethod
			Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
			<xenc:CipherData>
			<xenc:CipherValue>
			gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
			</xenc:CipherValue>
			</xenc:CipherData>
			</EncryptedValue>
			<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
			</Secret>
			<Time>
			<PlainValue>0</PlainValue>
			</Time>
			<TimeInterval>
			<PlainValue>30</PlainValue>
			</TimeInterval>
			</Data>
			</Key>
			</Device>
			</KeyContainer>
			11.8. Symmetric Key Container with two devices containing a Non-
			Encrypted HOTP Secret Key each sharing common KeyProperties
			<?xml version="1.0" encoding="UTF-8"?>
			<KeyContainer Version="1.0"
			xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
			<KeyProperties ID="KPID1"
			KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp">
			<Issuer>Issuer</Issuer>
			<Usage OTP="true">
			<ResponseFormat Length="8"
			Format="DECIMAL"/>
			</Usage>
			<Data>
			<Counter>
			<PlainValue>0</PlainValue>
			</Counter>
			</Data>
			</KeyProperties>
			<Device>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654321</SerialNo>
			</DeviceInfo>
			<Key KeyProperties="KPID1"
			KeyId="987654321">
			<Data>
			<Secret>
			<PlainValue>
			MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
			</PlainValue>
			</Secret>
			</Data>
			</Key>
			</Device>
			<Device>
			<DeviceInfo>
			<Manufacturer>Manufacturer</Manufacturer>
			<SerialNo>987654322</SerialNo>
			</DeviceInfo>
			<Key KeyProperties="KPID1"
			KeyId="987654322">
			<Data>
			<Secret>
			<PlainValue>
			MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
			</PlainValue>
			</Secret>
			</Data>
			</Key>
			</Device>
			</KeyContainer>
			12. References
			12.1. Normative References
	[PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography		[PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
	Specifications Version 2.0.",		Specifications Version 2.0.",
	URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,		URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
	October 1998.		October 1998.
	[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography		[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
	Standard", Version 2.0,		Standard", Version 2.0,
	URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.		URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.
	skipping to change at page 62, line 47 ¶		skipping to change at page 71, line 48 ¶
	(LDAP): String Representation of Distinguished Names",		(LDAP): String Representation of Distinguished Names",
	RFC 4514, June 2006.		RFC 4514, June 2006.
	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,		URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
	W3C Recommendation, February 2002.		W3C Recommendation, February 2002.
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/, December 2002.		URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
	13.2. Informative References		12.2. Informative References
	[CAP] MasterCard International, "Chip Authentication Program		[CAP] MasterCard International, "Chip Authentication Program
	Functional Architecture", September 2004.		Functional Architecture", September 2004.
	[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,		[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
	"Dynamic Symmetric Key Provisioning Protocol", Internet		"Dynamic Symmetric Key Provisioning Protocol", Internet
	Draft Informational, URL: http://www.ietf.org/		Draft Informational, URL: http://www.ietf.org/
	internet-drafts/draft-ietf-keyprov-dskpp-03.txt,		internet-drafts/draft-ietf-keyprov-dskpp-03.txt,
	February 2008.		February 2008.
	skipping to change at page 64, line 9 ¶		skipping to change at page 73, line 9 ¶
	[Schneier]		[Schneier]
	Schneier, B., "Secrets and Lies: Digitial Security in a		Schneier, B., "Secrets and Lies: Digitial Security in a
	Networked World", Wiley Computer Publishing, ISBN 0-8493-		Networked World", Wiley Computer Publishing, ISBN 0-8493-
	8253-7, 2000.		8253-7, 2000.
	Authors' Addresses		Authors' Addresses
	Philip Hoyer		Philip Hoyer
	ActivIdentity, Inc.		ActivIdentity, Inc.
	109 Borough High Street		117 Waterloo Road
	London, SE1 1NL		London, SE1 8UL
	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
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		USA
End of changes. 230 change blocks.
	788 lines changed or deleted		1173 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/