< draft-ietf-keyprov-pskc-06.txt		draft-ietf-keyprov-pskc-07.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: November 15, 2010 VeriSign		Expires: December 30, 2010 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	May 14, 2010		June 28, 2010
	Portable Symmetric Key Container (PSKC)		Portable Symmetric Key Container (PSKC)
	draft-ietf-keyprov-pskc-06		draft-ietf-keyprov-pskc-07
	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 to different types of crypto modules.		provisioning of symmetric keys to different types of crypto modules.
	For example, One Time Password (OTP) shared secrets or symmetric		For example, One Time Password (OTP) shared secrets or symmetric
	cryptographic keys to strong authentication devices. A standard key		cryptographic keys to strong authentication devices. A standard key
	transport format enables enterprises to deploy best-of-breed		transport format enables enterprises to deploy best-of-breed
	solutions combining components from different vendors into the same		solutions combining components from different vendors into the same
	infrastructure.		infrastructure.
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 November 15, 2010.		This Internet-Draft will expire on December 30, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Version Support . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4		1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 5
	1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4		1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 5
	1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5		1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Portable Key Container Entities Overview and Relationships . . 7		3. Portable Key Container Entities Overview and Relationships . . 8
	4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 9		4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 10
	4.1. <Key>: Embedding Keying Material and Key Related		4.1. <Key>: Embedding Keying Material and Key Related
	Information . . . . . . . . . . . . . . . . . . . . . . . 9		Information . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Transmission of supplementary Information . . . . . . . . 11		4.2. Key Value Encoding . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12		4.2.1. AES Key Value Encoding . . . . . . . . . . . . . . . . 13
	4.2.2. <CryptoModuleInfo> Element: CryptoModule		4.2.2. Triple DES Key Value Encoding . . . . . . . . . . . . 13
	Identification . . . . . . . . . . . . . . . . . . . . 13		4.3. Transmission of supplementary Information . . . . . . . . 14
	4.2.3. <UserId> Element: User Identification . . . . . . . . 14		4.3.1. <DeviceInfo> Element: Unique Device Identification . . 15
	4.2.4. <AlgorithmParameters> Element: Supplementary		4.3.2. <CryptoModuleInfo> Element: CryptoModule
	Information for OTP and CR Algorithms . . . . . . . . 14		Identification . . . . . . . . . . . . . . . . . . . . 16
	4.3. Transmission of Key Derivation Values . . . . . . . . . . 16		4.3.3. <UserId> Element: User Identification . . . . . . . . 17
	5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.3.4. <AlgorithmParameters> Element: Supplementary
	6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 23		Information for OTP and CR Algorithms . . . . . . . . 17
	6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23		4.4. Transmission of Key Derivation Values . . . . . . . . . . 19
	6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25		5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26		5.1. PIN Algorithm definition . . . . . . . . . . . . . . . . . 25
	6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29		6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 26
			6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 26
			6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 28
			6.2. Encryption based on Passphrase-based Keys . . . . . . . . 29
			6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 32
	6.4. Padding of Encrypted Values for Non-Padded Encryption		6.4. Padding of Encrypted Values for Non-Padded Encryption
	Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30		Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 33
	7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31		7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 34
	8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33		8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 36
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 39
	10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37		10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 40
	10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37		10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37		10.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
			11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46		12.1. Content-type registration for 'application/pskc+xml' . . . 49
	12.1. Content-type registration for 'application/pskc+xml' . . . 46		12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 50
	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47		12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 50
	12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47		12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 51
	12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48		12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 52
	12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49		12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 52
	12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49		13. Security Considerations . . . . . . . . . . . . . . . . . . . 54
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 51		13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 54
	13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 51		13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 55
	13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 52		13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 55
	13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 52		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 56
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55		16.1. Normative References . . . . . . . . . . . . . . . . . . . 58
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 55		16.2. Informative References . . . . . . . . . . . . . . . . . . 59
	16.2. Informative References . . . . . . . . . . . . . . . . . . 56		Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 61
	Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 58		A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 61
	A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 58
	A.1.1. Transport of keys from Server to Cryptographic		A.1.1. Transport of keys from Server to Cryptographic
	Module . . . . . . . . . . . . . . . . . . . . . . . . 58		Module . . . . . . . . . . . . . . . . . . . . . . . . 61
	A.1.2. Transport of keys from Cryptographic Module to		A.1.2. Transport of keys from Cryptographic Module to
	Cryptographic Module . . . . . . . . . . . . . . . . . 58		Cryptographic Module . . . . . . . . . . . . . . . . . 61
	A.1.3. Transport of keys from Cryptographic Module to		A.1.3. Transport of keys from Cryptographic Module to
	Server . . . . . . . . . . . . . . . . . . . . . . . . 59		Server . . . . . . . . . . . . . . . . . . . . . . . . 62
	A.1.4. Server to server Bulk import/export of keys . . . . . 59		A.1.4. Server to server Bulk import/export of keys . . . . . 62
	A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 59		A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 62
	A.2.1. Server to server Bulk import/export of keys . . . . . 59		A.2.1. Server to server Bulk import/export of keys . . . . . 62
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 61		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
	1. Introduction		1. Introduction
	With increasing use of symmetric key based systems, such as		With increasing use of symmetric key based systems, such as
	encryption of data at rest, or systems used for strong		encryption of data at rest, or systems used for strong
	authentication, such as those based on one-time-password (OTP) and		authentication, such as those based on one-time-password (OTP) and
	challenge response (CR) mechanisms, there is a need for vendor		challenge response (CR) mechanisms, there is a need for vendor
	interoperability and a standard format for importing and exporting		interoperability and a standard format for importing and exporting
	(provisioning) symmetric keys. For instance, traditionally, vendors		(provisioning) symmetric keys. For instance, traditionally, vendors
	of authentication servers and service providers have used proprietary		of authentication servers and service providers have used proprietary
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	requests the creation of an IANA registry for algorithm profiles		requests the creation of an IANA registry for algorithm profiles
	where algorithms, their meta-data and PSKC transmission profile can		where algorithms, their meta-data and PSKC transmission profile can
	be recorded for centralised standardised reference.		be recorded for centralised standardised reference.
	1.1. Key Words		1.1. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Versions		1.2. Version Support
	There is a provision made in the syntax for an explicit version		There is a provision made in the syntax for an explicit version
	number. Only version "1.0" is currently specified.		number. Only version "1.0" is currently specified.
			The numbering scheme for PSKC versions is "<major>.<minor>". The
			major and minor numbers MUST be treated as separate integers and each
			number MAY be incremented higher than a single digit. Thus, "PSKC
			2.4" would be a lower version than "PSKC 2.13", which in turn would
			be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be
			ignored by recipients and MUST NOT be sent.
			The major version number should be incremented only if the message
			format (E.g. Element structure) has changed so dramatically that an
			older version implementation would not be able to interoperate with a
			newer version. The minor version number indicates new capabilities,
			and MUST be ignored by an entity with a smaller minor version number,
			but used for informational purposes by the entity with the larger
			minor version number.
	1.3. Namespace Identifiers		1.3. Namespace Identifiers
	This document uses Uniform Resource Identifiers [RFC3986] to identify		This document uses Uniform Resource Identifiers [RFC3986] to identify
	resources, algorithms, and semantics.		resources, algorithms, and semantics.
	1.3.1. Defined Identifiers		1.3.1. Defined Identifiers
	The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:		The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
	"urn:ietf:params:xml:ns:keyprov:pskc"		"urn:ietf:params:xml:ns:keyprov:pskc"
	skipping to change at page 9, line 21 ¶		skipping to change at page 10, line 21 ¶
	The following example shows such a simple PSKC document. We will use		The following example shows such a simple PSKC document. We will use
	it to describe the structure of the <KeyContainer> element and its		it to describe the structure of the <KeyContainer> element and its
	child elements.		child elements.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0"		<KeyContainer Version="1.0"
	Id="exampleID1"		Id="exampleID1"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<KeyPackage>		<KeyPackage>
	<Key Id="12345678"		<Key Id="12345678"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer-A</Issuer>		<Issuer>Issuer-A</Issuer>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNA==		<PlainValue>MTIzNA==
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	</Data>		</Data>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	skipping to change at page 10, line 5 ¶		skipping to change at page 11, line 5 ¶
	'Id:' The 'Id' attribute carries a unique identifier for the		'Id:' The 'Id' attribute carries a unique identifier for the
	container. As such, it helps to identify a specific key container		container. As such, it helps to identify a specific key container
	in cases when multiple containers are embedded in larger xml		in cases when multiple containers are embedded in larger xml
	documents.		documents.
	4.1. <Key>: Embedding Keying Material and Key Related Information		4.1. <Key>: Embedding Keying Material and Key Related Information
	The following attributes of the <Key> element MUST be included at a		The following attributes of the <Key> element MUST be included at a
	minimum:		minimum:
	'Id': This attribute carries a globally unique identifier for the		'Id': This attribute carries a unique identifier for the symmetric
	symmetric key. The identifier is defined as a string of		key in the context of key provisioning exchanges between two
	alphanumeric characters.		parties. This means that if PSKC is used in multiple interactions
			between a sending and receiving party, using different containers
			referencing the same keys, the KeyId MUST use the same KeyId
			values (e.g. after initial provisioning, if a system wants to
			update key meta data values in the other system the KeyId value of
			the key where the meta data is to be updates MUST be the same of
			the original KeyId value provisioned). The identifier is defined
			as a string of alphanumeric characters.
	'Algorithm': This attribute contains a unique identifier for the		'Algorithm': This attribute contains a unique identifier for the
	PSKC algorithm profile. This profile associates specific		PSKC algorithm profile. This profile associates specific
	semantics to the elements and attributes contained in the <Key>		semantics to the elements and attributes contained in the <Key>
	element. This document describes profiles for open standards		element. This document describes profiles for open standards
	algorithms in Section 10. Additional profiles are defined in the		algorithms in Section 10. Additional profiles are defined in the
	following information draft [PSKC-ALGORITHM-PROFILES].		following information draft [PSKC-ALGORITHM-PROFILES].
	The <Key> element has a number of optional child elements. An		The <Key> element has a number of optional child elements. An
	initial set is described below:		initial set is described below:
	<Issuer>: This element represents the name of the party that issued		<Issuer>: This element represents the name of the party that issued
	the key. For example, a bank "Foobar Bank Inc." issuing hardware		the key. For example, a bank "Foobar Bank Inc." issuing hardware
	tokens to their retail banking users may set this element to		tokens to their retail banking users may set this element to
	"Foobar Bank Inc.".		"Foobar Bank Inc.".
	<FriendlyName>: A human readable name for the secret key for easier		<FriendlyName>: A human readable name for the secret key for easier
	reference. This element serves informational purposes only.		reference. This element serves informational purposes only. This
			element is a language dependent string hence it SHOULD have an
			attribute xml:lang="xx" where xx is the language identifier as
			specified in [RFC4646]. If no xml:lang attribute is present
			implementations MUST assume the language to be English as defined
			by setting the attribute value to "en" (e.g. xml:lang="en").
	<AlgorithmParameters>: This element carries parameters that		<AlgorithmParameters>: This element carries parameters that
	influence the result of the algorithmic computation, for example		influence the result of the algorithmic computation, for example
	response truncation and format in OTP and CR algorithms. A more		response truncation and format in OTP and CR algorithms. A more
	detailed discussion of the element can be found in Section 4.2.4.		detailed discussion of the element can be found in Section 4.3.4.
	<Data>: This element carries data about and related to the key. The		<Data>: This element carries data about and related to the key. The
	following child elements are defined for the <Data> element:		following child elements are defined for the <Data> element:
	<Secret>: This element carries the value of the key itself in a		<Secret>: This element carries the value of the key itself in a
	binary representation.		binary representation, please see Section 4.2 for more details
			on Key Value Encoding.
	<Counter>: This element contains the event counter for event		<Counter>: This element contains the event counter for event
	based OTP algorithms.		based OTP algorithms.
	<Time>: This element contains the time for time based OTP		<Time>: This element contains the time for time based OTP
	algorithms. (If time interval is used, this element carries		algorithms. (If time interval is used, this element carries
	the number of time intervals passed from a specific start		the number of time intervals passed from a specific start
	point, normally algorithm dependent).		point, normally algorithm dependent).
	<TimeInterval>: This element carries the time interval value for		<TimeInterval>: This element carries the time interval value for
	skipping to change at page 11, line 32 ¶		skipping to change at page 12, line 44 ¶
	Encrypted: The <EncryptedValue> element carries encrypted value.		Encrypted: The <EncryptedValue> element carries encrypted value.
	ValueMAC: The <ValueMAC> element is populated with a MAC		ValueMAC: The <ValueMAC> element is populated with a MAC
	generated from the encrypted value in case the encryption		generated from the encrypted value in case the encryption
	algorithm does not support integrity checks. The example shown		algorithm does not support integrity checks. The example shown
	at Figure 2 illustrates the usage of the <Data> element with		at Figure 2 illustrates the usage of the <Data> element with
	two child elements, namely <Secret> and <Counter>. Both		two child elements, namely <Secret> and <Counter>. Both
	elements carry plaintext value within the <PlainValue> child		elements carry plaintext value within the <PlainValue> child
	element.		element.
	4.2. Transmission of supplementary Information		4.2. Key Value Encoding
			Two parties receiving the same key value OCTET STRING, resulting in
			decoding the xs:base64Binary, inside the <PlainValue> or
			<EncryptedValue> elements, must make use of the key in exactly the
			same way in order to interoperate. To ensure that, it is necessary
			to define a correspondence between the OCTET STRING and the notation
			in the standard algorithm description that defines how the key is
			used. The next sections establish that correspondence for the
			algorithms AES [FIPS197] and TDEA [SP800-67]. Unless otherwise
			specified for a specific algorithm the OCTET STRING encoding MUST
			follow the AES Key Value Encoding.
			4.2.1. AES Key Value Encoding
			[FIPS197] section 5.2, titled Key Expansion, uses the input key as an
			array of bytes indexed starting at 0. The first octet of OCTET
			STRING SHALL become the key byte in AES labeled index 0 in [FIPS197];
			the succeeding octets of OCTET STRING SHALL become key bytes in AES
			in increasing index order.
			Proper parsing and key load of the contents of OCTET STRING for AES
			SHALL be determined by using the following value for the <PlainValue>
			element (binaryBase64 encoded) to generate and match the key
			expansion test vectors in [FIPS197] Appendix A for AES
			Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
			...
			<PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue>
			...
			4.2.2. Triple DES Key Value Encoding
			A Triple-DES key consists of three keys for the cryptographic engine
			(Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8
			parity bits); the three keys are also collectively referred to as a
			key bundle [SP800-67]. A key bundle may employ either two or three
			independent keys. When only two independent keys are employed
			(called two-key Triple DES), then the same value is used for Key1 and
			Key3.
			Each key in a Triple-DES key bundle is expanded into a key schedule
			according to a procedure defined in [SP800-67] Appendix A. That
			procedure numbers the bits in the key from 1 to 64, with number 1
			being the left-most, or most significant bit (MSB). The first octet
			of OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1 being
			the MSB. The second octet of OCTET STRING SHALL be bits 9 through 16
			of Key1, and so forth, so that the trailing octet of OCTET STRING
			SHALL be bits 57 through 64 of Key3 (or Key2 for two-key Triple DES).
			Proper parsing and key load of the contents of OCTET STRING for
			Triple-DES SHALL be determined by using the following <PlainValue>
			element (binaryBase64 encoded) to generate and match the key
			expansion test vectors in [SP800-67] appendix B for the key bundle:
			Key1 = 0123456789ABCDEF
			Key2 = 23456789ABCDEF01
			Key3 = 456789ABCDEF0123
			...
			<PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue>
			...
			4.3. Transmission of supplementary Information
	A PSKC document can contain a number of additional information		A PSKC document can contain a number of additional information
	regarding device identification, cryptomodule identification, user		regarding device identification, cryptomodule identification, user
	identification and parameters for usage with OTP and CR algorithms.		identification and parameters for usage with OTP and CR algorithms.
	The following example, see Figure 3, is used as a reference for the		The following example, see Figure 3, is used as a reference for the
	subsequent sub-sections.		subsequent sub-sections.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0"		<KeyContainer Version="1.0"
	Id="exampleID1"		Id="exampleID1"
	skipping to change at page 12, line 19 ¶		skipping to change at page 15, line 19 ¶
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	<UserId>DC=example-bank,DC=net</UserId>		<UserId>DC=example-bank,DC=net</UserId>
	</DeviceInfo>		</DeviceInfo>
	<CryptoModuleInfo>		<CryptoModuleInfo>
	<Id>CM_ID_001</Id>		<Id>CM_ID_001</Id>
	</CryptoModuleInfo>		</CryptoModuleInfo>
	<Key Id="12345678"		<Key Id="12345678"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>		<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 3: PSKC Key Container Example with Supplementary Data		Figure 3: PSKC Key Container Example with Supplementary Data
	4.2.1. <DeviceInfo> Element: Unique Device Identification		4.3.1. <DeviceInfo> Element: Unique Device Identification
	The <DeviceInfo> element uniquely identifies the device the		The <DeviceInfo> element uniquely identifies the device the
	<KeyPackage> is provisioned to. Since devices can come in different		<KeyPackage> is provisioned to. Since devices can come in different
	form factors, such as hardware tokens, smart-cards, soft tokens in a		form factors, such as hardware tokens, smart-cards, soft tokens in a
	mobile phone or as a PC, this element allows different child element		mobile phone or as a PC, this element allows different child element
	combinations to be used. When combined, the values of the child		combinations to be used. When combined, the values of the child
	elements MUST uniquely identify the device. For example, for		elements MUST uniquely identify the device. For example, for
	hardware tokens the combination of <SerialNo> and <Manufacturer>		hardware tokens the combination of <SerialNo> and <Manufacturer>
	elements uniquely identifies a device but the <SerialNo> element		elements uniquely identifies a device but the <SerialNo> element
	alone is insufficient since two different token manufacturers might		alone is insufficient since two different token manufacturers might
	issue devices with the same serial number (similar to the Issuer		issue devices with the same serial number (similar to the Issuer
	Distinguished Name and serial number of a certificate).		Distinguished Name and serial number of a certificate).
	The <DeviceInfo> element has the following child elements:		The <DeviceInfo> element has the following child elements:
	<Manufacturer>: This element indicates the manufacturer of the		<Manufacturer>: This element indicates the manufacturer of the
	device. Values for Manufacturer SHOULD be taken from [OATHMAN]		device. Values for Manufacturer SHOULD be taken from either
			[OATHMAN] prefixes (i.e., the left column) or they SHOULD be taken
			from IANA Private Enterprise Number Registry [IANAPENREG], using
			the Organisation value.
	<SerialNo>: This element contains the serial number of the device.		<SerialNo>: This element contains the serial number of the device.
	<Model>: This element describes the model of the device (e.g., one-		<Model>: This element describes the model of the device (e.g., one-
	button-HOTP-token-V1).		button-HOTP-token-V1).
	<IssueNo>: This element contains the issue number in case devices		<IssueNo>: This element contains the issue number in case devices
	with the same serial number that are distinguished by different		with the same serial number that are distinguished by different
	issue numbers.		issue numbers.
	skipping to change at page 13, line 46 ¶		skipping to change at page 16, line 49 ¶
	MAY only happen on the validation server as some devices such as		MAY only happen on the validation server as some devices such as
	smart cards do not have an internal clock. Systems thus SHOULD		smart cards do not have an internal clock. Systems thus SHOULD
	NOT rely upon the device to enforce key usage date restrictions.		NOT rely upon the device to enforce key usage date restrictions.
	Depending on the device type certain child elements of the		Depending on the device type certain child elements of the
	<DeviceInfo> element MUST be included in order to uniquely identify a		<DeviceInfo> element MUST be included in order to uniquely identify a
	device. This document does not enumerate the different device types		device. This document does not enumerate the different device types
	and therefore does not list the elements that are mandatory for each		and therefore does not list the elements that are mandatory for each
	type of device.		type of device.
	4.2.2. <CryptoModuleInfo> Element: CryptoModule Identification		4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification
	The <CryptoModuleInfo> element identifies the cryptographic module to		The <CryptoModuleInfo> element identifies the cryptographic module to
	which the symmetric keys are or have been provisioned to. This		which the symmetric keys are or have been provisioned to. This
	allows the identification of the specific cases where a device MAY		allows the identification of the specific cases where a device MAY
	contain more than one crypto module (e.g. a PC hosting a TPM and a		contain more than one crypto module (e.g. a PC hosting a TPM and a
	connected token).		connected token).
	The <CryptoModuleInfo> element has a single child element that MUST		The <CryptoModuleInfo> element has a single child element that MUST
	be included:		be included:
	<Id>: This element carries a unique identifier for the CryptoModule		<Id>: This element carries a unique identifier for the CryptoModule
	and is implementation specific. As such, it helps to identify a		and is implementation specific. As such, it helps to identify a
	specific CryptoModule to which the key is being or was		specific CryptoModule to which the key is being or was
	proivisioned.		proivisioned.
	4.2.3. <UserId> Element: User Identification		4.3.3. <UserId> Element: User Identification
	The <UserId> element identifies the user using a distinguished name,		The <UserId> element identifies the user using a distinguished name,
	as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net.		as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net.
	Although the syntax of the user identifier is defined, there are no		Although the syntax of the user identifier is defined, there are no
	semantics associated with this element, i.e., there are no checks		semantics associated with this element, i.e., there are no checks
	enforcing that only a specific user can use this key. As such, this		enforcing that only a specific user can use this key. As such, this
	element is for informational purposes only.		element is for informational purposes only.
	This element may appear in two places, namely as a child element of		This element may appear in two places, namely as a child element of
	the <Key> element where it indicates the user with whom the key is		the <Key> element where it indicates the user with whom the key is
	associated with and as a child element of the <DeviceInfo> element		associated with and as a child element of the <DeviceInfo> element
	where it indicates the user the device is associated with.		where it indicates the user the device is associated with.
	4.2.4. <AlgorithmParameters> Element: Supplementary Information for OTP		4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP
	and CR Algorithms		and CR Algorithms
	The <AlgorithmParameters> element is a child element of the <Key>		The <AlgorithmParameters> element is a child element of the <Key>
	element and this document defines two child elements:		element and this document defines three child elements: <Suite>,
	<ChallengeFormat> and <ResponseFormat>		<ChallengeFormat> and <ResponseFormat>
			<Suite>:
			The optional <Suite> element defines additional characteristics of
			the algorithm used, which are algorithm specific. For example in
			HMAC based OTP algorithm it could designate the strength of the
			hash algorithm used (SHA1, SHA256, etc). Please refer to
			algorithm profile specification Section 10 for the exact semantic
			of the value for each algorithm profile.
	<ChallengeFormat>:		<ChallengeFormat>:
	The <ChallengeFormat> element defines the characteristics of the		The <ChallengeFormat> element defines the characteristics of the
	challenge in a CR usage scenario whereby the following attributes		challenge in a CR usage scenario whereby the following attributes
	are defined:		are defined:
	'Encoding': This attribute, which MUST be included, defines the		'Encoding': This attribute, which MUST be included, defines the
	encoding of the challenge accepted by the device and MUST be		encoding of the challenge accepted by the device and MUST be
	one of the following values:		one of the following values:
	skipping to change at page 16, line 15 ¶		skipping to change at page 19, line 26 ¶
	response.		response.
	'Length': This attribute defines the length of the response		'Length': This attribute defines the length of the response
	generated by the device and MUST be included. If the		generated by the device and MUST be included. If the
	'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or		'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
	'ALPHANUMERIC' this value indicates the number of digits/		'ALPHANUMERIC' this value indicates the number of digits/
	characters. If the 'Encoding' attribute is 'BASE64' or		characters. If the 'Encoding' attribute is 'BASE64' or
	'BINARY', this value indicates the number of bytes of the		'BINARY', this value indicates the number of bytes of the
	unencoded value.		unencoded value.
	4.3. Transmission of Key Derivation Values		4.4. Transmission of Key Derivation Values
	<KeyProfileId> element, which is a child element of the <Key>		<KeyProfileId> element, which is a child element of the <Key>
	element, carries a unique identifier used between the sending and		element, carries a unique identifier used between the sending and
	receiving parties to establish a set of key attribute values that are		receiving parties to establish a set of key attribute values that are
	not transmitted within the container but agreed between the two		not transmitted within the container but agreed between the two
	parties out of band. This element will then represent the unique		parties out of band. This element will then represent the unique
	reference to a set of key attribute values. (For example, a smart		reference to a set of key attribute values. (For example, a smart
	card application personalisation profile id related to specific		card application personalisation profile id related to specific
	attribute values present on a smart card application, that have		attribute values present on a smart card application, that have
	influence when computing a response.).		influence when computing a response.).
	skipping to change at page 17, line 17 ¶		skipping to change at page 20, line 20 ¶
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<CryptoModuleInfo>		<CryptoModuleInfo>
	<Id>CM_ID_001</Id>		<Id>CM_ID_001</Id>
	</CryptoModuleInfo>		</CryptoModuleInfo>
	<Key Id="12345678"		<Key Id="12345678"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<KeyProfileId>keyProfile1</KeyProfileId>		<KeyProfileId>keyProfile1</KeyProfileId>
	<KeyReference>MasterKeyLabel		<KeyReference>MasterKeyLabel
	</KeyReference>		</KeyReference>
	<Data>		<Data>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	skipping to change at page 18, line 34 ¶		skipping to change at page 21, line 34 ¶
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<CryptoModuleInfo>		<CryptoModuleInfo>
	<Id>CM_ID_001</Id>		<Id>CM_ID_001</Id>
	</CryptoModuleInfo>		</CryptoModuleInfo>
	<Key Id="12345678"		<Key Id="12345678"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	skipping to change at page 19, line 17 ¶		skipping to change at page 22, line 17 ¶
	</KeyPackage>		</KeyPackage>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<CryptoModuleInfo>		<CryptoModuleInfo>
	<Id>CM_ID_001</Id>		<Id>CM_ID_001</Id>
	</CryptoModuleInfo>		</CryptoModuleInfo>
	<Key Id="123456781"		<Key Id="123456781"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:pin">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="4" Encoding="DECIMAL"/>		<ResponseFormat Length="4" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>MTIzNA==</PlainValue>		<PlainValue>MTIzNA==</PlainValue>
	</Secret>		</Secret>
	</Data>		</Data>
	</Key>		</Key>
	skipping to change at page 23, line 5 ¶		skipping to change at page 25, line 14 ¶
	'PINEncoding': This attribute indicates the encoding of the PIN		'PINEncoding': This attribute indicates the encoding of the PIN
	and MUST be one of the values: DECIMAL, HEXADECIMAL,		and MUST be one of the values: DECIMAL, HEXADECIMAL,
	ALPHANUMERIC, BASE64, or BINARY.		ALPHANUMERIC, BASE64, or BINARY.
	If the 'PinUsageMode' attribute is set to "Local" then the device		If the 'PinUsageMode' attribute is set to "Local" then the device
	MUST enforce the restriction indicated in the 'MaxFailedAttempts',		MUST enforce the restriction indicated in the 'MaxFailedAttempts',
	'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it		'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it
	MUST be enforced on the server side.		MUST be enforced on the server side.
			5.1. PIN Algorithm definition
			The PIN algorithm is defined as:
			boolean = comparePIN(K,P)
			Where:
			'K': Is the stored symmetric credential (PIN) in binary format.
			'P': Is the proposed PIN to be compared in binary format.
			The function comparePIN is a straight octet comparison of K and P.
			Such comparison MUST yield TRUE (credentials matched) when the the
			octet length of K is the same as the octet length of P and all octets
			comprising K are the same as the octets comprising P.
	6. Key Protection Methods		6. Key Protection Methods
	With the functionality described in the previous sections,		With the functionality described in the previous sections,
	information related to keys had to be transmitted in clear text.		information related to keys had to be transmitted in clear text.
	With the help of the <EncryptionKey> element, which is a child		With the help of the <EncryptionKey> element, which is a child
	element of the <KeyContainer> element, it is possible to encrypt keys		element of the <KeyContainer> element, it is possible to encrypt keys
	and associated information. The level of encryption is applied to		and associated information. The level of encryption is applied to
	the value of individual elements and the applied encryption algorithm		the value of individual elements and the applied encryption algorithm
	MUST be the same for all encrypted elements. Keys are protected		MUST be the same for all encrypted elements. Keys are protected
	using the following methods: pre-shared keys, passphrase-based keys,		using the following methods: pre-shared keys, passphrase-based keys,
	skipping to change at page 24, line 23 ¶		skipping to change at page 27, line 23 ¶
	</MACMethod>		</MACMethod>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>Manufacturer</Manufacturer>		<Manufacturer>Manufacturer</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<CryptoModuleInfo>		<CryptoModuleInfo>
	<Id>CM_ID_001</Id>		<Id>CM_ID_001</Id>
	</CryptoModuleInfo>		</CryptoModuleInfo>
	<Key Id="12345678"		<Key Id="12345678"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<EncryptedValue>		<EncryptedValue>
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>		Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
	<xenc:CipherData>		<xenc:CipherData>
	skipping to change at page 28, line 23 ¶		skipping to change at page 31, line 23 ¶
	</pskc:MACMethod>		</pskc:MACMethod>
	<pskc:KeyPackage>		<pskc:KeyPackage>
	<pskc:DeviceInfo>		<pskc:DeviceInfo>
	<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>		<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
	<pskc:SerialNo>987654321</pskc:SerialNo>		<pskc:SerialNo>987654321</pskc:SerialNo>
	</pskc:DeviceInfo>		</pskc:DeviceInfo>
	<pskc:CryptoModuleInfo>		<pskc:CryptoModuleInfo>
	<pskc:Id>CM_ID_001</pskc:Id>		<pskc:Id>CM_ID_001</pskc:Id>
	</pskc:CryptoModuleInfo>		</pskc:CryptoModuleInfo>
	<pskc:Key Algorithm=		<pskc:Key Algorithm=
	"urn:ietf:params:xml:ns:keyprov:pskc#hotp" Id="123456">		"urn:ietf:params:xml:ns:keyprov:pskc:hotp" Id="123456">
	<pskc:Issuer>Example-Issuer</pskc:Issuer>		<pskc:Issuer>Example-Issuer</pskc:Issuer>
	<pskc:AlgorithmParameters>		<pskc:AlgorithmParameters>
	<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>		<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
	</pskc:AlgorithmParameters>		</pskc:AlgorithmParameters>
	<pskc:Data>		<pskc:Data>
	<pskc:Secret>		<pskc:Secret>
	<pskc:EncryptedValue Id="ED">		<pskc:EncryptedValue Id="ED">
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm=		Algorithm=
	"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>		"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
	skipping to change at page 29, line 44 ¶		skipping to change at page 32, line 44 ¶
	</ds:X509Certificate>		</ds:X509Certificate>
	</ds:X509Data>		</ds:X509Data>
	</EncryptionKey>		</EncryptionKey>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>987654321</SerialNo>		<SerialNo>987654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key		<Key
	Id="MBK000000001"		Id="MBK000000001"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Example-Issuer</Issuer>		<Issuer>Example-Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="6" Encoding="DECIMAL"/>		<ResponseFormat Length="6" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<EncryptedValue>		<EncryptedValue>
	<xenc:EncryptionMethod		<xenc:EncryptionMethod
	Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>		Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
	<xenc:CipherData>		<xenc:CipherData>
	skipping to change at page 31, line 23 ¶		skipping to change at page 34, line 23 ¶
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	Version="1.0">		Version="1.0">
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>0755225266</SerialNo>		<SerialNo>0755225266</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key Id="123"		<Key Id="123"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Example-Issuer</Issuer>		<Issuer>Example-Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="6" Encoding="DECIMAL"/>		<ResponseFormat Length="6" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	skipping to change at page 33, line 28 ¶		skipping to change at page 36, line 28 ¶
	<?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:pskc">		xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>654321</SerialNo>		<SerialNo>654321</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key Id="1"		<Key Id="1"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	skipping to change at page 34, line 7 ¶		skipping to change at page 37, line 7 ¶
	<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>123456</SerialNo>		<SerialNo>123456</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key Id="2"		<Key Id="2"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	skipping to change at page 34, line 34 ¶		skipping to change at page 37, line 34 ¶
	<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
	</Policy>		</Policy>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>9999999</SerialNo>		<SerialNo>9999999</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key Id="3"		<Key Id="3"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	skipping to change at page 35, line 14 ¶		skipping to change at page 38, line 14 ¶
	</Policy>		</Policy>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	<KeyPackage>		<KeyPackage>
	<DeviceInfo>		<DeviceInfo>
	<Manufacturer>TokenVendorAcme</Manufacturer>		<Manufacturer>TokenVendorAcme</Manufacturer>
	<SerialNo>9999999</SerialNo>		<SerialNo>9999999</SerialNo>
	</DeviceInfo>		</DeviceInfo>
	<Key Id="4"		<Key Id="4"
	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">		Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
	<Issuer>Issuer</Issuer>		<Issuer>Issuer</Issuer>
	<AlgorithmParameters>		<AlgorithmParameters>
	<ResponseFormat Length="8" Encoding="DECIMAL"/>		<ResponseFormat Length="8" Encoding="DECIMAL"/>
	</AlgorithmParameters>		</AlgorithmParameters>
	<Data>		<Data>
	<Secret>		<Secret>
	<PlainValue>		<PlainValue>
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	skipping to change at page 36, line 13 ¶		skipping to change at page 39, line 13 ¶
	Figure 10: Bulk Provisioning Example		Figure 10: Bulk Provisioning Example
	9. Extensibility		9. Extensibility
	This section lists a few common extension points provided by PSKC:		This section lists a few common extension points provided by PSKC:
	New PSKC Version: Whenever it is necessary to define a new version		New PSKC Version: Whenever it is necessary to define a new version
	of this document then a new version number has to be allocated to		of this document then a new version number has to be allocated to
	refer to the new specification version. The version number is		refer to the new specification version. The version number is
	carried inside the 'Version' attribute, as described in Section 4,		carried inside the 'Version' attribute, as described in Section 4,
	and rules for extensibililty are defined in Section 12.		the numbering scheme MUST follow Section 1.2, and rules for
			extensibililty are defined in Section 12.
	New XML Elements: The usage of the XML schema and the available		New XML Elements: The usage of the XML schema and the available
	extension points allows new XML elements to be added. Depending		extension points allows new XML elements to be added. Depending
	of type of XML elements different ways for extensibility are		of type of XML elements different ways for extensibility are
	offered. In some places the <Extensions> element can be used and		offered. In some places the <Extensions> element can be used and
	elsewhere the "<xs:any namespace="##other" processContents="lax"		elsewhere the "<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>" XML extension point is		minOccurs="0" maxOccurs="unbounded"/>" XML extension point is
	utilized.		utilized.
	New XML Attributes: The XML schema allows new XML attributes to be		New XML Attributes: The XML schema allows new XML attributes to be
	skipping to change at page 37, line 13 ¶		skipping to change at page 40, line 13 ¶
	described in Section 12.		described in Section 12.
	10. PSKC Algorithm Profile		10. PSKC Algorithm Profile
	10.1. HOTP		10.1. HOTP
	Common Name: HOTP		Common Name: HOTP
	Class: OTP		Class: OTP
	URI: urn:ietf:params:xml:ns:keyprov:pskc#hotp		URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
	Algorithm Definition: [HOTP]		Algorithm Definition: [HOTP]
	Identifier Definition: (this RFC)		Identifier Definition: (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
	Deprectaed: FALSE		Deprectaed: FALSE
	Profiling:		Profiling:
	skipping to change at page 37, line 48 ¶		skipping to change at page 40, line 48 ¶
	+ The <ResponseFormat> element MUST have the 'Format'		+ The <ResponseFormat> element MUST have the 'Format'
	attribute set to "DECIMAL", and the 'Length' attribute MUST		attribute set to "DECIMAL", and the 'Length' attribute MUST
	indicate a length value between 6 and 9 (inclusive).		indicate a length value between 6 and 9 (inclusive).
	+ The <PINPolicy> element MAY be present but the		+ The <PINPolicy> element MAY be present but the
	'PINUsageMode' attribute cannot be set to "Algorithmic".		'PINUsageMode' attribute cannot be set to "Algorithmic".
	An example can be found in Figure 3.		An example can be found in Figure 3.
	10.2. KEYPROV-PIN		10.2. PIN
	Common Name: KEYPROV-PIN		Common Name: PIN
	Class: Symmetric static credential comparison		Class: Symmetric static credential comparison
	URI: urn:ietf:params:xml:ns:keyprov:pskc#pin		URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
	Algorithm Definition: (this document)		Algorithm Definition: (this RFC) Section 5.1
	Identifier Definition (this document)		Identifier Definition (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
	Deprectaed: FALSE		Deprectaed: FALSE
	Profiling:		Profiling:
	The <Usage> element MAY be present but no attribute of the		The <Usage> element MAY be present but no attribute of the
	<Usage> element is required. The <ResponseFormat> element MAY		<Usage> element is required. The <ResponseFormat> element MAY
	be used to indicate the PIN value format.		be used to indicate the PIN value format.
	The <Secret> element (see Section 4.1) MUST be provided.		The <Secret> element (see Section 4.1) MUST be provided.
	See the example in Figure 5		See the example in Figure 5
	11. XML Schema		11. XML Schema
	This section defines the XML schema for PSKC.		This section defines the XML schema for PSKC.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema 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:pskc"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
	targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"		targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<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=		schemaLocation=
	"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>		"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>		<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
	<xs:complexType name="KeyContainerType">		<xs:complexType name="KeyContainerType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="EncryptionKey"		<xs:element name="EncryptionKey"
	type="ds:KeyInfoType" minOccurs="0"/>		type="ds:KeyInfoType" minOccurs="0"/>
	<xs:element name="MACMethod"		<xs:element name="MACMethod"
	type="pskc:MACMethodType" minOccurs="0"/>		type="pskc:MACMethodType" minOccurs="0"/>
	<xs:element name="KeyPackage"		<xs:element name="KeyPackage"
	type="pskc:KeyPackageType" maxOccurs="unbounded"/>		type="pskc:KeyPackageType" maxOccurs="unbounded"/>
	<xs:element name="Signature"		<xs:element name="Signature"
	type="ds:SignatureType" minOccurs="0"/>		type="ds:SignatureType" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType"		type="pskc:ExtensionsType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Version"		<xs:attribute name="Version"
	type="pskc:VersionType" use="required"/>		type="pskc:VersionType" use="required"/>
	<xs:attribute name="Id"		<xs:attribute name="Id"
	type="xs:ID" use="optional"/>		type="xs:ID" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="VersionType" final="restriction">		<xs:simpleType name="VersionType" final="restriction">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:pattern value="\d{1,2}\.\d{1,3}"/>		<xs:pattern value="\d{1,2}\.\d{1,3}"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="KeyType">		<xs:complexType name="KeyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Issuer"		<xs:element name="Issuer"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="AlgorithmParameters"		<xs:element name="AlgorithmParameters"
	type="pskc:AlgorithmParametersType"		type="pskc:AlgorithmParametersType"
	minOccurs="0"/>		minOccurs="0"/>
	<xs:element name="KeyProfileId"		<xs:element name="KeyProfileId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="KeyReference"		<xs:element name="KeyReference"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="FriendlyName"		<xs:element name="FriendlyName"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Data"		<xs:element name="Data"
	type="pskc:KeyDataType" minOccurs="0"/>		type="pskc:KeyDataType" minOccurs="0"/>
	<xs:element name="UserId"		<xs:element name="UserId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Policy"		<xs:element name="Policy"
	type="pskc:PolicyType" minOccurs="0"/>		type="pskc:PolicyType" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="Id"		<xs:attribute name="Id"
	type="xs:string" use="required"/>		type="xs:string" use="required"/>
	<xs:attribute name="Algorithm"		<xs:attribute name="Algorithm"
	type="pskc:KeyAlgorithmType" use="optional"/>		type="pskc:KeyAlgorithmType" use="optional"/>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="PolicyType">		<xs:complexType name="PolicyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="StartDate"		<xs:element name="StartDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="ExpiryDate"		<xs:element name="ExpiryDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="PINPolicy"		<xs:element name="PINPolicy"
	type="pskc:PINPolicyType" minOccurs="0"/>		type="pskc:PINPolicyType" minOccurs="0"/>
	<xs:element name="KeyUsage"		<xs:element name="KeyUsage"
	type="pskc:KeyUsageType"		type="pskc:KeyUsageType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:element name="NumberOfTransactions"		<xs:element name="NumberOfTransactions"
	type="xs:nonNegativeInteger" minOccurs="0"/>		type="xs:nonNegativeInteger" minOccurs="0"/>
	<xs:any namespace="##other"		<xs:any namespace="##other"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyDataType">		<xs:complexType name="KeyDataType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Secret"		<xs:element name="Secret"
	type="pskc:binaryDataType" minOccurs="0"/>		type="pskc:binaryDataType" minOccurs="0"/>
	<xs:element name="Counter"		<xs:element name="Counter"
	type="pskc:longDataType" minOccurs="0"/>		type="pskc:longDataType" minOccurs="0"/>
	<xs:element name="Time"		<xs:element name="Time"
	type="pskc:intDataType" minOccurs="0"/>		type="pskc:intDataType" minOccurs="0"/>
	<xs:element name="TimeInterval"		<xs:element name="TimeInterval"
	type="pskc:intDataType" minOccurs="0"/>		type="pskc:intDataType" minOccurs="0"/>
	<xs:element name="TimeDrift"		<xs:element name="TimeDrift"
	type="pskc:intDataType" minOccurs="0"/>		type="pskc:intDataType" minOccurs="0"/>
	<xs:any namespace="##other"		<xs:any namespace="##other"
	processContents="lax"		processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="binaryDataType">		<xs:complexType name="binaryDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue"		<xs:element name="PlainValue"
	type="xs:base64Binary"/>		type="xs:base64Binary"/>
	<xs:element name="EncryptedValue"		<xs:element name="EncryptedValue"
	type="xenc:EncryptedDataType"/>		type="xenc:EncryptedDataType"/>
	</xs:choice>		</xs:choice>
	<xs:element name="ValueMAC"		<xs:element name="ValueMAC"
	type="xs:base64Binary" minOccurs="0"/>		type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="intDataType">		<xs:complexType name="intDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue" type="xs:int"/>		<xs:element name="PlainValue" type="xs:int"/>
	<xs:element name="EncryptedValue"		<xs:element name="EncryptedValue"
	type="xenc:EncryptedDataType"/>		type="xenc:EncryptedDataType"/>
	</xs:choice>		</xs:choice>
	<xs:element name="ValueMAC"		<xs:element name="ValueMAC"
	type="xs:base64Binary" minOccurs="0"/>		type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="stringDataType">		<xs:complexType name="stringDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue" type="xs:string"/>		<xs:element name="PlainValue" type="xs:string"/>
	<xs:element name="EncryptedValue"		<xs:element name="EncryptedValue"
	type="xenc:EncryptedDataType"/>		type="xenc:EncryptedDataType"/>
	</xs:choice>		</xs:choice>
	<xs:element name="ValueMAC"		<xs:element name="ValueMAC"
	type="xs:base64Binary" minOccurs="0"/>		type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="longDataType">		<xs:complexType name="longDataType">
	<xs:sequence>		<xs:sequence>
	<xs:choice>		<xs:choice>
	<xs:element name="PlainValue" type="xs:long"/>		<xs:element name="PlainValue" type="xs:long"/>
	<xs:element name="EncryptedValue"		<xs:element name="EncryptedValue"
	type="xenc:EncryptedDataType"/>		type="xenc:EncryptedDataType"/>
	</xs:choice>		</xs:choice>
	<xs:element name="ValueMAC"		<xs:element name="ValueMAC"
	type="xs:base64Binary" minOccurs="0"/>		type="xs:base64Binary" minOccurs="0"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="PINPolicyType">		<xs:complexType name="PINPolicyType">
	<xs:attribute name="PINKeyId"		<xs:attribute name="PINKeyId"
	type="xs:string" use="optional"/>		type="xs:string" use="optional"/>
	<xs:attribute name="PINUsageMode"		<xs:attribute name="PINUsageMode"
	type="pskc:PINUsageModeType"/>		type="pskc:PINUsageModeType"/>
	<xs:attribute name="MaxFailedAttempts"		<xs:attribute name="MaxFailedAttempts"
	type="xs:unsignedInt" use="optional"/>		type="xs:unsignedInt" use="optional"/>
	<xs:attribute name="MinLength"		<xs:attribute name="MinLength"
	type="xs:unsignedInt" use="optional"/>		type="xs:unsignedInt" use="optional"/>
	<xs:attribute name="MaxLength"		<xs:attribute name="MaxLength"
	type="xs:unsignedInt" use="optional"/>		type="xs:unsignedInt" use="optional"/>
	<xs:attribute name="PINEncoding"		<xs:attribute name="PINEncoding"
	type="pskc:ValueFormatType" use="optional"/>		type="pskc:ValueFormatType" use="optional"/>
	<xs:anyAttribute namespace="##other"/>		<xs:anyAttribute namespace="##other"/>
	</xs:complexType>		</xs:complexType>
	<xs:simpleType name="PINUsageModeType">		<xs:simpleType name="PINUsageModeType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="Local"/>		<xs:enumeration value="Local"/>
	<xs:enumeration value="Prepend"/>		<xs:enumeration value="Prepend"/>
	<xs:enumeration value="Append"/>		<xs:enumeration value="Append"/>
	<xs:enumeration value="Algorithmic"/>		<xs:enumeration value="Algorithmic"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="KeyUsageType">		<xs:simpleType name="KeyUsageType">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:enumeration value="OTP"/>		<xs:enumeration value="OTP"/>
	<xs:enumeration value="CR"/>		<xs:enumeration value="CR"/>
	<xs:enumeration value="Encrypt"/>		<xs:enumeration value="Encrypt"/>
	<xs:enumeration value="Integrity"/>		<xs:enumeration value="Integrity"/>
	<xs:enumeration value="Verify"/>		<xs:enumeration value="Verify"/>
	<xs:enumeration value="Unlock"/>		<xs:enumeration value="Unlock"/>
	<xs:enumeration value="Decrypt"/>		<xs:enumeration value="Decrypt"/>
	<xs:enumeration value="KeyWrap"/>		<xs:enumeration value="KeyWrap"/>
	<xs:enumeration value="Unwrap"/>		<xs:enumeration value="Unwrap"/>
	<xs:enumeration value="Derive"/>		<xs:enumeration value="Derive"/>
	<xs:enumeration value="Generate"/>		<xs:enumeration value="Generate"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="DeviceInfoType">		<xs:complexType name="DeviceInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Manufacturer"		<xs:element name="Manufacturer"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="SerialNo"		<xs:element name="SerialNo"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Model"		<xs:element name="Model"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="IssueNo"		<xs:element name="IssueNo"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="DeviceBinding"		<xs:element name="DeviceBinding"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="StartDate"		<xs:element name="StartDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="ExpiryDate"		<xs:element name="ExpiryDate"
	type="xs:dateTime" minOccurs="0"/>		type="xs:dateTime" minOccurs="0"/>
	<xs:element name="UserId"		<xs:element name="UserId"
	type="xs:string" minOccurs="0"/>		type="xs:string" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="CryptoModuleInfoType">		<xs:complexType name="CryptoModuleInfoType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="Id" type="xs:string"/>		<xs:element name="Id" type="xs:string"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="KeyPackageType">		<xs:complexType name="KeyPackageType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="DeviceInfo"		<xs:element name="DeviceInfo"
	type="pskc:DeviceInfoType" minOccurs="0"/>		type="pskc:DeviceInfoType" minOccurs="0"/>
	<xs:element name="CryptoModuleInfo"		<xs:element name="CryptoModuleInfo"
	type="pskc:CryptoModuleInfoType" minOccurs="0"/>		type="pskc:CryptoModuleInfoType" minOccurs="0"/>
	<xs:element name="Key"		<xs:element name="Key"
	type="pskc:KeyType" minOccurs="0"/>		type="pskc:KeyType" minOccurs="0"/>
	<xs:element name="Extensions"		<xs:element name="Extensions"
	type="pskc:ExtensionsType" minOccurs="0"		type="pskc:ExtensionsType" minOccurs="0"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="AlgorithmParametersType">		<xs:complexType name="AlgorithmParametersType">
	<xs:choice>		<xs:choice>
	<xs:element name="ChallengeFormat" minOccurs="0">		<xs:element name="Suite" type="xs:string" minOccurs="0"/>
	<xs:complexType>		<xs:element name="ChallengeFormat" minOccurs="0">
	<xs:attribute name="Encoding"		<xs:complexType>
	type="pskc:ValueFormatType"		<xs:attribute name="Encoding"
	use="required"/>		type="pskc:ValueFormatType"
	<xs:attribute name="Min"		use="required"/>
	type="xs:unsignedInt" use="required"/>		<xs:attribute name="Min"
	<xs:attribute name="Max"		type="xs:unsignedInt" use="required"/>
	type="xs:unsignedInt" use="required"/>		<xs:attribute name="Max"
	<xs:attribute name="CheckDigits"		type="xs:unsignedInt" use="required"/>
	type="xs:boolean" default="false"/>		<xs:attribute name="CheckDigits"
	</xs:complexType>		type="xs:boolean" default="false"/>
	</xs:element>		</xs:complexType>
	<xs:element name="ResponseFormat" minOccurs="0">		</xs:element>
	<xs:complexType>		<xs:element name="ResponseFormat" minOccurs="0">
	<xs:attribute name="Encoding"		<xs:complexType>
	type="pskc:ValueFormatType"		<xs:attribute name="Encoding"
	use="required"/>		type="pskc:ValueFormatType"
	<xs:attribute name="Length"		use="required"/>
	type="xs:unsignedInt" use="required"/>		<xs:attribute name="Length"
	<xs:attribute name="CheckDigits"		type="xs:unsignedInt" use="required"/>
	type="xs:boolean" default="false"/>		<xs:attribute name="CheckDigits"
	</xs:complexType>		type="xs:boolean" default="false"/>
	</xs:element>		</xs:complexType>
	<xs:element name="Extensions"		</xs:element>
	type="pskc:ExtensionsType" minOccurs="0"		<xs:element name="Extensions"
	maxOccurs="unbounded"/>		type="pskc:ExtensionsType" minOccurs="0"
	</xs:choice>		maxOccurs="unbounded"/>
	</xs:complexType>		</xs:choice>
	<xs:complexType name="ExtensionsType">		</xs:complexType>
			<xs:complexType name="ExtensionsType">
			<xs:sequence>
			<xs:any namespace="##other"
			processContents="lax" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="definition"
			type="xs:anyURI" use="optional"/>
			</xs:complexType>
			<xs:simpleType name="KeyAlgorithmType">
			<xs:restriction base="xs:anyURI"/>
			</xs:simpleType>
			<xs:simpleType name="ValueFormatType">
			<xs:restriction base="xs:string">
			<xs:enumeration value="DECIMAL"/>
			<xs:enumeration value="HEXADECIMAL"/>
			<xs:enumeration value="ALPHANUMERIC"/>
			<xs:enumeration value="BASE64"/>
			<xs:enumeration value="BINARY"/>
			</xs:restriction>
			</xs:simpleType>
			<xs:complexType name="MACMethodType">
	<xs:sequence>		<xs:sequence>
	<xs:any namespace="##other"		<xs:choice>
	processContents="lax" maxOccurs="unbounded"/>		<xs:element name="MACKey"
	</xs:sequence>		type="xenc:EncryptedDataType" minOccurs="0"/>
	<xs:attribute name="definition"		<xs:element name="MACKeyReference"
	type="xs:anyURI" use="optional"/>		type="xs:string" minOccurs="0"/>
	</xs:complexType>		</xs:choice>
	<xs:simpleType name="KeyAlgorithmType">		<xs:any namespace="##other"
	<xs:restriction base="xs:anyURI"/>		processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
	</xs:simpleType>		</xs:sequence>
	<xs:simpleType name="ValueFormatType">		<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
	<xs:restriction base="xs:string">		</xs:complexType>
	<xs:enumeration value="DECIMAL"/>		<xs:element name="KeyContainer"
	<xs:enumeration value="HEXADECIMAL"/>		type="pskc:KeyContainerType"/>
	<xs:enumeration value="ALPHANUMERIC"/>		</xs:schema>
	<xs:enumeration value="BASE64"/>
	<xs:enumeration value="BINARY"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="MACMethodType">
	<xs:sequence>
	<xs:choice>
	<xs:element name="MACKey"
	type="xenc:EncryptedDataType" minOccurs="0"/>
	<xs:element name="MACKeyReference"
	type="xs:string" minOccurs="0"/>
	</xs:choice>
	<xs:any namespace="##other"
	processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
	</xs:complexType>
	<xs:element name="KeyContainer"
	type="pskc:KeyContainerType"/>
	</xs:schema>
	12. IANA Considerations		12. IANA Considerations
	12.1. Content-type registration for 'application/pskc+xml'		12.1. Content-type registration for 'application/pskc+xml'
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [RFC4288] and guidelines in		according to the procedures of RFC 4288 [RFC4288] and guidelines in
	RFC 3023 [RFC3023].		RFC 3023 [RFC3023].
	MIME media type name: application		MIME media type name: application
	skipping to change at page 49, line 16 ¶		skipping to change at page 52, line 16 ¶
	the registration request.		the registration request.
	Deprecated: TRUE if based on expert approval this entry has been		Deprecated: TRUE if based on expert approval this entry has been
	deprecated and SHOULD not be used in any new implementations.		deprecated and SHOULD not be used in any new implementations.
	Otherwise FALSE.		Otherwise FALSE.
	PSKC Profiling: Information about PSKC XML elements and attributes		PSKC Profiling: Information about PSKC XML elements and attributes
	being used (or not used) with this specific profile of PSKC.		being used (or not used) with this specific profile of PSKC.
	PSKC algorithm profile identifier registrations are to be subject to		PSKC algorithm profile identifier registrations are to be subject to
	Expert Review as per RFC 5226 [RFC5226]. Updates can be provided		Specification Required as per RFC 5226 [RFC5226]. Updates can be
	based on expert approval only. Based on expert approval, it is		provided based on expert approval only. Based on expert approval, it
	possible to mark entries as "deprecated". A designated expert will		is possible to mark entries as "deprecated". A designated expert
	be appointed by the IESG.		will be appointed by the IESG.
	IANA is asked to add an initial value to the registry based on the		IANA is asked to add two initial values to the registry based on the
	PSKC HOTP algorithm profile described in Section 10.		algorithm profiles described in Section 10.
	12.5. PSKC Version Registry		12.5. PSKC Version Registry
	IANA is requested to create a registry for PSKC version numbers. The		IANA is requested to create a registry for PSKC version numbers. The
	registry has the following structure:		registry has the following structure:
	PSKC Version | Specification		PSKC Version | Specification
	+---------------------------+----------------		+---------------------------+----------------
	| 1.0 | [This document]		| 1.0 | [This document]
	Standards action is required to define new versions of PSKC. It is		Standards action is required to define new versions of PSKC. It is
	not envisioned to deprecate, delete, or modify existing PSKC		not envisioned to deprecate, delete, or modify existing PSKC
	versions.		versions.
	12.6. Key Usage Registry		12.6. Key Usage Registry
	IANA is requested to create a registry for key usage. A description		IANA is requested to create a registry for key usage. A description
	of the 'KeyUsage' element can be found in Section 5. The registry		of the 'KeyUsage' element can be found in Section 5.
	has the following structure:
	Key Usage Token | Specification		As part of this registry IANA will maintain the following
	+---------------------------+-------------------------------		information:
	| OTP | [Section 5 of this document]
	| CR | [Section 5 of this document]
	| Encrypt | [Section 5 of this document]
	| Integrity | [Section 5 of this document]
	| Verify | [Section 5 of this document]
	| Unlock | [Section 5 of this document]
	| Decrypt | [Section 5 of this document]
	| KeyWrap | [Section 5 of this document]
	| Unwrap | [Section 5 of this document]
	| Derive | [Section 5 of this document]
	| Generate | [Section 5 of this document]
	+---------------------------+-------------------------------
	Expert Review is required to define new key usage tokens. Each		Key Usage: The identifier of the Key Usage.
	registration request has to provide a description of the semantic.
	Using the same procedure it is possible to deprecate, delete, or		Specification: IANA will be asked to add a pointer to the
	modify existing key usage tokens. A designated expert will be		specification containing information about the semantics of a new
	appointed by the IESG.		Key Usage registration.
			Deprecated: TRUE if based on expert approval this entry has been
			deprecated and SHOULD not be used in any new implementations.
			Otherwise FALSE.
			ANA is asked to add an initial value to the registry:
			Key Usage | Specification | Deprecated
			+---------------+------------------------------+-----------
			| OTP | [Section 5 of this document] | FALSE
			| CR | [Section 5 of this document] | FALSE
			| Encrypt | [Section 5 of this document] | FALSE
			| Integrity | [Section 5 of this document] | FALSE
			| Verify | [Section 5 of this document] | FALSE
			| Unlock | [Section 5 of this document] | FALSE
			| Decrypt | [Section 5 of this document] | FALSE
			| KeyWrap | [Section 5 of this document] | FALSE
			| Unwrap | [Section 5 of this document] | FALSE
			| Derive | [Section 5 of this document] | FALSE
			| Generate | [Section 5 of this document] | FALSE
			+---------------+------------------------------+-----------
			Key Usage Registry registrations are to be subject to Specification
			Required as per RFC 5226 [RFC5226]. Expert Review is required to
			define new Key Usage values. Updates can be provided based on expert
			approval only. Based on expert approval, it is possible to mark
			entries as "deprecated". A designated expert will be appointed by
			the IESG.
	13. Security Considerations		13. Security Considerations
	The portable symmetric key container (PSKC) carries sensitive		The portable symmetric key container (PSKC) carries sensitive
	information (e.g., cryptographic keys) and may be transported across		information (e.g., cryptographic keys) and may be transported across
	the boundaries of one secure perimeter to another. For example, a		the boundaries of one secure perimeter to another. For example, a
	container residing within the secure perimeter of a back-end		container residing within the secure perimeter of a back-end
	provisioning server in a secure room may be transported across the		provisioning server in a secure room may be transported across the
	internet to an end-user device attached to a personal computer. This		internet to an end-user device attached to a personal computer. This
	means that special care MUST be taken to ensure the confidentiality,		means that special care MUST be taken to ensure the confidentiality,
	skipping to change at page 51, line 48 ¶		skipping to change at page 54, line 48 ¶
	dictionary attacks to break the encryption password and recover the		dictionary attacks to break the encryption password and recover the
	information. Standard security best practices for selection of		information. Standard security best practices for selection of
	strong encryption passwords apply.		strong encryption passwords apply.
	Additionally, it is strongly RECOMMENDED that practical		Additionally, it is strongly RECOMMENDED that practical
	implementations use PBESalt and PBEIterationCount when PBE encryption		implementations use PBESalt and PBEIterationCount when PBE encryption
	is used. A different PBESalt value per PSKC SHOULD be used for best		is used. A different PBESalt value per PSKC SHOULD be used for best
	protection.		protection.
	The second approach to protecting the confidentiality of the key data		The second approach to protecting the confidentiality of the key data
	payload is based on using transport layer security. The secure		is based on using lower layer security mechanisms (e.g., [TLS],
	channel established between the source secure perimeter (the		[IPSec]). The secure connection established between the source
	provisioning server from the example above) and the target perimeter		secure perimeter (the provisioning server from the example above) and
	(the device attached to the end-user computer) utilizes encryption to		the target perimeter (the device attached to the end-user computer)
	transport the messages that travel across. No key data payload		utilizes encryption to protect the messages that travel across that
	encryption is required in this mode. Secure channels that encrypt		connection. No key data payload encryption is required in this mode.
	and digest each message provide an extra measure of security.		Secure connections that encrypt and digest each message provide an
			extra measure of security.
	Because of the fact that the plain text PSKC is protected only by the		Because of the fact that the plain text PSKC is protected only by the
	transport layer security, practical implementation MUST ensure		transport layer security, practical implementation MUST ensure
	protection against man-in-the-middle attacks. Authenticating the		protection against man-in-the-middle attacks. Authenticating the
	secure channel end-points is critically important for eliminating		secure channel end-points is critically important for eliminating
	intruders that may compromise the confidentiality of the PSKC.		intruders that may compromise the confidentiality of the PSKC.
	13.2. PSKC Integrity		13.2. PSKC Integrity
	The PSKC provides a mean to guarantee the integrity of the		The PSKC provides a mean to guarantee the integrity of the
	skipping to change at page 52, line 34 ¶		skipping to change at page 55, line 35 ¶
	13.3. PSKC Authenticity		13.3. PSKC Authenticity
	The digital signature of the PSKC is the primary way of showing its		The digital signature of the PSKC is the primary way of showing its
	authenticity. The recipient of the container SHOULD use the public		authenticity. The recipient of the container SHOULD 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 PSKC can be checked even after		Note that the digital signature of the PSKC can be checked even after
	the container has been delivered through the secure channel of		the container has been delivered through the secure channel of
	communication.		communication.
	A weaker payload authenticity guarantee may be provided by the		Authenticity guarantee may be provided by [TLS] or [IPSec]. However,
	transport layer if it is configured to digest each message it		no authenticity verification is possible once the container is
	transports. However, no authenticity verification is possible once		delivered at the recipient end. Since the TLS endpoints could differ
	the container is delivered at the recipient end. This approach may		from the key provisioning endpoints, this solution is weaker than the
	be useful in cases where the digital signature of the container does		previous solution that relies on a digital signature of the PSKC.
	not encompass the entire PSKC.
	14. Contributors		14. Contributors
	We would like Hannes Tschofenig for his text contributions to this		We would like Hannes Tschofenig for his text contributions to this
	document.		document.
	15. Acknowledgements		15. Acknowledgements
	The authors of this draft would like to thank the following people		The authors of this draft would like to thank the following people
	for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,		for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
	skipping to change at page 55, line 15 ¶		skipping to change at page 58, line 15 ¶
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[AESKWPAD]		[AESKWPAD]
	Housley, R. and M. Dworkin, "Advanced Encryption Standard		Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", March 2009, <http:		(AES) Key Wrap with Padding Algorithm", March 2009, <http:
	//www.ietf.org/internet-drafts/		//www.ietf.org/internet-drafts/
	draft-housley-aes-key-wrap-with-pad-02.txt>.		draft-housley-aes-key-wrap-with-pad-02.txt>.
			[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced
			Encryption Standard (AES)", November 2001.
	[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and		[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
	O. Ranen, "HOTP: An HMAC-Based One Time Password		O. Ranen, "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226, December 2005.		Algorithm", RFC 4226, December 2005.
			[IANAPENREG]
			IANA, "IANA Private Enterprise Number Registry",
			April 2009,
			<http://www.iana.org/assignments/enterprise-numbers/>.
	[ISOIEC7812]		[ISOIEC7812]
	ISO, "ISO/IEC 7812-1:2006 Identification cards --		ISO, "ISO/IEC 7812-1:2006 Identification cards --
	Identification of issuers -- Part 1: Numbering system",		Identification of issuers -- Part 1: Numbering system",
	October 2006, <http://www.iso.org/iso/iso_catalogue/		October 2006, <http://www.iso.org/iso/iso_catalogue/
	catalogue_tc/catalogue_detail.htm?csnumber=39698>.		catalogue_tc/catalogue_detail.htm?csnumber=39698>.
	[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)",		[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)",
	April 2009,		April 2009,
	<http://www.openauthentication.org/oath-id/prefixes/>.		<http://www.openauthentication.org/oath-id/prefixes/>.
	skipping to change at page 55, line 49 ¶		skipping to change at page 59, line 9 ¶
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol		[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
	(LDAP): String Representation of Distinguished Names",		(LDAP): String Representation of Distinguished Names",
	RFC 4514, June 2006.		RFC 4514, June 2006.
			[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
			Languages", RFC 4646, September 2006.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
			[SP800-67]
			National Institute of Standards, "NIST Special Publication
			800-67 Version 1.1: Recommendation for the Triple Data
			Encryption Algorithm (TDEA) Block Cipher", NIST Special
			Publication 800-67, May 2008.
	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,		URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
	W3C Recommendation, February 2002.		W3C Recommendation, February 2002.
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/,		URL: http://www.w3.org/TR/xmlenc-core/,
	W3C Recommendation, December 2002.		W3C Recommendation, December 2002.
	[XMLENC11]		[XMLENC11]
	Eastlake, D., "XML Encryption Syntax and Processing		Eastlake, D., "XML Encryption Syntax and Processing
	skipping to change at page 56, line 28 ¶		skipping to change at page 59, line 46 ¶
	[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-07.txt,		internet-drafts/draft-ietf-keyprov-dskpp-07.txt,
	February 2009.		February 2009.
			[IPSec] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, December 2005.
	[NIST800-57]		[NIST800-57]
	Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,		Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
	"NIST Special Publication 800-57, Recommendation for Key		"NIST Special Publication 800-57, Recommendation for Key
	Management - Part 1: General (Revised)", NIST Special		Management - Part 1: General (Revised)", NIST Special
	Publication 800-57, March 2007.		Publication 800-57, March 2007.
	[OATH] "Initiative for Open AuTHentication",		[OATH] "Initiative for Open AuTHentication",
	URL: http://www.openauthentication.org.		URL: http://www.openauthentication.org.
	[PSKC-ALGORITHM-PROFILES]		[PSKC-ALGORITHM-PROFILES]
	skipping to change at page 57, line 5 ¶		skipping to change at page 60, line 25 ¶
	May 2010.		May 2010.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 3986,		Resource Identifiers (URI): Generic Syntax", RFC 3986,
	January 2005.		January 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[XMLNS] "Namespaces in XML", W3C Recommendation ,		[XMLNS] "Namespaces in XML", W3C Recommendation ,
	URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,		URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
	January 1999.		January 1999.
	Appendix A. Use Cases		Appendix A. Use Cases
	This section describes a comprehensive list of use cases that		This section describes a comprehensive list of use cases that
	inspired the development of this specification. These requirements		inspired the development of this specification. These requirements
	were used to derive the primary requirement that drove the design.		were used to derive the primary requirement that drove the design.
	These requirements are covered in the next section.		These requirements are covered in the next section.
End of changes. 62 change blocks.
	431 lines changed or deleted		596 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/