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. meta data for the key.
The following additional constraints apply: The following additional constraints apply:
+ The value of the <Secret> element MUST contain key material + The value of the <Secret> element MUST contain key material
with a length of at least 16 octets (128 bits), if it is with a length of at least 16 octets (128 bits), if it is
present. present.
+ The <ResponseFormat> element MUST have the 'Format' + The <ResponseFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Length' attribute MUST attribute set to "DECIMAL", and the 'Length' attribute MUST
indicate a length value between 6 and 9. indicate a length value between 6 and 9.
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.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/