Diff: draft-ietf-keyprov-pskc-03.txt - draft-ietf-keyprov-pskc-04.txt

draft-ietf-keyprov-pskc-03.txt	draft-ietf-keyprov-pskc-04.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: December 11, 2009 VeriSign	Expires: April 26, 2010 VeriSign
S. Machani	S. Machani
Diversinet	Diversinet
June 9, 2009	October 23, 2009
Portable Symmetric Key Container (PSKC)	Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-03	draft-ietf-keyprov-pskc-04
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 December 11, 2009.	This Internet-Draft will expire on April 26, 2010.
Copyright Notice	Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the	Copyright (c) 2009 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
This document specifies a symmetric key format for transport and	This document specifies a symmetric key format for transport and
provisioning of symmetric keys to different types of crypto modules.	provisioning of symmetric keys to different types of crypto modules.
For example One Time Password (OTP) shared secrets or symmetric	For example, One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. The standard	cryptographic keys to strong authentication devices. A standard key
key transport format enables enterprises to deploy best-of-breed	transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same	solutions combining components from different vendors into the same
infrastructure.	infrastructure.
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
skipping to change at page 4, line 12 ¶	skipping to change at page 4, line 12 ¶
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 authentication
such as those based on one-time-password (OTP) and challenge response	such as those based on one-time-password (OTP) and challenge response
(CR) mechanisms, there is a need for vendor interoperability and a	(CR) mechanisms, there is a need for vendor interoperability and a
standard format for importing and exporting (provisioning) symmetric	standard format for importing and exporting (provisioning) symmetric
keys. Traditionally, for example vendors of authentication servers	keys. Traditionally, for example, vendors of authentication servers
and service providers have used proprietary formats for importing and	and service providers have used proprietary formats for importing and
exporting these keys into their systems, thus making it hard to use	exporting these keys into their systems, thus making it hard to use
tokens from vendor "Foo" with a server from vendor "Bar".	tokens from vendor "Foo" with a server from vendor "Bar".
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 may be 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 a IANA registry for algorithm profiles where	requests the creation of an IANA registry for algorithm profiles
algorithms, their related meta-data and PSKC transmission profile can	where algorithms, their related meta-data and PSKC transmission
be recorded for centralised standardised reference.	profile can 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 [RFC2396] 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 5, line 25 ¶	skipping to change at page 5, line 25 ¶
PSKC also relies on algorithm identifiers and elements defined in the	PSKC also relies on algorithm identifiers and elements defined in the
XML Encryption [XMLENC] namespace:	XML Encryption [XMLENC] namespace:
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the	References to the XML Encryption namespace are represented by the
prefix "xenc".	prefix "xenc".
When protecting keys in transport with passphrase-based keys, PSKC	When protecting keys in transport with passphrase-based keys, PSKC
also relies on the derived key element defined in the W3C Derived Key	also relies on the derived key element defined in the XML Encryption
[W3C-DKEY] namespace:	Version 1.1 [XMLENC11] namespace:
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"	xmlns:xenc11="http://www.w3.org/2009/xmlenc11#""
References to the W3C Derived Key namespace are represented by the	References to the XML Encryption Version 1.1 namespace are
prefix "dkey".	represented by the prefix "xenc11".
When protecting keys in transport with passphrase-based keys, PSKC	When protecting keys in transport with passphrase-based keys, PSKC
also relies on algorithm identifiers and elements defined in the	also relies on algorithm identifiers and elements defined in the
PKCS#5 [PKCS5] namespace:	PKCS#5 [PKCS5] namespace:
xmlns:pkcs5=	xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
References to the PKCS#5 namespace are represented by the prefix	References to the PKCS#5 namespace are represented by the prefix
"pkcs5".	"pkcs5".
skipping to change at page 7, line 13 ¶	skipping to change at page 7, line 13 ¶
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
2. KeyPackage entity - representing the package of upmost 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
5. Key entity - representing the key transported or provisioned	5. Key entity - representing the key transported or provisioned
skipping to change at page 9, line 21 ¶	skipping to change at page 9, line 21 ¶
The following example shows such a simple PSKC document. We will use	The following example shows such a simple PSKC document. We will use
it to describe the structure of the <KeyContainer> element and its	it to describe the structure of the <KeyContainer> element and its
child elements.	child elements.
<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"	<KeyContainer Version="1.0"
Id="exampleID1"	Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">	xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>	<KeyPackage>
<Key Id="12345678"	<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer-A</Issuer>	<Issuer>Issuer-A</Issuer>
<Data>	<Data>
<Secret>	<Secret>
<PlainValue>MTIzNA==	<PlainValue>MTIzNA==
</PlainValue>	</PlainValue>
</Secret>	</Secret>
</Data>	</Data>
</Key>	</Key>
</KeyPackage>	</KeyPackage>
</KeyContainer>	</KeyContainer>
Figure 2: Basic PSKC Key Container Example	Figure 2: Basic PSKC Key Container Example
The attributes of the <KeyContainer> element have the following	The attributes of the <KeyContainer> element have the following
semantics:	semantics:
'Version:' The 'Version' attribute is used to identify the version	'Version:' The 'Version' attribute is used to identify the version
of the PSKC schema version. This specification defines the	of the PSKC schema version. This specification defines the
initial version ("1.0") of the PSKC schema. This attribute is	initial version ("1.0") of the PSKC schema. This attribute MUST
mandatory.	be included.
'Id:' The 'Id' attribute carries a unique identifier for the	'Id:' The 'Id' attribute carries a unique identifier for the
container. As such, it helps to identify a specific key container	container. As such, it helps to identify a specific key container
in cases when multiple containers are embedded in larger xml	in cases when multiple containers are embedded in larger xml
documents.	documents.
4.1. <Key>: Embedding Keying Material and Key Related Information	4.1. <Key>: Embedding Keying Material and Key Related Information
The following attributes of the <Key> element MUST be included at a	The following attributes of the <Key> element MUST be included at a
minimum:	minimum:
'Id': This attribute carries a globally unique identifier for the	'Id': This attribute carries a globally unique identifier for the
symmetric key. The identifier is defined as a string of	symmetric key. The identifier is defined as a string of
alphanumeric characters.	alphanumeric characters.
'Algorithm': This attribute contains a unique identifier for the	'Algorithm': This attribute contains a unique identifier for the
PSKC algorithm profile. This profile associates specific	PSKC algorithm profile. This profile associates specific
semantics to the elements and attributes contained in the <Key>	semantics to the elements and attributes contained in the <Key>
element. This document describes profiles for open standards	element. This document describes profiles for open standards
algorithms in Section 10. Additional profiles are defined in the	algorithms in Section 10. Additional profiles are defined in the
following information draft [PSKC-ALGORITHM-PROFILES]	following information draft [PSKC-ALGORITHM-PROFILES].
The <Key> element has a number of optional child elements. An	The <Key> element has a number of optional child elements. An
initial set is described below:	initial set is described below:
<Issuer>: This element represents the name of the party that issued	<Issuer>: This element represents the name of the party that issued
the key. For example, a bank "Foobar Bank Inc." issuing hardware	the key. For example, a bank "Foobar Bank Inc." issuing hardware
tokens to their retail banking users may set this element to	tokens to their retail banking users may set this element to
"Foobar Bank Inc.".	"Foobar Bank Inc.".
<FriendlyName>: A human readable name for the secret key for easier	<FriendlyName>: A human readable name for the secret key for easier
skipping to change at page 10, line 44 ¶	skipping to change at page 10, line 44 ¶
<Secret>: This element carries the value of the key itself in a	<Secret>: This element carries the value of the key itself in a
binary representation.	binary representation.
<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.
<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 value indicates the number
of seconds that the device clock may drift each day.	of seconds that the device clock may drift each day.
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.
Additionally, it MUST be possible to carry a <ValueMac> element,	ValueMAC: The <ValueMAC> element is populated with a MAC
which is populated with a MAC generated from the encrypted value	generated from the encrypted value in case the encryption
in case the encryption algorithm does not support integrity	algorithm does not support integrity checks. The example shown
checks, as a child element. The example shown at Figure 2	at Figure 2 illustrates the usage of the <Data> element with
illustrates the usage of the <Data> element with two child	two child elements, namely <Secret> and <Counter>. Both
elements, namely <Secret> and <Counter>. Both elements carry	elements carry plaintext value within the <PlainValue> child
plaintext value within the <PlainValue> child element.	element.
4.2. Transmission of supplementary Information	4.2. Transmission of supplementary Information
A PSKC document can contain a number of additional information	A PSKC document can contain a number of additional information
regarding device identification, cryptomodule identification, user	regarding device identification, cryptomodule identification, user
identification and parameters for usage with OTP and CR algorithms.	identification and parameters for usage with OTP and CR algorithms.
The following example, see Figure 3, is used as a reference for the	The following example, see Figure 3, is used as a reference for the
subsequent sub-sections.	subsequent sub-sections.
<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 13, line 19 ¶	skipping to change at page 13, line 19 ¶
<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.
<DeviceBinding>: In a number of cases access to lower layer device	<DeviceBinding>: This element allows a provisioning server to ensure
identifiers, such as a serial number, from a PSKC implementation	that the key is going to be loaded into the device for which the
is difficult or impossible. For this purpose an opaque	key provisioning request was approved. The device is bound to the
identifier, carried in the <DeviceBinding> element, is introduced	request using a device identifier, e.g., an IMEI for the phone, or
that allows to bind keys to the device or to a class of devices.	an identifier for a class of identifiers, e.g., those for which
When loading keys into a device, the value of the <DeviceBinding>	the keys are protected by a TPM.
element MUST be checked against information provided to the user
via out-of-band mechanisms. The implementation then ensures that
the correct device or class of device is being used with respect
to the provisioned key.
<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
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
which the symmetric keys are or have been provisioned to. This	which the symmetric keys are or have been provisioned to. This
allows the identification of the specific cases where a device MAY	allows the identification of the specific cases where a device MAY
contain more than one crypto module (e.g. a PC hosting a TPM and a	contain more than one crypto module (e.g. a PC hosting a TPM and a
connected token)	connected token).
The <CryptoModuleInfo> element has a single mandatory child element:	The <CryptoModuleInfo> element has a single child element that MUST
be included:
<Id>: This element carries a unique identifier for the CryptoModule	<Id>: This element carries a unique identifier for the CryptoModule
and is implementation specific. As such, it helps to identify a	and is implementation specific. As such, it helps to identify a
specific CryptoModule to which the key is being or was	specific CryptoModule to which the key is being or was
proivisioned.	proivisioned.
4.2.3. <UserId> Element: User Identification	4.2.3. <UserId> Element: User Identification
The <UserId> element identifies the user using a distinguished name,	The <UserId> element identifies the user using a distinguished name,
as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net	as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net.
Although the syntax of the user identifier is defined there are no	Although the syntax of the user identifier is defined, there are no
semantics associated with this element, i.e., there are no checks	semantics associated with this element, i.e., there are no checks
enforcing that only a specific user can use this key. As such, this	enforcing that only a specific user can use this key. As such, this
element is for informational purposes only.	element is for informational purposes only.
This element may appear in two places, namely as a child element of	This element may appear in two places, namely as a child element of
the <Key> element where it indicates the user with whom the key is	the <Key> element where it indicates the user with whom the key is
associated with and as a child element of the <DeviceInfo> element	associated with and as a child element of the <DeviceInfo> element
where it indicates that the entity the device belongs to.	where it indicates the user the device is associated with.
4.2.4. <AlgorithmParameters> Element: Supplementary Information for OTP	4.2.4. <AlgorithmParameters> Element: Supplementary Information for OTP
and CR Algorithms	and CR Algorithms
The <AlgorithmParameters> element is a child element of the <Key>	The <AlgorithmParameters> element is a child element of the <Key>
element and this document defines two child elements:	element and this document defines two child elements:
<ChallengeFormat> and <ResponseFormat>	<ChallengeFormat> and <ResponseFormat>
<ChallengeFormat>:	<ChallengeFormat>:
The <ChallengeFormat> element defines the characteristics of the	The <ChallengeFormat> element defines the characteristics of the
challenge in a CR usage scenario whereby the following attributes	challenge in a CR usage scenario whereby the following attributes
are defined:	are defined:
'Encoding': This mandatory attribute defines the encoding of the	'Encoding': This attribute, which MUST be included, defines the
challenge accepted by the device and MUST be one of the	encoding of the challenge accepted by the device and MUST be
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	BASE64 Base 64 encoded
BINARY Binary data	BINARY Binary data
'CheckDigit': This optional attribute indicates whether a device	'CheckDigit': This attribute indicates whether a device needs to
needs to check the appended Luhn check digit, as defined in	check the appended Luhn check digit, as defined in [LUHN],
[LUHN], contained in a challenge. This is only valid if the	contained in a challenge. This is only valid if the 'Encoding'
'Encoding' attribute is 'DECIMAL'. A value of TRUE indicates	attribute is 'DECIMAL'. A value of TRUE indicates that the
that the device will check the appended Luhn check digit in a	device will check the appended Luhn check digit in a provided
provided challenge. A value of FALSE indicates that the device	challenge. A value of FALSE indicates that the device will not
will not check the appended Luhn check digit in the challenge.	check the appended Luhn check digit in the challenge.
'Min': This mandatory attribute defines the minimum size of the	'Min': This attribute defines the minimum size of the challenge
challenge accepted by the device for CR mode. If the	accepted by the device for CR mode and MUST be included. If
'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 mandatory attribute defines the maximum size of the	'Max': This attribute defines the maximum size of the challenge
challenge accepted by the device for CR mode. If the	accepted by the device for CR mode and MUST be included. If
'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or	the 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the maximum number of	'ALPHANUMERIC' this value indicates the maximum 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 maximum number of bytes of	'BINARY', this value indicates the maximum number of bytes of
the unencoded value.	the unencoded value.
<ResponseFormat>:	<ResponseFormat>:
The <ResponseFormat> element defines the characteristics of the	The <ResponseFormat> element defines the characteristics of the
result of a computation and defines the format of the OTP or the	result of a computation and defines the format of the OTP or the
response to a challenge. For cases where the key is a PIN value,	response to a challenge. For cases where the key is a PIN value,
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 mandatory attribute defines the encoding of the	'Encoding': This attribute defines the encoding of the response
response generated by the device and MUST be one of the	generated by the device, it MUST be included and MUST be one of
following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,	the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,
or BINARY.	BASE64, or BINARY.
'CheckDigit': This optional attribute indicates whether the	'CheckDigit': This attribute indicates whether the device needs
device needs to append a Luhn check digit, as defined in	to append a Luhn check digit, as defined in [LUHN], to the
[LUHN], to the response. This is only valid if the 'Encoding'	response. This is only valid if the 'Encoding' attribute is
attribute is 'DECIMAL'. If the value is TRUE then the device	'DECIMAL'. If the value is TRUE then the device will append a
will append a Luhn check digit to the response. If the value	Luhn check digit to the response. If the value is FALSE, then
is FALSE, then the device will not append a Luhn check digit to	the device will not append a Luhn check digit to the response.
the response.
'Length': This mandatory attribute defines the length of the	'Length': This attribute defines the length of the response
response generated by the device. If the 'Encoding' attribute	generated by the device and MUST be included. If the
is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value	'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
indicates the number of digits/characters. If the 'Encoding'	'ALPHANUMERIC' this value indicates the number of digits/
attribute is 'BASE64' or 'BINARY', this value indicates the	characters. If the 'Encoding' attribute is 'BASE64' or
number of bytes of the unencoded value.	'BINARY', this value indicates the number of bytes of the
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 attributes
present on a smart card application that have influence when	present on a smart card application that have influence when
computing a response.) Likewise, the sending and receiving parties,	computing a response.).
might agree to a set of values related to the MasterCard's Chip
Authentication Protocol [CAP].
For example, sending and receiving party would agree that	For example, in the case of MasterCard's Chip Authentication Program
KeyProfileId='1' would represent a certain set of values (e.g.,	[CAP], sending and receiving party would agree that KeyProfileId='1'
Internet authentication flag set to a specific value). When sending	represents a certain set of values (e.g., Internet Authentication
keys these values would not be transmitted as key attributes but only	Flag IAF set to a specific value). During transmission of the
referred to via the <KeyProfileId> element set to the specific agreed	KeyContainer, these values would not be transmitted as key attributes
profile (in this case '1'). When the receiving party receives the	but only referred to via the <KeyProfileId> element set to the
keys it can then associate all relevant key attributes contained in	specific agreed profile (in this case '1'). The receiving party can
the out of band agreed profile with the imported keys. Often this	then associate all relevant key attributes contained in the out of
methodology is used between the manufacturing and the validation	band agreed profile with the imported keys. Often this methodology
service to avoid repeated transmission of the same set of values.	is used between a manufacturing service, run by company A and the
validation service 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 is	be used with a key derivation scheme and no specific key value
transported but only the reference to the external key is used (e.g.,	(secret) is transported but only the reference to the external master
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"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">	Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>	<Issuer>Issuer</Issuer>
<AlgorithmParameters>	<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>	<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>	</AlgorithmParameters>
<KeyProfileId>keyProfile1</KeyProfileId>	<KeyProfileId>keyProfile1</KeyProfileId>
<KeyReference>MasterKeyLabel
</KeyReference>
<Data>	<Data>
<Counter>	<Counter>
<PlainValue>0</PlainValue>	<PlainValue>0</PlainValue>
</Counter>	</Counter>
</Data>	</Data>
<Policy>	<Policy>
<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 <SerialNumber>	The key value will be derived using the value of the <SerialNo>
element and an external key identified by the label 'MasterKeyLabel'.	element, values agreed between sending and receiving parties and
identified by the KeyProfile 'keyProfile1' and an external agreed key
referenced by the label 'MasterKeyLabel'.
5. Key policy - transmission of key usage policies and key PIN	5. Key policy - transmission of key usage policies and key PIN
protection 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 policy to be attached to a key and its
related meta data. This element is a child element of the <Key>	related meta data. This element is a child element of the <Key>
element.	element.
If the <Policy> element contains child elements or values within	If the <Policy> element contains child elements or values within
skipping to change at page 19, line 47 ¶	skipping to change at page 19, line 47 ¶
period of a key. It MUST be ensured that the key is only used	period of a key. It MUST be ensured that the key is only used
between the start and the end date (inclusive). The value MUST be	between the start and the end date (inclusive). The value MUST be
expressed in UTC form, with no time zone component.	expressed in UTC form, with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than	Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap	milliseconds and MUST NOT generate time instants that specify leap
seconds. When this element is absent the current time is assumed	seconds. When this element is absent the current time is assumed
as the start time.	as the start time.
<NumberOfTransactions>: The value in this element indicates the	<NumberOfTransactions>: The value in this element indicates the
maximum number of times a key carried within the PSKC document can	maximum number of times a key carried within the PSKC document can
be used. When this element is omitted then there is no	be used by an application after having received it.. When this
restriction regarding the number of times a key can be used.	element is omitted then there is no restriction regarding the
number of times a key can be used.
<KeyUsage>: The <KeyUsage> element puts constraints on the intended	<KeyUsage>: The <KeyUsage> element puts constraints on the intended
usage of the key. The recipient of the PSKC document MUST enforce	usage of the key. The recipient of the PSKC document MUST enforce
the key usage. Currently, the following tokens are registered by	the key usage. Currently, the following tokens are registered by
this document:	this document:
OTP: The key MUST only be used for OTP generation.	OTP: The key MUST only be used for OTP generation.
CR: The key MUST only be used for Challenge/Response purposes.	CR: The key MUST only be used for Challenge/Response purposes.
Encrypt: The key MUST only be used for data encryption purposes.	Encrypt: The key MUST only be used for data encryption purposes.
Integrity: The key MUST only be used to generate a keyed message	Integrity: The key MUST only be used to generate a keyed message
digest for data integrity or authentication purposes.	digest for data integrity or authentication purposes.
Verify: The key MUST only be used to verify a keyed message	Verify: The key MUST only be used to verify a keyed message
digest for data integrity or authentication purposes. ( is the	digest for data integrity or authentication purposes. (this is
vice versa of Integrity)	the vice versa of Integrity)
Unlock: The key MUST only be used for an inverse challenge	Unlock: The key MUST only be used for an inverse challenge
response in the case where a user has locked the device by	response in the case where a user has locked the device by
entering a wrong PIN too many times (for devices with PIN-input	entering a wrong PIN too many times (for devices with PIN-input
capability).	capability).
Decrypt: The key MUST only be used for data decryption purposes.	Decrypt: The key MUST only be used for data decryption purposes.
KeyWrap: The key MUST only be used for key wrap purposes.	KeyWrap: The key MUST only be used for key wrap purposes.
skipping to change at page 21, line 18 ¶	skipping to change at page 21, line 18 ¶
'PINUsageMode': This mandatory attribute indicates the way the	'PINUsageMode': This mandatory attribute indicates the way the
PIN is used during the usage of the key. The following values	PIN is used during the usage of the key. The following values
are defined:	are defined:
Local: This value indicates that the PIN is checked locally on	Local: This value indicates that the PIN is checked locally on
the device before allowing the key to be used in executing	the device before allowing the key to be used in executing
the algorithm.	the algorithm.
Prepend: This value indicates that the PIN is prepended to the	Prepend: This value indicates that the PIN is prepended to the
OTP or response hence it MUST be checked by the validation	algorithm response hence it MUST be checked by the party
server.	validating the response.
Append: This value indicates that the PIN is appended to the	Append: This value indicates that the PIN is appended to the
OTP or response hence it MUST be checked by the validation	algorithm response hence it MUST be checked by the party
server.	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.
'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.
'MaxLength': This attribute indicates the maximum lenght of a PIN	'MaxLength': This attribute indicates the maximum length of a PIN
that can be set to protect this key. It MUST NOT be possible	that can be set to protect this key. It MUST NOT be possible
to set a PIN longer than this value. If the 'PINFormat'	to set a PIN longer than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this	attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
value indicates the number of digits/characters. If the	value indicates the number of digits/characters. If the
'PINFormat' attribute is 'BASE64' or 'BINARY', this value	'PINFormat' attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value.	indicates the number of bytes of the unencoded value.
'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.
skipping to change at page 23, line 15 ¶	skipping to change at page 23, line 15 ¶
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.	and asymmetric keys. When encryption algorithms are used that make
use of Initialisation Vectors (IV), for example AES128-CBC, then a
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
[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 "Example-Key1", 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'.
Since AES128-CBC does not provide integrity checks a keyed MAC is
The IV for the MAC key is '11223344556677889900112233445566' and the
IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
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 use as the algorithm	"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the
and the value of the MAC key is randomly generated, in our case	algorithm and the value of the MAC key is randomly generated, in our
'1122334455667788990011223344556677889900', and encrypted with the	case '1122334455667788990011223344556677889900', and encrypted with
above encryption key.) The result of the keyed MAC computation is	the above encryption key). The result of the keyed MAC computation
placed in the <ValueMAC> child element of <Secret>.	is placed in the <ValueMAC> child element of <Secret>.
<?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"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>	<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>	<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>	</EncryptionKey>
<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">	<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<MACKey>	<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>
R8+5I6m74doa0nRhaPejbt3elq9hLPGvxHgXVlYpbgA=	ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX
</xenc:CipherValue>	</xenc:CipherValue>
</xenc:CipherData>	</xenc:CipherData>
</MACKey>	</MACKey>
</MACMethod>	</MACMethod>
<KeyPackage>	<KeyPackage>
<DeviceInfo>	<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>	<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>	<SerialNo>987654321</SerialNo>
</DeviceInfo>	</DeviceInfo>
<CryptoModuleInfo>	<CryptoModuleInfo>
<Id>CM_ID_001</Id>	<Id>CM_ID_001</Id>
</CryptoModuleInfo>	</CryptoModuleInfo>
skipping to change at page 24, line 28 ¶	skipping to change at page 24, line 35 ¶
<AlgorithmParameters>	<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>	<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>	</AlgorithmParameters>
<Data>	<Data>
<Secret>	<Secret>
<EncryptedValue>	<EncryptedValue>
<xenc:EncryptionMethod	<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>	Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>	<xenc:CipherData>
<xenc:CipherValue>	<xenc:CipherValue>
pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=	AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
</xenc:CipherValue>	</xenc:CipherValue>
</xenc:CipherData>	</xenc:CipherData>
</EncryptedValue>	</EncryptedValue>
<ValueMAC>ooo0Swn6s/myD4o05FCfBHN0560=</ValueMAC>	<ValueMAC>aSRlEG1agUo0CS2dt/OvIAqQ6Co=
</ValueMAC>
</Secret>	</Secret>
<Counter>	<Counter>
<PlainValue>0</PlainValue>	<PlainValue>0</PlainValue>
</Counter>	</Counter>
</Data>	</Data>
</Key>	</Key>
</KeyPackage>	</KeyPackage>
</KeyContainer>	</KeyContainer>
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key	Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
When protecting the payload with pre-shared keys implementations MUST	When protecting the payload with pre-shared keys implementations MUST
set the name of the specific pre-shared key in the <KeyName> element	set the name of the specific pre-shared key in the <KeyName> element
inside the <EncryptionKey> element. When the encryption method uses	inside the <EncryptionKey> element. When the encryption method uses
a CBC mode that requires an explicit initialization vector (IV), the	a CBC mode that requires an explicit initialization vector (IV), the
IV MUST be passed by prepending it to the encrypted value.	IV MUST be passed by prepending it to the encrypted value.
For systems implementing PSKC it is RECOMMENDED to support AES-128-	For systems implementing PSKC it is RECOMMENDED to support AES-128-
CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and	CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and
KW-AES128 (with the URI of	KW-AES128 (with the URI of
http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-	http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-
skipping to change at page 25, line 44 ¶	skipping to change at page 26, line 6 ¶
between the receiver and the sender, or one set by an application	between the receiver and the sender, or one set by an application
protocol that uses KeyContainer. It is recommended that a sender	protocol that uses KeyContainer. It is recommended that a sender
generates a random MAC key. When the sender generates such a random	generates a random MAC key. When the sender generates such a random
MAC key, the MAC key material MUST be encrypted with the same	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. Implementations of PSKC MUST support HMAC-SHA1 (with the URI of	key. For systems implementing PSKC it is RECOMMENDED to implement
http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-	the HMAC-SHA1 (with the URI of
implement MAC algorithm. Some of the MAC algorithms that can	'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC
optionally be implemented are:	algorithms that can optionally be implemented are:
Algorithm | Uniform Resource Locator (URL)	Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------	---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256	HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384	HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512	HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
6.2. Encryption based on Passphrase-based Keys	6.2. Encryption based on Passphrase-based Keys
Figure 7 shows an example that illustrates the encryption of the	Figure 7 shows an example that illustrates the encryption of the
content of the <Secret> element using passphrase based encryption	content of the <Secret> element using passphrase based key derivation
PBES2 as defined in [PKCS5]. When using passphrase based encryption,	(PBKDF2) to derive the encryption key as defined in [PKCS5]. When
the <DerivedKey> element defined in W3C [W3C-DKEY] MUST be used to	using passphrase based key derivation, the <DerivedKey> element
specify the passphrased-based key. A <DerivedKey> element is set as	defined in XML Encryption v1.1 [XMLENC11] MUST be used to specify the
the child element of <EncryptionKey> element of the key container.	passphrased-based key. A <DerivedKey> element is set as the child
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, namely	function and related parameters. The encryption algorithm, in this
PBES2 as specified in [PKCS5] ( URI	example AES-128-CBC ( URI
'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2'), MUST	'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the
be set in the 'Algorithm' attribute of <EncryptionMethod> element	'Algorithm' attribute of <EncryptionMethod> element used inside the
used inside the encrypted data elements.	encrypted data elements.
When PBKDF2 is used, the attribute "Algorithm" of the element <dkey:	When PBKDF2 is used, the attribute "Algorithm" of the element
KeyDerivationMethod> MUST be set to the URI	<xenc11:KeyDerivationMethod> 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 <dkey:KeyDerivationMethod> MUST include the <PBKDF2-params>	element <xenc11:KeyDerivationMethod> 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 PBES2 is used for encryption, the URL
'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2' MUST
be specified as the 'Algorithm' attribute of <xenc:EncryptionMethod>
element. The underlying encryption scheme MUST be expressed in the
<pskc:EncryptionScheme> element, which is a child element of <xenc:
EncryptionMethod>.
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.
When PKCS#5 password based encryption is used, the <EncryptionKey>
element and <xenc:EncryptionMethod> element MUST be used in exactly
the form as shown in Figure 7.
In the example below, the following data is used.	In the example below, the following data is used.
Password: qwerty	Password: qwerty
Salt: 0x123eff3c4a72129c	Salt: 0x123eff3c4a72129c
Iteration Count: 1000	Iteration Count: 1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581	MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
skipping to change at page 27, line 26 ¶	skipping to change at page 27, line 26 ¶
The initialization vector (IV) is	The initialization vector (IV) is
"0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to	"0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to
encrypt the randomly chosen MAC key. A different IV can be used,	encrypt the randomly chosen MAC key. A different IV can be used,
say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the example. The	say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the example. The
encryption with algorithm "AES-128-CBC" follows the specification	encryption with algorithm "AES-128-CBC" follows the specification
defined in [XMLENC].	defined in [XMLENC].
<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer	<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"	xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns:pkcs5=	xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey>	<pskc:EncryptionKey>
<dkey:DerivedKey>	<xenc11:DerivedKey>
<dkey:KeyDerivationMethod	<xenc11:KeyDerivationMethod
Algorithm=	Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">	"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>	<pkcs5:PBKDF2-params>
<Salt>	<Salt>
<Specified>Ej7/PEpyEpw=</Specified>	<Specified>Ej7/PEpyEpw=</Specified>
</Salt>	</Salt>
<IterationCount>1000</IterationCount>	<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>	<KeyLength>16</KeyLength>
<PRF/>	<PRF/>
</pkcs5:PBKDF2-params>	</pkcs5:PBKDF2-params>
</dkey:KeyDerivationMethod>	</xenc11:KeyDerivationMethod>
<xenc:ReferenceList>	<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>	<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>	</xenc:ReferenceList>
<dkey:MasterKeyName>My Password 1</dkey:MasterKeyName>	<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
</dkey: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	2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ
SWJblA7Dzi031L6FNnUrcjsGGcQ==	SWJblA7Dzi031L6FNnUrcjsGGcQ==
skipping to change at page 28, line 34 ¶	skipping to change at page 28, line 34 ¶
"urn:ietf:params:xml:ns:keyprov:pskc#hotp" Id="123456">	"urn:ietf:params:xml:ns:keyprov:pskc#hotp" Id="123456">
<pskc:Issuer>Example-Issuer</pskc:Issuer>	<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>	<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>	<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>	</pskc:AlgorithmParameters>
<pskc:Data>	<pskc:Data>
<pskc:Secret>	<pskc:Secret>
<pskc:EncryptedValue Id="ED">	<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod	<xenc:EncryptionMethod
Algorithm=	Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">	"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<pskc:EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
</xenc:EncryptionMethod>
<xenc:CipherData>	<xenc:CipherData>
<xenc:CipherValue>	<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f	oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
</xenc:CipherValue>	</xenc:CipherValue>
</xenc:CipherData>	</xenc:CipherData>
</pskc:EncryptedValue>	</pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=	<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC>	</pskc:ValueMAC>
</pskc:Secret>	</pskc:Secret>
</pskc:Data>	</pskc:Data>
skipping to change at page 30, line 28 ¶	skipping to change at page 30, line 25 ¶
<PlainValue>0</PlainValue>	<PlainValue>0</PlainValue>
</Counter>	</Counter>
</Data>	</Data>
</Key>	</Key>
</KeyPackage>	</KeyPackage>
</KeyContainer>	</KeyContainer>
Figure 8: Example of a PSKC Document using Encryption based on	Figure 8: Example of a PSKC Document using Encryption based on
Asymmetric Keys	Asymmetric Keys
Systems implementing PSKC MUST support the	For systems implementing PSKC it is RECOMMENDED to implement the
http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm.	RSA-1.5 algorithm, identified by the URI
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is one example of	'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
optional implemnted asymmetric key encryption algorithm
Some of the asymmetric encryption algorithms that can optionally be
implemented are:
Algorithm | Uniform Resource Locator (URL)
------------------+-------------------------------------------------
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
The sections above describe the use of different type of algorithms	Padding of encrypted values (for example the key secret value) is
to protect the transported keys. When algorithms are used that do	required when key protection algorithms are used that do not support
not have embedded padding (for example AES algorithm in CBC mode) and	embedded padding and the value to be encrypted is not a multiple of
the keys transmitted are not og the cypher block length (for example	the encryption algorithm cypher block length.
a HOTP key that is 20 bytes long enctypted with AES that has an 8
byte block cypher) padding is required.
PSKC impllementations MUST use PKCS5 padding as described in [PKCS5].	For example, when transmitting a HOTP key (20 bytes long) protected
with the AES algorithm in CBC mode (8 byte block cypher), since 20
bytes are not a multiple of the 8 byte block length, padding is
required.
In these cases, for systems implementing PSKC it is RECOMMENDED to
pad the value before encryption using PKCS5 padding as described in
[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].
<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer	<KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"	xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
skipping to change at page 36, line 34 ¶	skipping to change at page 36, line 34 ¶
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].	draft 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 usage 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 usage of the key to certain functions, such	allows to restrict the use of the key to certain functions, such
as "OTP usage only". Further values may be registered as	as "OTP usage only". Further values may be registered as
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
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.	metadata 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.
skipping to change at page 39, line 17 ¶	skipping to change at page 39, line 17 ¶
This section defines the XML schema for PSKC.	This section defines the XML schema for PSKC.
<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"	xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"	targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
elementFormDefault="qualified"	elementFormDefault="qualified"
attributeFormDefault="unqualified">	attributeFormDefault="unqualified">
<!-- Please note that the first schemaLocation URI has a
linebreak inserted to make it with into the 72-character
wide IETF documents. -->
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=	schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/	"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>	xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"	<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation=	schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>	"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>	<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType">	<xs:complexType name="KeyContainerType">
<xs:sequence>	<xs:sequence>
skipping to change at page 45, line 17 ¶	skipping to change at page 45, line 14 ¶
<xs:element name="MACKey"	<xs:element name="MACKey"
type="xenc:EncryptedDataType" minOccurs="0"/>	type="xenc:EncryptedDataType" minOccurs="0"/>
<xs:element name="MACKeyReference"	<xs:element name="MACKeyReference"
type="xs:string" minOccurs="0"/>	type="xs:string" minOccurs="0"/>
</xs:choice>	</xs:choice>
<xs:any namespace="##other"	<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>	processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>	</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>	<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>	</xs:complexType>
<xs:element name="EncryptionScheme"
type="xenc:EncryptionMethodType"/>
<xs:element name="KeyContainer"	<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>	type="pskc:KeyContainerType"/>
</xs:schema>	</xs:schema>
12. IANA Considerations	12. IANA Considerations
12.1. Content-type registration for 'application/pskc+xml'	12.1. Content-type registration for 'application/pskc+xml'
This specification requests the registration of a new MIME type	This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in	according to the procedures of RFC 4288 [RFC4288] and guidelines in
skipping to change at page 49, line 27 ¶	skipping to change at page 49, line 27 ¶
12.5. PSKC Version Registry	12.5. PSKC Version Registry
IANA is requested to create a registry for PSKC version numbers. The	IANA is requested to create a registry for PSKC version numbers. The
registry has the following structure:	registry has the following structure:
PSKC Version | Specification	PSKC Version | Specification
+---------------------------+----------------	+---------------------------+----------------
| 1.0 | [This document]	| 1.0 | [This document]
Standards action is required to define new versions of PSKC. It is	Standards action is required to define new versions of PSKC. It is
not envisioned to depreciate, delete, or modify existing PSKC	not envisioned to deprecate, delete, or modify existing PSKC
versions.	versions.
12.6. Key Usage Registry	12.6. Key Usage Registry
IANA is requested to create a registry for key usage. A description	IANA is requested to create a registry for key usage. A description
of the 'KeyUsage' element can be found in Section 5. The registry	of the 'KeyUsage' element can be found in Section 5. The registry
has the following structure:	has the following structure:
Key Usage Token | Specification	Key Usage Token | Specification
+---------------------------+-------------------------------	+---------------------------+-------------------------------
skipping to change at page 50, line 5 ¶	skipping to change at page 50, line 5 ¶
| 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 depreciate, delete, or	Using the same procedure it is possible to deprecate, delete, or
modify existing key usage tokens.	modify existing key usage tokens.
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
skipping to change at page 54, line 9 ¶	skipping to change at page 54, line 9 ¶
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,
Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea	Siddhart Bajaj, Stu Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea
Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and	Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and
especially Robert Philpott.	especially Robert Philpott.
We would like to thank Sean Turner for his draft review in January	We would like to thank Sean Turner for his draft review in January
2009. We would also like to thank Anders Rundgren for triggering the	2009. We would also like to thank Anders Rundgren for triggering the
discussion regarding to the selection of encryption algorithms (KW-	discussion regarding to the selection of encryption algorithms (KW-
AES-128 vs. AES-128-CBC) and his input on the keyed message digest	AES-128 vs. AES-128-CBC) and his input on the keyed message digest
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
skipping to change at page 55, line 37 ¶	skipping to change at page 55, line 37 ¶
RFC 4514, June 2006.	RFC 4514, June 2006.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002.	W3C Recommendation, February 2002.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/,	URL: http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002.	W3C Recommendation, December 2002.
[XMLENC11]
Eastlake, D., "XML Encryption Syntax and Processing
Version 1.1.",
URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730,
W3C Recommendation, July 2009.
16.2. Informative References	16.2. Informative References
[AESKWPAD]	[AESKWPAD]
Housley, R. and M. Dworkin, "Advanced Encryption Standard	Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", March 2009, <http:	(AES) Key Wrap with Padding Algorithm", March 2009, <http:
//www.ietf.org/internet-drafts/	//www.ietf.org/internet-drafts/
draft-housley-aes-key-wrap-with-pad-02.txt>.	draft-housley-aes-key-wrap-with-pad-02.txt>.
[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-05.txt,	internet-drafts/draft-ietf-keyprov-dskpp-07.txt,
February 2008.	February 2009.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and	[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password	O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, December 2005.	Algorithm", RFC 4226, December 2005.
[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,	[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
August 1960, <http://patft.uspto.gov/netacgi/	August 1960, <http://patft.uspto.gov/netacgi/
nph-Parser?patentnumber=2950048>.	nph-Parser?patentnumber=2950048>.
[NIST800-57]	[NIST800-57]
skipping to change at page 56, line 38 ¶	skipping to change at page 56, line 44 ¶
December 2008.	December 2008.
[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.	[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.
Masinter, "Uniform Resource Identifiers (URI): Generic	Masinter, "Uniform Resource Identifiers (URI): Generic
Syntax", BCP 26, RFC 2396, August 1998.	Syntax", BCP 26, RFC 2396, August 1998.
[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.
[W3C-DKEY]
Nystrom, M., "XML Security Derived Keys",
W3C Informational, February 2009,
<http://www.w3.org/TR/xmlsec-derivedkeys>.
[XMLNS] "Namespaces in XML", W3C Recommendation ,	[XMLNS] "Namespaces in XML", W3C Recommendation ,
URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,	URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
January 1999.	January 1999.
Appendix A. Use Cases	Appendix A. Use Cases
This section describes a comprehensive list of use cases that	This section describes a comprehensive list of use cases that
inspired the development of this specification. These requirements	inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design.	were used to derive the primary requirement that drove the design.
These requirements are covered in the next section.	These requirements are covered in the next section.
skipping to change at page 58, line 26 ¶	skipping to change at page 58, line 26 ¶
A.1.4. Server to server Bulk import/export of keys	A.1.4. Server to server Bulk import/export of keys
From time to time, a key management system may be required to import	From time to time, a key management system may be required to import
or export keys in bulk from one entity to another.	or export keys in bulk from one entity to another.
For example, instead of importing keys from a manufacturer using a	For example, instead of importing keys from a manufacturer using a
file, a validation server may download the keys using an online	file, a validation server may download the keys using an online
protocol. The keys can be downloaded in a standard format that can	protocol. The keys can be downloaded in a standard format that can
be processed by a validation system.	be processed by a validation system.
For example, in a variation of the above, an Over-The-Aire (OTA) key	For example, in a variation of the above, an Over-The-Air (OTA) key
provisioning gateway that provisions keys to mobile phones may obtain	provisioning gateway that provisions keys to mobile phones may obtain
key material from a key issuer using an online protocol. The keys	key material from a key issuer using an online protocol. The keys
are delivered in a standard format that can be processed by the key	are delivered in a standard format that can be processed by the key
provisioning gateway and subsequently sent to the end-user's mobile	provisioning gateway and subsequently sent to the end-user's mobile
phone.	phone.
A.2. Offline Use Cases	A.2. Offline Use Cases
This section describes the use cases relating to offline transport of	This section describes the use cases relating to offline transport of
keys from one system to another, using some form of export and import	keys from one system to another, using some form of export and import
End of changes. 77 change blocks.
187 lines changed or deleted		191 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff