< draft-ietf-keyprov-pskc-05.txt		draft-ietf-keyprov-pskc-06.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: July 9, 2010 VeriSign		Expires: November 15, 2010 VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	January 5, 2010		May 14, 2010
	Portable Symmetric Key Container (PSKC)		Portable Symmetric Key Container (PSKC)
	draft-ietf-keyprov-pskc-05		draft-ietf-keyprov-pskc-06
			Abstract
			This document specifies a symmetric key format for transport and
			provisioning of symmetric keys to different types of crypto modules.
			For example, One Time Password (OTP) shared secrets or symmetric
			cryptographic keys to strong authentication devices. A standard key
			transport format enables enterprises to deploy best-of-breed
			solutions combining components from different vendors into the same
			infrastructure.
	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 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 July 9, 2010.		This Internet-Draft will expire on November 15, 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document specifies a symmetric key format for transport and		described in the BSD License.
	provisioning of symmetric keys to different types of crypto modules.
	For example, One Time Password (OTP) shared secrets or symmetric
	cryptographic keys to strong authentication devices. A standard key
	transport format enables enterprises to deploy best-of-breed
	solutions combining components from different vendors into the same
	infrastructure.
	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. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4		1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4
	1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4		1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4
	1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5		1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 4 ¶
	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. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 51
	13.2. Payload Integrity . . . . . . . . . . . . . . . . . . . . 52		13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 52
	13.3. Payload Authenticity . . . . . . . . . . . . . . . . . . . 52		13.3. PSKC 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 . . . . . . . . . . . . . . . . . . 56
	Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57		Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 58
	A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57		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 . . . . . . . . . . . . . . . . . . . . . . . . 57		Module . . . . . . . . . . . . . . . . . . . . . . . . 58
	A.1.2. Transport of keys from Cryptographic Module to		A.1.2. Transport of keys from Cryptographic Module to
	Cryptographic Module . . . . . . . . . . . . . . . . . 57		Cryptographic Module . . . . . . . . . . . . . . . . . 58
	A.1.3. Transport of keys from Cryptographic Module to		A.1.3. Transport of keys from Cryptographic Module to
	Server . . . . . . . . . . . . . . . . . . . . . . . . 58		Server . . . . . . . . . . . . . . . . . . . . . . . . 59
	A.1.4. Server to server Bulk import/export of keys . . . . . 58		A.1.4. Server to server Bulk import/export of keys . . . . . 59
	A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58		A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 59
	A.2.1. Server to server Bulk import/export of keys . . . . . 58		A.2.1. Server to server Bulk import/export of keys . . . . . 59
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 61
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
	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
	formats for importing and exporting these keys into their systems,		formats for importing and exporting these keys into their systems,
	thus making it hard to use tokens from two different vendors.		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 are 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		HMAC-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 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].
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	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:
	xmlns:pskc="urn:ietf:params:xml:ns:keyprov: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 in this
	use the prefix "pskc".		specification and used in the example use the prefix "pskc" (defined
			as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc") . It is
			RECOMMENDED to use this namespace in implementations.
	1.3.2. Referenced Identifiers		1.3.2. Referenced Identifiers
	The PSKC syntax presented in this document relies on algorithm		The PSKC syntax presented in this document relies on algorithm
	identifiers and elements defined in the XML Signature [XMLDSIG]		identifiers and elements defined in the XML Signature [XMLDSIG]
	namespace:		namespace:
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	References to the XML Signature namespace are represented by the		References to the XML Signature namespace are represented by the
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	**mandatory** XML elements and attributes. Optional elements and		**mandatory** XML elements and attributes. Optional elements and
	attributes are not explicitly indicated, i.e., if it does not say		attributes are not explicitly indicated, i.e., if it does not say
	mandatory it is optional.		mandatory it is optional.
	3. Portable Key Container Entities Overview and Relationships		3. Portable Key Container Entities Overview and Relationships
	The portable key container is based on an XML schema definition and		The portable key container is based on an XML schema definition and
	contains the following main conceptual entities:		contains the following main conceptual entities:
	1. KeyContainer entity - representing the container that carries a		1. KeyContainer entity - representing the container that carries a
	number of KeyPackages		number of KeyPackages. A valid container MUST carry at least 1
			KeyPackage.
	2. KeyPackage entity - representing the package of at most one key		2. KeyPackage entity - representing the package of at most one key
	and its related provisioning endpoint or current usage endpoint,		and its related provisioning endpoint or current usage endpoint,
	such as a physical or virtual device and a specific CryptoModule		such as a physical or virtual device and a specific CryptoModule
	3. DeviceInfo entity - representing the information about the device		3. DeviceInfo entity - representing the information about the device
	and criteria to uniquely identify the device		and criteria to uniquely identify the device
	4. 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
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 47 ¶
	<Counter>: This element contains the event counter for event		<Counter>: This element contains the event counter for event
	based OTP algorithms.		based OTP algorithms.
	<Time>: This element contains the time for time based OTP		<Time>: This element contains the time for time based OTP
	algorithms. (If time interval is used, this element carries		algorithms. (If time interval is used, this element carries
	the number of time intervals passed from a specific start		the number of time intervals passed from a specific start
	point, normally algorithm dependent).		point, normally algorithm dependent).
	<TimeInterval>: This element carries the time interval value for		<TimeInterval>: This element carries the time interval value for
	time based OTP algorithms.		time based OTP algorithms in seconds (typical value for this
			would be 30 indicating a time interval of 30 seconds).
	<TimeDrift>: This element contains the device clock drift value		<TimeDrift>: This element contains the device clock drift value
	for time-based OTP algorithms. The value indicates the number		for time-based OTP algorithms. The integer value (positive or
	of seconds that the device clock may drift each day.		negative drift) that indicates the number of time intervals
			that a validation server has established the device clock
			drifted after the last succssful authentication. So for
			example if the last successful authentication established a
			device time value of 8 intervals from a specific start date but
			the validation server determines the time value at 9 intervals,
			the server SHOULD record the drift as -1.
	All the elements listed above (and those defined in the future)		All the elements listed above (and those defined in the future)
	obey a simple structure in that they MUST support child elements		obey a simple structure in that they MUST support child elements
	to convey the data value in either plaintext or encrypted format:		to convey the data value in either plaintext or encrypted format:
	Plaintext: The <PlainValue> element carries plaintext value that		Plaintext: The <PlainValue> element carries plaintext value that
	is typed, for example to xs:integer.		is typed, for example to xs:integer.
	Encrypted: The <EncryptedValue> element carries encrypted value.		Encrypted: The <EncryptedValue> element carries encrypted value.
	skipping to change at page 13, line 8 ¶		skipping to change at page 13, line 8 ¶
	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.		device. Values for Manufacturer SHOULD be taken from [OATHMAN]
	<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 32 ¶		skipping to change at page 13, line 32 ¶
	request using a device identifier, e.g., an International Mobile		request using a device identifier, e.g., an International Mobile
	Equipment Identity (IMEI) for the phone, or an identifier for a		Equipment Identity (IMEI) for the phone, or an identifier for a
	class of identifiers, e.g., those for which the keys are protected		class of identifiers, e.g., those for which the keys are protected
	by a Trusted Platform Module (TPM).		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. Keys
			that reside on the device SHOULD only be used when the current
			date is after the <StartDate> and before the <ExpiryDate>. Note
			that usage enforcement of the keys with respective to the dates
			MAY only happen on the validation server as some devices such as
			smart cards do not have an internal clock. Systems thus SHOULD
			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.2.2. <CryptoModuleInfo> Element: CryptoModule Identification
	The <CryptoModuleInfo> element identifies the cryptographic module to		The <CryptoModuleInfo> element identifies the cryptographic module to
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 4 ¶
	'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:
	DECIMAL Only numerical digits		DECIMAL Only numerical digits
	HEXADECIMAL Hexadecimal response		HEXADECIMAL Hexadecimal response
	ALPHANUMERIC All letters and numbers (case sensitive)		ALPHANUMERIC All letters and numbers (case sensitive)
			BASE64 Base 64 encoded as defined in Section 4 of [RFC4648].
	BASE64 Base 64 encoded
	BINARY Binary data		BINARY Binary data
	'CheckDigit': This attribute indicates whether a device needs to		'CheckDigit': This attribute indicates whether a device needs to
	check the appended Luhn check digit, as defined in [LUHN],		check the appended Luhn check digit, as defined in
	contained in a challenge. This is only valid if the 'Encoding'		[ISOIEC7812], contained in a challenge. This is only valid if
	attribute is 'DECIMAL'. A value of TRUE indicates that the		the 'Encoding' attribute is 'DECIMAL'. A value of TRUE
	device will check the appended Luhn check digit in a provided		indicates that the device will check the appended Luhn check
	challenge. A value of FALSE indicates that the device will not		digit in a provided challenge. A value of FALSE indicates that
	check the appended Luhn check digit in the challenge.		the device will not check the appended Luhn check digit in the
			challenge.
	'Min': This attribute defines the minimum size of the challenge		'Min': This attribute defines the minimum size of the challenge
	accepted by the device for CR mode and MUST be included. If		accepted by the device for CR mode and MUST be included. If
	the 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or		the 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
	'ALPHANUMERIC' this value indicates the minimum number of		'ALPHANUMERIC' this value indicates the minimum number of
	digits/characters. If the 'Encoding' attribute is 'BASE64' or		digits/characters. If the 'Encoding' attribute is 'BASE64' or
	'BINARY', this value indicates the minimum number of bytes of		'BINARY', this value indicates the minimum number of bytes of
	the unencoded value.		the unencoded value.
	'Max': This attribute defines the maximum size of the challenge		'Max': This attribute defines the maximum size of the challenge
	skipping to change at page 15, line 45 ¶		skipping to change at page 15, line 48 ¶
	this element contains the format of the PIN itself (e.g., DECIMAL,		this element contains the format of the PIN itself (e.g., DECIMAL,
	length 4 for a 4 digit PIN). The following attributes are		length 4 for a 4 digit PIN). The following attributes are
	defined:		defined:
	'Encoding': This attribute defines the encoding of the response		'Encoding': This attribute defines the encoding of the response
	generated by the device, it MUST be included and MUST be one of		generated by the device, it MUST be included and MUST be one of
	the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,		the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,
	BASE64, or BINARY.		BASE64, or BINARY.
	'CheckDigit': This attribute indicates whether the device needs		'CheckDigit': This attribute indicates whether the device needs
	to append a Luhn check digit, as defined in [LUHN], to the		to append a Luhn check digit, as defined in [ISOIEC7812], to
	response. This is only valid if the 'Encoding' attribute is		the response. This is only valid if the 'Encoding' attribute
	'DECIMAL'. If the value is TRUE then the device will append a		is 'DECIMAL'. If the value is TRUE then the device will append
	Luhn check digit to the response. If the value is FALSE, then		a Luhn check digit to the response. If the value is FALSE,
	the device will not append a Luhn check digit to the response.		then the device will not append a Luhn check digit to the
			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.3. Transmission of Key Derivation Values
	skipping to change at page 21, line 30 ¶		skipping to change at page 21, line 30 ¶
	Append: This value indicates that the PIN is appended to the		Append: This value indicates that the PIN is appended to the
	algorithm response hence it MUST be checked by the party		algorithm response hence it MUST be checked by the party
	validating the response.		validating the response.
	Algorithmic: This value indicates that the PIN is used as part		Algorithmic: This value indicates that the PIN is used as part
	of the algorithm computation.		of the algorithm computation.
	'MaxFailedAttempts': This attribute indicates the maximum number		'MaxFailedAttempts': This attribute indicates the maximum number
	of times the PIN may be entered wrongly before it MUST NOT be		of times the PIN may be entered wrongly before it MUST NOT be
	possible to use the key anymore.		possible to use the key anymore (typical reasonable values are
			in the positive integer range of at least 2 and no more than
			10).
	'MinLength': This attribute indicates the minimum length of a PIN		'MinLength': This attribute indicates the minimum length of a PIN
	that can be set to protect the associated key. It MUST NOT be		that can be set to protect the associated key. It MUST NOT be
	possible to set a PIN shorter than this value. If the		possible to set a PIN shorter than this value. If the
	'PINFormat' attribute is 'DECIMAL', 'HEXADECIMAL' or		'PINFormat' attribute is 'DECIMAL', 'HEXADECIMAL' or
	'ALPHANUMERIC' this value indicates the number of digits/		'ALPHANUMERIC' this value indicates the number of digits/
	characters. If the 'PINFormat' attribute is 'BASE64' or		characters. If the 'PINFormat' 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.
	skipping to change at page 29, line 8 ¶		skipping to change at page 29, line 8 ¶
	</pskc:Key>		</pskc:Key>
	</pskc:KeyPackage>		</pskc:KeyPackage>
	</pskc:KeyContainer>		</pskc:KeyContainer>
	Figure 7: Example of a PSKC Document using Encryption based on		Figure 7: Example of a PSKC Document using Encryption based on
	Passphrase-based Keys		Passphrase-based Keys
	6.3. Encryption based on Asymmetric Keys		6.3. Encryption based on Asymmetric Keys
	When using asymmetric keys to encrypt child elements of the <Data>		When using asymmetric keys to encrypt child elements of the <Data>
	element information about the certificate being used MUST be stated		element, information about the certificate being used MUST be stated
	in the <X509Data> element, which is a child element of the		in the <X509Data> element, which is a child element of the
	<EncryptionKey> element. The encryption algorithm MUST be indicated		<EncryptionKey> element. The encryption algorithm MUST be indicated
	in the 'Algorithm' attribute of the <EncryptionMethod> element. In		in the 'Algorithm' attribute of the <EncryptionMethod> element. In
	the example shown in Figure 8 the algorithm is set to		the example shown in Figure 8 the algorithm is set to
	"http://www.w3.org/2001/04/xmlenc#rsa_1_5".		"http://www.w3.org/2001/04/xmlenc#rsa_1_5".
	<?xml version="1.0" encoding="UTF-8" ?>		<?xml version="1.0" encoding="UTF-8" ?>
	<KeyContainer		<KeyContainer
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"		xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
	skipping to change at page 36, line 12 ¶		skipping to change at page 36, line 12 ¶
	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 'Algorithm' attribute, as described in		carried inside the 'Version' attribute, as described in Section 4,
	Section 4, and rules for extensibililty are defined in Section 12.		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 37, 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
	URN: urn:ietf:params:xml:ns:keyprov:pskc#hotp		URI: urn:ietf:params:xml:ns:keyprov:pskc#hotp
	Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt		Algorithm Definition: [HOTP]
	Identifier Definition: (this RFC)		Identifier Definition: (this RFC)
	Registrant Contact: IESG		Registrant Contact: IESG
			Deprectaed: FALSE
	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.
	skipping to change at page 37, line 47 ¶		skipping to change at page 38, line 4 ¶
	+ 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. KEYPROV-PIN
	Common Name: KEYPROV-PIN		Common Name: KEYPROV-PIN
	Class: Symmetric static credential comparison		Class: Symmetric static credential comparison
	URN: urn:ietf:params:xml:ns:keyprov:pskc#pin		URI: urn:ietf:params:xml:ns:keyprov:pskc#pin
	Algorithm Definition: (this document)		Algorithm Definition: (this document)
	Identifier Definition (this document)		Identifier Definition (this document)
	Registrant Contact: IESG		Registrant Contact: IESG
			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
	skipping to change at page 46, line 17 ¶		skipping to change at page 46, line 17 ¶
	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
	MIME subtype name: pskc+xml		MIME subtype name: pskc+xml
	Mandatory parameters: none		Required parameters: There is no required parameter.
	Optional parameters: charset		Optional parameters: charset
	Indicates the character encoding of enclosed XML.		Indicates the character encoding of enclosed XML.
	Encoding considerations: Uses XML, which can employ 8-bit		Encoding considerations: Uses XML, which can employ 8-bit
	characters, depending on the character encoding used. See RFC		characters, depending on the character encoding used. See RFC
	3023 [RFC3023], Section 3.2.		3023 [RFC3023], Section 3.2.
	Security considerations: This content type is designed to carry PSKC		Security considerations: Please refer to Section 13 of RFCXXXX [NOTE
	protocol payloads.		TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of
			this specification.]
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please		Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
	replace XXXX with the RFC number of this specification.]		replace XXXX with the RFC number of this specification.]
	Applications which use this media type: This MIME type is being used		Applications which use this media type: This MIME type is being used
	as a symmetric key container format for transport and provisioning		as a symmetric key container format for transport and provisioning
	of symmetric keys (One Time Password (OTP) shared secrets or		of symmetric keys (One Time Password (OTP) shared secrets or
	symmetric cryptographic keys) to different types of strong		symmetric cryptographic keys) to different types of strong
	skipping to change at page 47, line 5 ¶		skipping to change at page 47, line 5 ¶
	systems.		systems.
	Additional information:		Additional information:
	Magic Number: None		Magic Number: None
	File Extension: .pskcxml		File Extension: .pskcxml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information: Philip Hoyer,		Personal and email address to contact for further information:
	Philip.Hoyer@actividentity.com		Philip Hoyer, Philip.Hoyer@actividentity.com
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
			Restrictions on usage: None
	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].
	skipping to change at page 48, line 42 ¶		skipping to change at page 48, line 42 ¶
	As part of this registry IANA will maintain the following		As part of this registry IANA will maintain the following
	information:		information:
	Common Name: The name by which the PSKC algorithm profile is		Common Name: The name by which the PSKC algorithm profile is
	generally referred.		generally referred.
	Class: The type of PSKC algorithm profile registry entry being		Class: The type of PSKC algorithm profile registry entry being
	created, such as encryption, Message Authentication Code (MAC),		created, such as encryption, Message Authentication Code (MAC),
	One Time Password (OTP), Digest.		One Time Password (OTP), Digest.
	URN: The URN to be used to identify the profile.		URI: The URI to be used to identify the profile.
	Identifier Definition: IANA will be asked to add a pointer to the		Identifier Definition: IANA will be asked to add a pointer to the
	specification containing information about the PSKC algorithm		specification containing information about the PSKC algorithm
	profile registration.		profile registration.
	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.
			Deprecated: TRUE if based on expert approval this entry has been
			deprecated and SHOULD not be used in any new implementations.
			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		Expert Review as per RFC 5226 [RFC5226]. Updates can be provided
	based on expert approval only. Based on expert approval, it is		based on expert approval only. Based on expert approval, it is
	possible to mark entries as "deprecated". A designated expert will		possible to mark entries as "deprecated". A designated expert will
	be appointed by the IESG.		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
	skipping to change at page 50, line 4 ¶		skipping to change at page 50, line 19 ¶
	| 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. A designated expert will be		modify existing key usage tokens. A designated expert will be
	appointed by the IESG.		appointed by the IESG.
	13. Security Considerations		13. Security Considerations
	The portable key container carries sensitive information (e.g.,		The portable symmetric key container (PSKC) carries sensitive
	cryptographic keys) and may be transported across the boundaries of		information (e.g., cryptographic keys) and may be transported across
	one secure perimeter to another. For example, a container residing		the boundaries of one secure perimeter to another. For example, a
	within the secure perimeter of a back-end provisioning server in a		container residing within the secure perimeter of a back-end
	secure room may be transported across the internet to an end-user		provisioning server in a secure room may be transported across the
	device attached to a personal computer. This means that special care		internet to an end-user device attached to a personal computer. This
	must be taken to ensure the confidentiality, integrity, and		means that special care MUST be taken to ensure the confidentiality,
	authenticity of the information contained within.		integrity, and authenticity of the information contained within.
	13.1. Payload Confidentiality		13.1. PSKC 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 key data payload encryption.
	cryptographic cipher should be used - the longer the cryptographic		Symmetric cryptographic cipher SHOULD be used - the longer the
	key, the stronger the protection. Please see Section 6.1 for		cryptographic key, the stronger the protection. Please see
	recommendations of payload protection using symmetric cryptographic		Section 6.1 for recommendations of key data payload protection using
	ciphers. In cases where the exchange of key encryption keys between		symmetric cryptographic ciphers. In cases where the exchange of key
	the sender and the receiver is not possible, asymmetric encryption of		encryption keys between the sender and the receiver is not possible,
	the secret key payload may be employed, see Section 6.3 . Similarly		asymmetric encryption of the key data payload may be employed, see
	to symmetric key cryptography, the stronger the asymmetric key, the		Section 6.3 . Similarly to symmetric key cryptography, the stronger
	more secure the protection is.		the asymmetric key, the more secure the protection is.
	If the payload is encrypted with a method that uses one of the		If the key data payload is encrypted with a method that uses one of
	password-based encryption methods provided above, the payload may be		the password-based encryption methods (PBE methods) detailed in
	subjected to password dictionary attacks to break the encryption		Section 6.2, the key data payload may be subjected to password
	password and recover the information. Standard security best		dictionary attacks to break the encryption password and recover the
	practices for selection of strong encryption passwords apply.		information. Standard security best practices for selection of
			strong encryption passwords apply.
	Practical implementations should use PBESalt and PBEIterationCount		Additionally, it is strongly RECOMMENDED that practical
	when PBE encryption is used. Different PBESalt value per key		implementations use PBESalt and PBEIterationCount when PBE encryption
	container should be used for best protection.		is used. A different PBESalt value per PSKC SHOULD be used for best
			protection.
	The second approach to protecting the confidentiality of the payload		The second approach to protecting the confidentiality of the key data
	is based on using transport layer security. The secure channel		payload is based on using transport layer security. The secure
	established between the source secure perimeter (the provisioning		channel established between the source secure perimeter (the
	server from the example above) and the target perimeter (the device		provisioning server from the example above) and the target perimeter
	attached to the end-user computer) utilizes encryption to transport		(the device attached to the end-user computer) utilizes encryption to
	the messages that travel across. No payload encryption is required		transport the messages that travel across. No key data payload
	in this mode. Secure channels that encrypt and digest each message		encryption is required in this mode. Secure channels that encrypt
	provide an extra measure of security, especially when the signature		and digest each message provide an extra measure of security.
	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 PSKC is protected only by the
	the transport layer security, practical implementation must ensure		transport layer security, practical implementation MUST ensure
	protection against man-in-the-middle attacks. Validating the secure		protection against man-in-the-middle attacks. Authenticating the
	channel end-points is critically important for eliminating intruders		secure channel end-points is critically important for eliminating
	that may compromise the confidentiality of the payload.		intruders that may compromise the confidentiality of the PSKC.
	13.2. Payload Integrity		13.2. PSKC Integrity
	The portable symmetric key container provides a mean to guarantee the		The PSKC provides a mean to guarantee the integrity of the
	integrity of the information it contains through digital signatures.		information it contains through digital signatures. It is
	For best security practices, the digital signature of the container		RECOMMENDED that for best security practices, the digital signature
	should encompass the entire payload. This provides assurances for		of the container encompasses the entire PSKC.This provides assurances
	the integrity of all attributes. It also allows verification of the		for the integrity of all attributes. It also allows verification of
	integrity of a given payload even after the container is delivered		the integrity of a given PSKC 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. PSKC Authenticity
	The digital signature of the payload is the primary way of showing		The digital signature of the PSKC is the primary way of showing its
	its authenticity. The recipient of the container may 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 payload can be checked even		Note that the digital signature of the PSKC can be checked even after
	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		A weaker payload authenticity guarantee may be provided by the
	transport layer if it is configured to digest each message it		transport layer if it is configured to digest each message it
	transports. However, no authenticity verification is possible once		transports. However, no authenticity verification is possible once
	the container is delivered at the recipient end. This approach may		the container is delivered at the recipient end. This approach may
	be useful in cases where the digital signature of the container does		be useful in cases where the digital signature of the container does
	not encompass the entire payload.		not encompass the entire 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 9 ¶		skipping to change at page 55, line 9 ¶
	computation.		computation.
	This work is based on earlier work by the members of OATH (Initiative		This work is based on earlier work by the members of OATH (Initiative
	for Open AuTHentication), see [OATH], to specify a format that can be		for Open AuTHentication), see [OATH], to specify a format that can be
	freely distributed to the technical community.		freely distributed to the technical community.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
			[AESKWPAD]
			Housley, R. and M. Dworkin, "Advanced Encryption Standard
			(AES) Key Wrap with Padding Algorithm", March 2009, <http:
			//www.ietf.org/internet-drafts/
			draft-housley-aes-key-wrap-with-pad-02.txt>.
			[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
			O. Ranen, "HOTP: An HMAC-Based One Time Password
			Algorithm", RFC 4226, December 2005.
			[ISOIEC7812]
			ISO, "ISO/IEC 7812-1:2006 Identification cards --
			Identification of issuers -- Part 1: Numbering system",
			October 2006, <http://www.iso.org/iso/iso_catalogue/
			catalogue_tc/catalogue_detail.htm?csnumber=39698>.
			[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)",
			April 2009,
			<http://www.openauthentication.org/oath-id/prefixes/>.
	[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography		[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
	Standard", Version 2.0,		Standard", Version 2.0,
	URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.		URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[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.
			[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
			Encodings", RFC 4648, October 2006.
	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,		URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
	W3C Recommendation, February 2002.		W3C Recommendation, February 2002.
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/,		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
	Version 1.1.",		Version 1.1.",
	URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730,		URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730,
	W3C Recommendation, July 2009.		W3C Recommendation, July 2009.
	16.2. Informative References		16.2. Informative References
	[AESKWPAD]
	Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", March 2009, <http:
	//www.ietf.org/internet-drafts/
	draft-housley-aes-key-wrap-with-pad-02.txt>.
	[CAP] MasterCard International, "Chip Authentication Program		[CAP] MasterCard International, "Chip Authentication Program
	Functional Architecture", September 2004.		Functional Architecture", September 2004.
	[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,		[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
	"Dynamic Symmetric Key Provisioning Protocol", Internet		"Dynamic Symmetric Key Provisioning Protocol", Internet
	Draft Informational, URL: http://www.ietf.org/		Draft Informational, URL: http://www.ietf.org/
	internet-drafts/draft-ietf-keyprov-dskpp-07.txt,		internet-drafts/draft-ietf-keyprov-dskpp-07.txt,
	February 2009.		February 2009.
	[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
	O. Ranen, "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226, December 2005.
	[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
	August 1960, <http://patft.uspto.gov/netacgi/
	nph-Parser?patentnumber=2950048>.
	[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]
	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://www.ietf.org/id/
	draft-hoyer-keyprov-pskc-algorithm-profiles-00,		draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt,
	December 2008.		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.
	[XMLNS] "Namespaces in XML", W3C Recommendation ,		[XMLNS] "Namespaces in XML", W3C Recommendation ,
End of changes. 58 change blocks.
	138 lines changed or deleted		185 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/