< draft-ietf-keyprov-pskc-04.txt		draft-ietf-keyprov-pskc-05.txt >
	keyprov P. Hoyer		keyprov P. Hoyer
	Internet-Draft ActivIdentity		Internet-Draft ActivIdentity
	Intended status: Standards Track M. Pei		Intended status: Standards Track M. Pei
	Expires: April 26, 2010 VeriSign		Expires: July 9, 2010 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	October 23, 2009		January 5, 2010
	Portable Symmetric Key Container (PSKC)		Portable Symmetric Key Container (PSKC)
	draft-ietf-keyprov-pskc-04		draft-ietf-keyprov-pskc-05
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 26, 2010.		This Internet-Draft will expire on July 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	4.1. <Key>: Embedding Keying Material and Key Related		4.1. <Key>: Embedding Keying Material and Key Related
	Information . . . . . . . . . . . . . . . . . . . . . . . 9		Information . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Transmission of supplementary Information . . . . . . . . 11		4.2. Transmission of supplementary Information . . . . . . . . 11
	4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12		4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12
	4.2.2. <CryptoModuleInfo> Element: CryptoModule		4.2.2. <CryptoModuleInfo> Element: CryptoModule
	Identification . . . . . . . . . . . . . . . . . . . . 13		Identification . . . . . . . . . . . . . . . . . . . . 13
	4.2.3. <UserId> Element: User Identification . . . . . . . . 14		4.2.3. <UserId> Element: User Identification . . . . . . . . 14
	4.2.4. <AlgorithmParameters> Element: Supplementary		4.2.4. <AlgorithmParameters> Element: Supplementary
	Information for OTP and CR Algorithms . . . . . . . . 14		Information for OTP and CR Algorithms . . . . . . . . 14
	4.3. Transmission of Key Derivation Values . . . . . . . . . . 16		4.3. Transmission of Key Derivation Values . . . . . . . . . . 16
	5. Key policy - transmission of key usage policies and key		5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	PIN protection policy . . . . . . . . . . . . . . . . . . . . 18		6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 23
	6. Key protection methods . . . . . . . . . . . . . . . . . . . . 23
	6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23		6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23
	6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25		6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25
	6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26		6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26
	6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29		6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29
	6.4. Padding of encrypted values for non-padded encryption		6.4. Padding of Encrypted Values for Non-Padded Encryption
	algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30		Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30
	7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31		7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31
	8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33		8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36		9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
	10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37		10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37
	10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37		10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37		10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37
	11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39		11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	12.1. Content-type registration for 'application/pskc+xml' . . . 46		12.1. Content-type registration for 'application/pskc+xml' . . . 46
	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47		12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
	12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47		12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47
	12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48		12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48
	12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49		12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49
	12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49		12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 51		13. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 51		13.1. Payload Confidentiality . . . . . . . . . . . . . . . . . 51
	13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 52		13.2. Payload Integrity . . . . . . . . . . . . . . . . . . . . 52
	13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 52		13.3. Payload Authenticity . . . . . . . . . . . . . . . . . . . 52
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 55		16.1. Normative References . . . . . . . . . . . . . . . . . . . 55
	16.2. Informative References . . . . . . . . . . . . . . . . . . 55		16.2. Informative References . . . . . . . . . . . . . . . . . . 55
	Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57		Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57
	A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57		A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57
	A.1.1. Transport of keys from Server to Cryptographic		A.1.1. Transport of keys from Server to Cryptographic
	Module . . . . . . . . . . . . . . . . . . . . . . . . 57		Module . . . . . . . . . . . . . . . . . . . . . . . . 57
	A.1.2. Transport of keys from Cryptographic Module to		A.1.2. Transport of keys from Cryptographic Module to
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	Server . . . . . . . . . . . . . . . . . . . . . . . . 58		Server . . . . . . . . . . . . . . . . . . . . . . . . 58
	A.1.4. Server to server Bulk import/export of keys . . . . . 58		A.1.4. Server to server Bulk import/export of keys . . . . . 58
	A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58		A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58
	A.2.1. Server to server Bulk import/export of keys . . . . . 58		A.2.1. Server to server Bulk import/export of keys . . . . . 58
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
	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 authentication		encryption of data at rest, or systems used for strong
	such as those based on one-time-password (OTP) and challenge response		authentication, such as those based on one-time-password (OTP) and
	(CR) mechanisms, there is a need for vendor interoperability and a		challenge response (CR) mechanisms, there is a need for vendor
	standard format for importing and exporting (provisioning) symmetric		interoperability and a standard format for importing and exporting
	keys. Traditionally, for example, vendors of authentication servers		(provisioning) symmetric keys. For instance, traditionally, vendors
	and service providers have used proprietary formats for importing and		of authentication servers and service providers have used proprietary
	exporting these keys into their systems, thus making it hard to use		formats for importing and exporting these keys into their systems,
	tokens from vendor "Foo" with a server from vendor "Bar".		thus making it hard to use tokens from two different vendors.
	This document defines a standardized XML-based key container, called		This document defines a standardized XML-based key container, called
	Portable Symmetric Key Container (PSKC), for transporting symmetric		Portable Symmetric Key Container (PSKC), for transporting symmetric
	keys and key related meta data. The document also specifies the		keys and key related meta data. The document also specifies the
	information elements that may be required when the symmetric key is		information elements that are required when the symmetric key is
	utilized for specific purposes, such as the initial counter in the		utilized for specific purposes, such as the initial counter in the
	MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also		MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also
	requests the creation of an IANA registry for algorithm profiles		requests the creation of an IANA registry for algorithm profiles
	where algorithms, their related meta-data and PSKC transmission		where algorithms, their meta-data and PSKC transmission profile can
	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. Versions
	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.
	1.3. Namespace Identifiers		1.3. Namespace Identifiers
	This document uses Uniform Resource Identifiers [RFC2396] 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:
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
	References to qualified elements in the PSKC schema defined herein		References to qualified elements in the PSKC schema defined herein
	use the prefix "pskc".		use the prefix "pskc".
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	and criteria to uniquely identify the device		and criteria to uniquely identify the device
	4. CryptoModuleInfo entity - representing the information about the		4. CryptoModuleInfo entity - representing the information about the
	CryptoModule where the keys reside or are provisioned to		CryptoModule where the keys reside or are provisioned to
	5. Key entity - representing the key transported or provisioned		5. Key entity - representing the key transported or provisioned
	6. Data entity - representing a list of meta-data related to the		6. Data entity - representing a list of meta-data related to the
	key, where the element name is the name of the meta-data and its		key, where the element name is the name of the meta-data and its
	associated value is either in encrypted form (for example for		associated value is either in encrypted form (for example for
	Data element 'SECRET') or plaintext (for example for the Data		Data element <Secret>) or plaintext (for example the Data element
	element 'COUNTER')		<Counter>)
	Figure 1 shows the high-level structure of the PSKC data elements.		Figure 1 shows the high-level structure of the PSKC data elements.
	-----------------		-----------------
	| KeyContainer |		| KeyContainer |
	|---------------|		|---------------|
	| EncryptionKey |		| EncryptionKey |
	| Signature |		| Signature |
	| ... |		| ... |
	-----------------		-----------------
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 44 ¶
	/|\ 0..n		/|\ 0..n
	--------------------------------------- - -		--------------------------------------- - -
	| | |		| | |
	------------------ ---------------- -------- - -		------------------ ---------------- -------- - -
	| Data:Secret | | Data:Counter | | Data:other		| Data:Secret | | Data:Counter | | Data:other
	|----------------| |--------------| |-- - -		|----------------| |--------------| |-- - -
	| EncryptedValue | | PlainValue |		| EncryptedValue | | PlainValue |
	| ValueMAC | ----------------		| ValueMAC | ----------------
	------------------		------------------
	Figure 1		Figure 1: PSKC data elements relationship diagram
	The following sections describe in detail all the entities and		The following sections describe in detail all the entities and
	related XML schema elements and attributes.		related XML schema elements and attributes.
	4. <KeyContainer> Element: The Basics		4. <KeyContainer> Element: The Basics
	In its most basic form, a PSKC document uses the top-level element		In its most basic form, a PSKC document uses the top-level element
	<KeyContainer> and a single <KeyPackage> element to carry key		<KeyContainer> and a single <KeyPackage> element to carry key
	information.		information.
	skipping to change at page 12, line 21 ¶		skipping to change at page 12, line 21 ¶
	<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>
	<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
	<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>
	</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.2.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
	skipping to change at page 13, line 22 ¶		skipping to change at page 13, line 22 ¶
	<Model>: This element describes the model of the device (e.g., one-		<Model>: This element describes the model of the device (e.g., one-
	button-HOTP-token-V1).		button-HOTP-token-V1).
	<IssueNo>: This element contains the issue number in case devices		<IssueNo>: This element contains the issue number in case devices
	with the same serial number that are distinguished by different		with the same serial number that are distinguished by different
	issue numbers.		issue numbers.
	<DeviceBinding>: This element allows a provisioning server to ensure		<DeviceBinding>: This element allows a provisioning server to ensure
	that the key is going to be loaded into the device for which the		that the key is going to be loaded into the device for which the
	key provisioning request was approved. The device is bound to the		key provisioning request was approved. The device is bound to the
	request using a device identifier, e.g., an IMEI for the phone, or		request using a device identifier, e.g., an International Mobile
	an identifier for a class of identifiers, e.g., those for which		Equipment Identity (IMEI) for the phone, or an identifier for a
	the keys are protected by a TPM.		class of identifiers, e.g., those for which the keys are protected
			by a Trusted Platform Module (TPM).
	<StartDate>: and <ExpiryDate>: These two elements indicate the start		<StartDate>: and <ExpiryDate>: These two elements indicate the start
	and end date of a device (such as the one on a payment card, used		and end date of a device (such as the one on a payment card, used
	when issue numbers are not printed on cards). The date MUST be		when issue numbers are not printed on cards). The date MUST be
	expressed in UTC form with no timezone component. Implementations		expressed in UTC form with no timezone component. Implementations
	SHOULD NOT rely on time resolution finer than milliseconds and		SHOULD NOT rely on time resolution finer than milliseconds and
	MUST NOT generate time instants that specify leap seconds.		MUST NOT generate time instants that specify leap seconds.
	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
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 21 ¶
	unencoded value.		unencoded value.
	4.3. Transmission of Key Derivation Values		4.3. 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 attributes		card application personalisation profile id related to specific
	present on a smart card application that have influence when		attribute values present on a smart card application, that have
	computing a response.).		influence when computing a response.).
	For example, in the case of MasterCard's Chip Authentication Program		For example, in the case of MasterCard's Chip Authentication Program
	[CAP], sending and receiving party would agree that KeyProfileId='1'		[CAP], the sending and the receiving party would agree that
	represents a certain set of values (e.g., Internet Authentication		KeyProfileId='1' represents a certain set of values (e.g., Internet
	Flag IAF set to a specific value). During transmission of the		Authentication Flag IAF set to a specific value). During
	KeyContainer, these values would not be transmitted as key attributes		transmission of the KeyContainer, these values would not be
	but only referred to via the <KeyProfileId> element set to the		transmitted as key attributes but only referred to via the
	specific agreed profile (in this case '1'). The receiving party can		<KeyProfileId> element set to the specific agreed profile (in this
	then associate all relevant key attributes contained in the out of		case '1'). The receiving party can then associate all relevant key
	band agreed profile with the imported keys. Often this methodology		attributes contained in the out of band agreed profile with the
	is used between a manufacturing service, run by company A and the		imported keys. Often this methodology is used between a
	validation service run by company B, to avoid repeated transmission		manufacturing service, run by company A and the validation service
	of the same set of key attribute values.		run by company B, to avoid repeated transmission of the same set of
			key attribute values.
	The <KeyReference> element contains a reference to an external key to		The <KeyReference> element contains a reference to an external key to
	be used with a key derivation scheme and no specific key value		be used with a key derivation scheme and no specific key value
	(secret) is transported but only the reference to the external master		(secret) is transported but only the reference to the external master
	key is used (e.g., the PKCS#11 key label).		key is used (e.g., the PKCS#11 key label).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.0" id="exampleID1"		<KeyContainer Version="1.0" Id="exampleID1"
	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"
	skipping to change at page 17, line 41 ¶		skipping to change at page 17, line 41 ¶
	<KeyUsage>OTP</KeyUsage>		<KeyUsage>OTP</KeyUsage>
	</Policy>		</Policy>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	Figure 4: Example of a PSKC Document transmitting a HOTP key via key		Figure 4: Example of a PSKC Document transmitting a HOTP key via key
	derivation values		derivation values
	The key value will be derived using the value of the <SerialNo>		The key value will be derived using the value of the <SerialNo>
	element, values agreed between sending and receiving parties and		element, values agreed between the sending and the receiving parties
	identified by the KeyProfile 'keyProfile1' and an external agreed key		and identified by the KeyProfile 'keyProfile1' and an externally
	referenced by the label 'MasterKeyLabel'.		agreed key referenced by the label 'MasterKeyLabel'.
	5. Key policy - transmission of key usage policies and key PIN		5. Key Policy
	protection policy
	This section illustrates the functionality of the <Policy> element		This section illustrates the functionality of the <Policy> element
	within PSKC that allows policy to be attached to a key and its		within PSKC that allows a key usage and key PIN protection policy to
	related meta data. This element is a child element of the <Key>		be attached to a specific key and its related meta data. This
	element.		element is a child element of the <Key> element.
	If the <Policy> element contains child elements or values within		If the <Policy> element contains child elements or values within
	elements/attributes that are not understood by the recipient of the		elements/attributes that are not understood by the recipient of the
	PSKC document then the recipient MUST assume that key usage is not		PSKC document then the recipient MUST assume that key usage is not
	permitted. This statement ensures that the lack of understanding of		permitted. This statement ensures that the lack of understanding of
	certain extensions does not lead to unintended key usage.		certain extensions does not lead to unintended key usage.
	We will start our description with an example that expands the		We will start our description with an example that expands the
	example shown in Figure 3.		example shown in Figure 3.
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	'PINEncoding': This attribute indicates the encoding of the PIN		'PINEncoding': This attribute indicates the encoding of the PIN
	and MUST be one of the values: DECIMAL, HEXADECIMAL,		and MUST be one of the values: DECIMAL, HEXADECIMAL,
	ALPHANUMERIC, BASE64, or BINARY.		ALPHANUMERIC, BASE64, or BINARY.
	If the 'PinUsageMode' attribute is set to "Local" then the device		If the 'PinUsageMode' attribute is set to "Local" then the device
	MUST enforce the restriction indicated in the 'MaxFailedAttempts',		MUST enforce the restriction indicated in the 'MaxFailedAttempts',
	'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it		'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it
	MUST be enforced on the server side.		MUST be enforced on the server side.
	6. 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,
	and asymmetric keys. When encryption algorithms are used that make		and asymmetric keys. When encryption algorithms are used that make
	skipping to change at page 23, line 27 ¶		skipping to change at page 23, line 27 ¶
	random IV value MUST be generated for each value to be encrypted and		random IV value MUST be generated for each value to be encrypted and
	it MUST be prepended to the resulting encrypted value as specified in		it MUST be prepended to the resulting encrypted value as specified in
	[XMLENC].		[XMLENC].
	6.1. Encryption based on Pre-Shared Keys		6.1. Encryption based on Pre-Shared Keys
	Figure 6 shows an example that illustrates the encryption of the		Figure 6 shows an example that illustrates the encryption of the
	content of the <Secret> element using AES128-CBC and PKCS5 Padding.		content of the <Secret> element using AES128-CBC and PKCS5 Padding.
	The plaintext value of <Secret> is		The plaintext value of <Secret> is
	'3132333435363738393031323334353637383930'. The name of the pre-		'3132333435363738393031323334353637383930'. The name of the pre-
	shared secret is "Example-Key1", as set in the <KeyName> element		shared secret is "Pre-shared-key", as set in the <KeyName> element
	(which is a child element of the <EncryptionKey> element). The value		(which is a child element of the <EncryptionKey> element). The value
	of the encryption key used is '12345678901234567890123456789012'.		of the encryption key used is '12345678901234567890123456789012'.
	The IV for the MAC key is '11223344556677889900112233445566' and the		The IV for the MAC key is '11223344556677889900112233445566' and the
	IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.		IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
	As AES128-CBC does not provide integrity checks a keyed MAC is		As AES128-CBC does not provide integrity checks a keyed MAC is
	applied to the encrypted value using a MAC key and a MAC algorithm as		applied to the encrypted value using a MAC key and a MAC algorithm as
	declared in the <MACMethod> element (in our example		declared in the <MACMethod> element (in our example
	"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the		"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the
	skipping to change at page 24, line 39 ¶		skipping to change at page 24, line 39 ¶
	<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>
	<xenc:CipherValue>		<xenc:CipherValue>
	AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv		AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
	</xenc:CipherValue>		</xenc:CipherValue>
	</xenc:CipherData>		</xenc:CipherData>
	</EncryptedValue>		</EncryptedValue>
	<ValueMAC>aSRlEG1agUo0CS2dt/OvIAqQ6Co=		<ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc=
	</ValueMAC>		</ValueMAC>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	</Key>		</Key>
	</KeyPackage>		</KeyPackage>
	</KeyContainer>		</KeyContainer>
	skipping to change at page 25, line 42 ¶		skipping to change at page 25, line 42 ¶
	KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128		KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
	KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192		KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
	KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256		KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
	6.1.1. MAC Method		6.1.1. MAC Method
	When algorithms without integrity checks are used, such as AES-128-		When algorithms without integrity checks are used, such as AES-128-
	CBC, a keyed MAC value MUST be placed in the <ValueMAC> element of		CBC, a keyed MAC value MUST be placed in the <ValueMAC> element of
	the <Data> element. In this case the MAC algorithm type MUST be set		the <Data> element. In this case the MAC algorithm type MUST be set
	in the <MACMethod> element of the <KeyContainer> element. The MAC		in the <MACMethod> element of the <KeyContainer> element. The MAC
	key MUST be a randomly generated key by the sender, a pre-shared one		key MUST be a randomly generated key by the sender, be pre-agreed
	between the receiver and the sender, or one set by an application		between the receiver and the sender, or be set by the application
	protocol that uses KeyContainer. It is recommended that a sender		protocol that carries the PSKC document. It is RECOMMENDED that the
	generates a random MAC key. When the sender generates such a random		sender generates a random MAC key. When the sender generates such a
	MAC key, the MAC key material MUST be encrypted with the same		random MAC key, the MAC key material MUST be encrypted with the same
	encryption key specified in <EncryptionKey> element of the key		encryption key specified in <EncryptionKey> element of the key
	container. The encryption method and encrypted value MUST be set		container. The encryption method and encrypted value MUST be set
	respectively in the <EncryptionMethod> element and the <CipherData>		respectively in the <EncryptionMethod> element and the <CipherData>
	element of the <MACKey> element in the <MACMethod> element. The		element of the <MACKey> element in the <MACMethod> element. The
	<MACKeyReference> element of the <MACMethod> element MAY be used to		<MACKeyReference> element of the <MACMethod> element MAY be used to
	indicate a pre-shared MAC key or a provisioning protocol derived MAC		indicate a pre-shared MAC key or a provisioning protocol derived MAC
	key. For systems implementing PSKC it is RECOMMENDED to implement		key. For systems implementing PSKC it is RECOMMENDED to implement
	the HMAC-SHA1 (with the URI of		the HMAC-SHA1 (with the URI of
	'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC		'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC
	algorithms that can optionally be implemented are:		algorithms that can optionally be implemented are:
	skipping to change at page 26, line 35 ¶		skipping to change at page 26, line 35 ¶
	passphrased-based key. A <DerivedKey> element is set as the child		passphrased-based key. A <DerivedKey> element is set as the child
	element of <EncryptionKey> element of the key container.		element of <EncryptionKey> element of the key container.
	The <DerivedKey> element is used to specify the key derivation		The <DerivedKey> element is used to specify the key derivation
	function and related parameters. The encryption algorithm, in this		function and related parameters. The encryption algorithm, in this
	example AES-128-CBC ( URI		example AES-128-CBC ( URI
	'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the		'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the
	'Algorithm' attribute of <EncryptionMethod> element used inside the		'Algorithm' attribute of <EncryptionMethod> element used inside the
	encrypted data elements.		encrypted data elements.
	When PBKDF2 is used, the attribute "Algorithm" of the element		When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11:
	<xenc11:KeyDerivationMethod> MUST be set to the URI		KeyDerivationMethod> element MUST be set to the URI
	'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The		'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The
	element <xenc11:KeyDerivationMethod> MUST include the <PBKDF2-params>		<xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params>
	child element to indicate the PBKDF2 parameters, such as salt and		child element to indicate the PBKDF2 parameters, such as salt and
	iteration count.		iteration count.
	When the encryption method uses a CBC mode that uses an explicit		When the encryption method uses a CBC mode that uses an explicit
	initialization vector (IV) other than a derived one, the IV MUST be		initialization vector (IV) other than a derived one, the IV MUST be
	passed by prepending it to the encrypted value.		passed by prepending it to the encrypted value.
	In the example below, the following data is used.		In the example below, the following data is used.
	Password: qwerty		Password: qwerty
	skipping to change at page 28, line 9 ¶		skipping to change at page 28, line 9 ¶
	<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>		<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
	</xenc11:DerivedKey>		</xenc11:DerivedKey>
	</pskc:EncryptionKey>		</pskc:EncryptionKey>
	<pskc:MACMethod		<pskc:MACMethod
	Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">		Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
	<pskc:MACKey>		<pskc:MACKey>
	<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>
	<xenc:CipherValue>		<xenc:CipherValue>
	2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ		2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
	SWJblA7Dzi031L6FNnUrcjsGGcQ==
	</xenc:CipherValue>		</xenc:CipherValue>
	</xenc:CipherData>		</xenc:CipherData>
	</pskc:MACKey>		</pskc:MACKey>
	</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>
	skipping to change at page 30, line 36 ¶		skipping to change at page 30, line 36 ¶
	RSA-1.5 algorithm, identified by the URI		RSA-1.5 algorithm, identified by the URI
	'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.		'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
	Some of the asymmetric encryption algorithms that can optionally be		Some of the asymmetric encryption algorithms that can optionally be
	implemented are:		implemented are:
	Algorithm | Uniform Resource Locator (URL)		Algorithm | Uniform Resource Locator (URL)
	------------------+-------------------------------------------------		------------------+-------------------------------------------------
	RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p		RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
	6.4. Padding of encrypted values for non-padded encryption algorithms		6.4. Padding of Encrypted Values for Non-Padded Encryption Algorithms
	Padding of encrypted values (for example the key secret value) is		Padding of encrypted values (for example the key secret value) is
	required when key protection algorithms are used that do not support		required when key protection algorithms are used that do not support
	embedded padding and the value to be encrypted is not a multiple of		embedded padding and the value to be encrypted is not a multiple of
	the encryption algorithm cypher block length.		the encryption algorithm cypher block length.
	For example, when transmitting a HOTP key (20 bytes long) protected		For example, when transmitting a HOTP key (20 bytes long) protected
	with the AES algorithm in CBC mode (8 byte block cypher), since 20		with the AES algorithm in CBC mode (8 byte block cypher), padding is
	bytes are not a multiple of the 8 byte block length, padding is		required since 20 bytes are not a multiple of the 8 byte block
	required.		length.
	In these cases, for systems implementing PSKC it is RECOMMENDED to		In these cases, for systems implementing PSKC it is RECOMMENDED to
	pad the value before encryption using PKCS5 padding as described in		pad the value before encryption using PKCS5 padding as described in
	[PKCS5].		[PKCS5].
	7. Digital Signature		7. Digital Signature
	PSKC allows a digital signature to be added to the XML document, as a		PSKC allows a digital signature to be added to the XML document, as a
	child element of the <KeyContainer> element. The description of the		child element of the <KeyContainer> element. The description of the
	XML digital signature can be found in [XMLDSIG].		XML digital signature can be found in [XMLDSIG].
	skipping to change at page 33, line 13 ¶		skipping to change at page 33, line 13 ¶
	Figure 9: Digital Signature Example		Figure 9: Digital Signature Example
	8. Bulk Provisioning		8. Bulk Provisioning
	The functionality of bulk provisioning can be accomplished by		The functionality of bulk provisioning can be accomplished by
	repeating the <KeyPackage> element multiple times within the		repeating the <KeyPackage> element multiple times within the
	<KeyContainer> element indicating that multiple keys are provided to		<KeyContainer> element indicating that multiple keys are provided to
	different devices or cryptomodules. The <EncryptionKey> element then		different devices or cryptomodules. The <EncryptionKey> element then
	applies to all <KeyPackage> elements. When provisioning multiple		applies to all <KeyPackage> elements. When provisioning multiple
	keys to the same device the <KeyPackage> element is repeated but the		keys to the same device the <KeyPackage> element is repeated but the
	enclosed <DeviceInfo> element will contain the same sub elements that		enclosed <DeviceInfo> element will contain the same sub-elements that
	uniquely identify the single device.		uniquely identify the single device (for example the keys for the
			device identified by SerialNo='9999999' in the example below).
	Figure 10 shows an example utilizing these capabilities.		Figure 10 shows an example utilizing these capabilities.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<KeyContainer Version="1.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>
	skipping to change at page 34, line 52 ¶		skipping to change at page 35, line 4 ¶
	MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=		MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
	</PlainValue>		</PlainValue>
	</Secret>		</Secret>
	<Counter>		<Counter>
	<PlainValue>0</PlainValue>		<PlainValue>0</PlainValue>
	</Counter>		</Counter>
	</Data>		</Data>
	<Policy>		<Policy>
	<StartDate>2006-03-01T00:00:00Z</StartDate>		<StartDate>2006-03-01T00:00:00Z</StartDate>
	<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>		<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
	</Policy>
			</Policy>
	</Key>		</Key>
			</KeyPackage>
			<KeyPackage>
			<DeviceInfo>
			<Manufacturer>TokenVendorAcme</Manufacturer>
			<SerialNo>9999999</SerialNo>
			</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=
	skipping to change at page 36, line 29 ¶		skipping to change at page 36, line 29 ¶
	elsewhere the "<xs:any namespace="##other" processContents="lax"		elsewhere the "<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>" XML extension point is		minOccurs="0" maxOccurs="unbounded"/>" XML extension point is
	utilized.		utilized.
	New XML Attributes: The XML schema allows new XML attributes to be		New XML Attributes: The XML schema allows new XML attributes to be
	added where XML extension points have been defined (see "<xs:		added where XML extension points have been defined (see "<xs:
	anyAttribute namespace="##other"/>" in Section 11).		anyAttribute namespace="##other"/>" in Section 11).
	New PSKC Algorithm Profiles: This document defines two PSKC		New PSKC Algorithm Profiles: This document defines two PSKC
	algorithm profiles, see Section 10. The following informational		algorithm profiles, see Section 10. The following informational
	draft describes additional profiles [PSKC-ALGORITHM-PROFILES].		document describes additional profiles [PSKC-ALGORITHM-PROFILES].
	Further PSKC algorithm profiles can be registered as described in		Further PSKC algorithm profiles can be registered as described in
	Section 12.4.		Section 12.4.
	Algorithm URIs: Section 6 defines how keys and related data can be		Algorithm URIs: Section 6 defines how keys and related data can be
	protected. A number of algorithms can be used. The use of new		protected. A number of algorithms can be used. The use of new
	algorithms can be used by pointing to a new algorithm URI.		algorithms can be used by pointing to a new algorithm URI.
	Policy: Section 5 defines policies that can be attached to a key and		Policy: Section 5 defines policies that can be attached to a key and
	keying related data. The <Policy> element is one such item that		keying related data. The <Policy> element is one such item that
	allows to restrict the use of the key to certain functions, such		allows to restrict the use of the key to certain functions, such
	skipping to change at page 37, line 29 ¶		skipping to change at page 37, line 29 ¶
	Registrant Contact: IESG		Registrant Contact: IESG
	Profiling:		Profiling:
	The <KeyPackage> element MUST be present and the		The <KeyPackage> element MUST be present and the
	<ResponseFormat> element, which is a child element of the		<ResponseFormat> element, which is a child element of the
	<AlgorithmParameters> element, MUST be used to indicate the OTP		<AlgorithmParameters> element, MUST be used to indicate the OTP
	length and the value format.		length and the value format.
	The <Counter> element (see Section 4.1) MUST be provided as		The <Counter> element (see Section 4.1) MUST be provided as
	meta data for the key.		meta-data for the key.
	The following additional constraints apply:		The following additional constraints apply:
	+ The value of the <Secret> element MUST contain key material		+ The value of the <Secret> element MUST contain key material
	with a length of at least 16 octets (128 bits), if it is		with a length of at least 16 octets (128 bits), if it is
	present.		present.
	+ The <ResponseFormat> element MUST have the 'Format'		+ The <ResponseFormat> element MUST have the 'Format'
	attribute set to "DECIMAL", and the 'Length' attribute MUST		attribute set to "DECIMAL", and the 'Length' attribute MUST
	indicate a length value between 6 and 9.		indicate a length value between 6 and 9 (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. KEYPROV-PIN
	Common Name: KEYPROV-PIN		Common Name: KEYPROV-PIN
	Class: Symmetric static credential comparison		Class: Symmetric static credential comparison
	skipping to change at page 47, line 20 ¶		skipping to change at page 47, line 20 ¶
	Author: This specification is a work item of the IETF KEYPROV		Author: This specification is a work item of the IETF KEYPROV
	working group, with mailing list address <keyprov@ietf.org>.		working group, with mailing list address <keyprov@ietf.org>.
	Change controller: The IESG <iesg@ietf.org>		Change controller: The IESG <iesg@ietf.org>
	12.2. XML Schema Registration		12.2. XML Schema Registration
	This section registers an XML schema as per the guidelines in		This section registers an XML schema as per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:ns:keyprov:pskc		URI: urn:ietf:params:xml:schema:keyprov:pskc
	Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer		Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
	(Philip.Hoyer@actividentity.com).		(Philip.Hoyer@actividentity.com).
	XML Schema: The XML schema to be registered is contained in		XML Schema: The XML schema to be registered is contained in
	Section 11. Its first line is		Section 11. Its first line is
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	and its last line is		and its last line is
	skipping to change at page 49, line 12 ¶		skipping to change at page 49, line 12 ¶
	Algorithm Definition: A reference to the stable document in which		Algorithm Definition: A reference to the stable document in which
	the algorithm being used with the PSKC is defined.		the algorithm being used with the PSKC is defined.
	Registrant Contact: Contact information about the party submitting		Registrant Contact: Contact information about the party submitting
	the registration request.		the registration request.
	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].		Expert Review as per RFC 5226 [RFC5226]. 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.
	IANA is asked to add an initial value to the registry based on the		IANA is asked to add an initial value to the registry based on the
	PSKC HOTP algorithm profile described in Section 10.		PSKC HOTP algorithm profile described in Section 10.
	12.5. PSKC Version Registry		12.5. PSKC Version Registry
	IANA is requested to create a registry for PSKC version numbers. The		IANA is requested to create a registry for PSKC version numbers. The
	registry has the following structure:		registry has the following structure:
	PSKC Version | Specification		PSKC Version | Specification
	skipping to change at page 49, line 50 ¶		skipping to change at page 50, line 4 ¶
	| Encrypt | [Section 5 of this document]		| Encrypt | [Section 5 of this document]
	| Integrity | [Section 5 of this document]		| Integrity | [Section 5 of this document]
	| Verify | [Section 5 of this document]		| Verify | [Section 5 of this document]
	| Unlock | [Section 5 of this document]		| Unlock | [Section 5 of this document]
	| Decrypt | [Section 5 of this document]		| Decrypt | [Section 5 of this document]
	| KeyWrap | [Section 5 of this document]		| KeyWrap | [Section 5 of this document]
	| Unwrap | [Section 5 of this document]		| Unwrap | [Section 5 of this document]
	| Derive | [Section 5 of this document]		| Derive | [Section 5 of this document]
	| Generate | [Section 5 of this document]		| Generate | [Section 5 of this document]
	+---------------------------+-------------------------------		+---------------------------+-------------------------------
	Expert Review is required to define new key usage tokens. Each		Expert Review is required to define new key usage tokens. Each
	registration request has to provide a description of the semantic.		registration request has to provide a description of the semantic.
	Using the same procedure it is possible to deprecate, delete, or		Using the same procedure it is possible to deprecate, delete, or
	modify existing key usage tokens.		modify existing key usage tokens. A designated expert will be
			appointed by the IESG.
	13. Security Considerations		13. Security Considerations
	The portable key container carries sensitive information (e.g.,		The portable key container carries sensitive information (e.g.,
	cryptographic keys) and may be transported across the boundaries of		cryptographic keys) and may be transported across the boundaries of
	one secure perimeter to another. For example, a container residing		one secure perimeter to another. For example, a container residing
	within the secure perimeter of a back-end provisioning server in a		within the secure perimeter of a back-end provisioning server in a
	secure room may be transported across the internet to an end-user		secure room may be transported across the internet to an end-user
	device attached to a personal computer. This means that special care		device attached to a personal computer. This means that special care
	must be taken to ensure the confidentiality, integrity, and		must be taken to ensure the confidentiality, integrity, and
	authenticity of the information contained within.		authenticity of the information contained within.
	13.1. Payload confidentiality		13.1. Payload Confidentiality
	By design, the container allows two main approaches to guaranteeing		By design, the container allows two main approaches to guaranteeing
	the confidentiality of the information it contains while transported.		the confidentiality of the information it contains while transported.
	First, the container key data payload may be encrypted.		First, the container key data payload may be encrypted.
	In this case no transport layer security is required. However,		In this case no transport layer security is required. However,
	standard security best practices apply when selecting the strength of		standard security best practices apply when selecting the strength of
	the cryptographic algorithm for payload encryption. Symmetric		the cryptographic algorithm for payload encryption. Symmetric
	cryptographic cipher should be used - the longer the cryptographic		cryptographic cipher should be used - the longer the cryptographic
	skipping to change at page 52, line 12 ¶		skipping to change at page 52, line 12 ¶
	in this mode. Secure channels that encrypt and digest each message		in this mode. Secure channels that encrypt and digest each message
	provide an extra measure of security, especially when the signature		provide an extra measure of security, especially when the signature
	of the payload does not encompass the entire payload.		of the payload does not encompass the entire payload.
	Because of the fact that the plain text payload is protected only by		Because of the fact that the plain text payload is protected only by
	the transport layer security, practical implementation must ensure		the transport layer security, practical implementation must ensure
	protection against man-in-the-middle attacks. Validating the secure		protection against man-in-the-middle attacks. Validating the secure
	channel end-points is critically important for eliminating intruders		channel end-points is critically important for eliminating intruders
	that may compromise the confidentiality of the payload.		that may compromise the confidentiality of the payload.
	13.2. Payload integrity		13.2. Payload Integrity
	The portable symmetric key container provides a mean to guarantee the		The portable symmetric key container provides a mean to guarantee the
	integrity of the information it contains through digital signatures.		integrity of the information it contains through digital signatures.
	For best security practices, the digital signature of the container		For best security practices, the digital signature of the container
	should encompass the entire payload. This provides assurances for		should encompass the entire payload. This provides assurances for
	the integrity of all attributes. It also allows verification of the		the integrity of all attributes. It also allows verification of the
	integrity of a given payload even after the container is delivered		integrity of a given payload even after the container is delivered
	through the communication channel to the target perimeter and channel		through the communication channel to the target perimeter and channel
	message integrity check is no longer possible.		message integrity check is no longer possible.
	13.3. Payload authenticity		13.3. Payload Authenticity
	The digital signature of the payload is the primary way of showing		The digital signature of the payload is the primary way of showing
	its authenticity. The recipient of the container may use the public		its authenticity. The recipient of the container may use the public
	key associated with the signature to assert the authenticity of the		key associated with the signature to assert the authenticity of the
	sender by tracing it back to a preloaded public key or certificate.		sender by tracing it back to a preloaded public key or certificate.
	Note that the digital signature of the payload can be checked even		Note that the digital signature of the payload can be checked even
	after the container has been delivered through the secure channel of		after the container has been delivered through the secure channel of
	communication.		communication.
	A weaker payload authenticity guarantee may be provided by the		A weaker payload authenticity guarantee may be provided by the
	skipping to change at page 56, line 36 ¶		skipping to change at page 56, line 36 ¶
	URL: http://www.openauthentication.org.		URL: http://www.openauthentication.org.
	[PSKC-ALGORITHM-PROFILES]		[PSKC-ALGORITHM-PROFILES]
	Hoyer, P., Pei, M., Machani, S., and A. Doherty,		Hoyer, P., Pei, M., Machani, S., and A. Doherty,
	"Additional Portable Symmetric Key Container (PSKC)		"Additional Portable Symmetric Key Container (PSKC)
	Algorithm Profiles", Internet Draft Informational, URL:		Algorithm Profiles", Internet Draft Informational, URL:
	http://tools.ietf.org/html/		http://tools.ietf.org/html/
	draft-hoyer-keyprov-pskc-algorithm-profiles-00,		draft-hoyer-keyprov-pskc-algorithm-profiles-00,
	December 2008.		December 2008.
	[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Masinter, "Uniform Resource Identifiers (URI): Generic		Resource Identifiers (URI): Generic Syntax", RFC 3986,
	Syntax", BCP 26, RFC 2396, August 1998.		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.
	[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
	skipping to change at page 62, line 13 ¶		skipping to change at page 62, line 13 ¶
	key encryption key is difficult to use.		key encryption key is difficult to use.
	Authors' Addresses		Authors' Addresses
	Philip Hoyer		Philip Hoyer
	ActivIdentity, Inc.		ActivIdentity, Inc.
	117 Waterloo Road		117 Waterloo Road
	London, SE1 8UL		London, SE1 8UL
	UK		UK
	Phone: +44 (0) 20 7744 6455		Phone: +44 (0) 20 7960 0220
	Email: Philip.Hoyer@actividentity.com		Email: phoyer@actividentity.com
	Mingliang Pei		Mingliang Pei
	VeriSign, Inc.		VeriSign, Inc.
	487 E. Middlefield Road		487 E. Middlefield Road
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		USA
	Phone: +1 650 426 5173		Phone: +1 650 426 5173
	Email: mpei@verisign.com		Email: mpei@verisign.com
End of changes. 49 change blocks.
	91 lines changed or deleted		99 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/