One document matched: draft-ietf-keyprov-pskc-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY I-D.housley-aes-key-wrap-with-pad PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.housley-aes-key-wrap-with-pad.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-keyprov-pskc-03">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Portable Symmetric Key Container (PSKC)</title>
<author initials="P." surname="Hoyer" fullname="Philip Hoyer">
<organization abbrev="ActivIdentity"> ActivIdentity, Inc. </organization>
<address>
<postal>
<street>117 Waterloo Road</street>
<city>London</city>
<region>SE1</region>
<code>8UL</code>
<country>UK</country>
</postal>
<phone>+44 (0) 20 7744 6455</phone>
<email>Philip.Hoyer@actividentity.com</email>
</address>
</author>
<author initials="M." surname="Pei" fullname="Mingliang Pei">
<organization abbrev="VeriSign"> VeriSign, Inc. </organization>
<address>
<postal>
<street>487 E. Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<phone>+1 650 426 5173</phone>
<email>mpei@verisign.com</email>
</address>
</author>
<author initials="S." surname="Machani" fullname="Salah Machani">
<organization abbrev="Diversinet"> Diversinet, Inc. </organization>
<address>
<postal>
<street>2225 Sheppard Avenue East</street>
<street>Suite 1801</street>
<city>Toronto</city>
<region>Ontario</region>
<code>M2J 5C2</code>
<country>Canada</country>
</postal>
<phone>+1 416 756 2324 Ext. 321</phone>
<email>smachani@diversinet.com</email>
</address>
</author>
<date month="June" year="2009"/>
<workgroup>keyprov</workgroup>
<abstract>
<t>This document specifies a symmetric key format for transport and provisioning of
symmetric keys to different types of crypto modules. For example One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. The standard key transport format enables enterprises to
deploy best-of-breed solutions combining components from different vendors into the
same infrastructure. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>With increasing use of symmetric key based systems, such as encryption of data at rest or systems used for strong authentication such as those
based on one-time-password (OTP) and challenge response (CR) mechanisms, there is a need for
vendor interoperability and a standard format for importing and exporting
(provisioning) symmetric keys. Traditionally, for example vendors of authentication servers and
service providers have used proprietary formats for importing and exporting these
keys into their systems, thus making it hard to use tokens from vendor "Foo" with a server
from vendor "Bar".</t>
<t>This document defines a standardized XML-based key container, called Portable
Symmetric Key Container (PSKC), for transporting symmetric keys and key related meta data. The document also specifies the information elements that may be required when the symmetric key is utilized for specific purposes, such as the initial counter in the MAC-Based One Time Password (HOTP) <xref target="HOTP"/> algorithm. It also requests the creation of a IANA registry for algorithm profiles where algorithms, their related meta-data and PSKC transmission profile can be recorded for centralised standardised reference. </t>
<section title="Key Words">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section title="Versions">
<t>There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified.</t>
</section>
<section title="Namespace Identifiers">
<t>This document uses Uniform Resource Identifiers <xref target="RFC2396"/> to identify
resources, algorithms, and semantics..</t>
<section title="Defined Identifiers">
<t> The XML namespace <xref target="XMLNS" /> URI for Version 1.0 of PSKC is:</t>
<t>xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"</t>
<t> References to qualified elements in the PSKC schema defined herein
use the prefix "pskc".</t>
</section>
<section title="Referenced Identifiers">
<t>The PSKC syntax presented in this document relies on
algorithm identifiers and elements defined in the XML Signature <xref target="XMLDSIG"/>
namespace:</t>
<t>xmlns:ds="http://www.w3.org/2000/09/xmldsig#"</t>
<t> References to the XML Signature namespace
are represented by the prefix "ds".</t>
<t>PSKC also relies on
algorithm identifiers and elements defined in the XML Encryption <xref target="XMLENC"/>
namespace:</t>
<t>xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"</t>
<t> References to the XML Encryption namespace
are represented by the prefix "xenc".</t>
<t>When protecting keys in transport with passphrase-based keys, PSKC also relies on
the derived key element defined in the W3C Derived Key <xref target="W3C-DKEY"/>
namespace:</t>
<t>xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"</t>
<t> References to the W3C Derived Key namespace
are represented by the prefix "dkey".</t>
<t>When protecting keys in transport with passphrase-based keys, PSKC also relies on
algorithm identifiers and elements defined in the PKCS#5 <xref target="PKCS5"/>
namespace:</t>
<t>xmlns:pkcs5= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"</t>
<t> References to the PKCS#5 namespace
are represented by the prefix "pkcs5".</t>
</section>
</section>
</section>
<!-- ****************************************************************************************** -->
<section title="Terminology">
<!--
<t>The following terms used in this document. <list style="hanging">
<t hangText="Authentication Token:">A physical device that an authorized user of
computer services is given to aid in authentication. The term may also refer
to software tokens.</t>
<t hangText="Bulk Provisioning:">Transferring multiple keys linked to multiple
devices in a single execution step within one single PSKC KeyContainer</t>
<t hangText="Cryptographic Module:">A component of an application, which enables
symmetric key cryptographic functionality</t>
<t hangText="Cryptographic Key:">A parameter used in conjunction with a
cryptographic algorithm that determines its operation in such a way that an
entity with knowledge of the key can reproduce or reverse the operation,
while an entity without knowledge of the key cannot (see <xref
target="NIST-SP800-57"/>)</t>
<t hangText="Cryptographic Token:">See Authentication Token</t>
<t hangText="Device:">A physical piece of hardware, or a software framework,
that hosts symmetric keys</t>
<t hangText="DeviceInfo:">A set of elements whose values combined uniquely
identify a device e.g. Manufacturer 'TokenVendorAcme' and Serialnumber
'12345678'</t>
<t hangText="Dynamic Provisioning:">Usage of a protocol, such as DSKPP, to make
a key container available to a recipient</t>
<t hangText="Key Encryption Key:">A key used to encrypt key</t>
<t hangText="Key:">See Cryptographic Key</t>
<t hangText="Hardware Token:">See Authentication Token</t>
<t hangText="Key Algorithm:">A well-defined computational procedure that takes
variable inputs including a cryptographic key and produces an output.</t>
<t hangText="Key Container:">An object that encapsulates symmetric keys and
their attributes for set of devices</t>
<t hangText="Key ID (KeyID):">A unique identifier for the symmetric key</t>
<t hangText="Key Issuer:">An organization that issues symmetric keys to
end-users</t>
<t hangText="Key Type:">The type of symmetric key cryptographic methods for
which the key will be used (e.g., OATH HOTP or RSA SecurID authentication,
AES encryption, etc.)</t>
<t hangText="Secret Key:">The symmetric key data</t>
<t hangText="Software Token:">A type of authentication token that is stored on a
general-purpose electronic device such as a desktop computer, laptop, PDA,
or mobile phone </t>
<t hangText="Token:">See Authentication Token</t>
<t hangText="User:">The person or client to whom devices are issued</t>
<t hangText="User ID:">A unique identifier for the user or client</t>
</list></t>
-->
<t>NOTE: In subsequent sections of the document we highlight **mandatory** XML elements
and attributes. Optional elements and attributes are not explicitly indicated, i.e.,
if it does not say mandatory it is optional. </t>
</section>
<!-- ****************************************************************************************** -->
<section title="Portable Key Container Entities Overview and Relationships">
<t>The portable key container is based on an XML schema definition and contains the
following main conceptual entities: <list style="numbers">
<t>KeyContainer entity - representing the container that carries a number of KeyPackages</t>
<t>KeyPackage entity - representing the package of upmost one key and its related provisioning endpoint or current usage endpoint, such as a physical or virtual device and a specific CryptoModule</t>
<t>DeviceInfo entity - representing the information about the device and
criteria to uniquely identify the device</t>
<t>CryptoModuleInfo entity - representing the information about the CryptoModule where the keys reside or are provisioned to</t>
<t>Key entity - representing the key transported or provisioned</t>
<t>Data entity - representing a list of meta-data related to the key, where the element name is the name of the meta-data and its associated value is either in encrypted form (for example for Data element 'SECRET') or plaintext (for example for the Data element 'COUNTER') </t>
</list>
</t>
<t><xref target="er"/> shows the high-level structure of the PSKC data elements. <figure
anchor="er">
<artwork>
<![CDATA[
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
]]>
</artwork>
</figure> The following sections describe in detail all the entities and related XML
schema elements and attributes.</t>
</section>
<section anchor="basics" title="<KeyContainer> Element: The Basics">
<t>In its most basic form, a PSKC document uses the top-level element
<KeyContainer> and a single <KeyPackage> element to
carry key information.</t>
<t>The following example shows such a simple PSKC document. We will use it to describe
the structure of the <KeyContainer> element and its child elements.
<figure anchor="example-simple" title="Basic PSKC Key Container Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
<Issuer>Issuer-A</Issuer>
<Data>
<Secret>
<PlainValue>MTIzNA==
</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
<t>The attributes of the <KeyContainer> element have the following
semantics: <list style="hanging">
<t hangText="'Version:'">The 'Version' attribute is used to identify the version
of the PSKC schema version. This specification defines the initial version
("1.0") of the PSKC schema. This attribute is mandatory.</t>
<t hangText="'Id:'">The 'Id' attribute carries a unique identifier for the
container. As such, it helps to identify a specific key container in cases when multiple containers are embedded in larger xml documents. </t>
</list>
</t>
<section anchor="KeyElement"
title="<Key>: Embedding Keying Material and Key Related Information">
<t>The following attributes of the <Key> element MUST be included at a
minimum: <list style="hanging">
<t hangText="'Id':">This attribute carries a globally unique identifier
for the symmetric key. The identifier is defined as a string of
alphanumeric characters.</t>
<t hangText="'Algorithm':">This attribute contains a unique identifier
for the PSKC algorithm profile. This profile associates specific
semantics to the elements and attributes contained in the
<Key> element. This document describes profiles for open standards algorithms in <xref target="profiles"/>. Additional profiles are defined in the following information draft <xref target="PSKC-ALGORITHM-PROFILES"/></t>
</list>
</t>
<t>The <Key> element has a number of optional child elements. An
initial set is described below: <list style="hanging">
<t hangText="<Issuer>:">This element represents the name of
the party that issued the key. For example, a bank "Foobar Bank Inc."
issuing hardware tokens to their retail banking users may set this
element to "Foobar Bank Inc.".</t>
<t hangText="<FriendlyName>:"> A human readable name for the
secret key for easier reference. This element serves informational
purposes only.</t>
<t hangText="<AlgorithmParameters>:"> This element carries parameters that influence the result of the algorithmic computation, for example response truncation and format in OTP and CR algorithms. A more detailed
discussion of the element can be found in <xref target="AlgorithmParametersElement"/>. </t>
<t hangText="<Data>:">This element carries data about and
related to the key. The following child elements are defined for the
<Data> element: <vspace blankLines="1"/>
<list style="hanging">
<t hangText="<Secret>:">This element carries the value
of the key itself in a binary representation.</t>
<t hangText="<Counter>:">This element contains the
event counter for event based OTP algorithms.</t>
<t hangText="<Time>:">This element contains the time
for time based OTP algorithms. (If time interval is used, this
element carries the number of time intervals passed from a
specific start point, normally algorithm dependent)</t>
<t hangText="<TimeInterval>:">This element carries the
time interval value for time based OTP algorithms.</t>
<t hangText="<TimeDrift>:">This element contains the
device clock drift value for time-based OTP algorithms. The
value indicates the number of seconds that the device clock may
drift each day. </t>
</list> All the elements listed above (and those defined in the
future) obey a simple structure in that they MUST support child elements
to convey the data value in either plaintext or encrypted format: <list
style="hanging">
<t hangText="Plaintext:">The <PlainValue> element carries
plaintext value that is typed, for example to xs:integer.</t>
<t hangText="Encrypted:">The <EncryptedValue> element
carries encrypted value</t>
</list> Additionally, it MUST be possible to carry a <ValueMac>
element, which is populated with a MAC generated from the encrypted
value in case the encryption algorithm does not support integrity
checks, as a child element. The example shown at <xref
target="example-simple"/> illustrates the usage of the
<Data> element with two child elements, namely
<Secret> and <Counter>. Both elements carry
plaintext value within the <PlainValue> child element. </t>
</list>
</t>
</section>
<section title="Transmission of supplementary Information">
<t>A PSKC document can contain a number of additional information regarding device
identification, cryptomodule identification, user identification and parameters for usage with
OTP and CR algorithms. The following example, see <xref target="example-suppl"
/>, is used as a reference for the subsequent sub-sections. <figure
anchor="example-suppl"
title="PSKC Key Container Example with Supplementary Data">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
<UserId>DC=example-bank,DC=net</UserId>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
<section anchor="DeviceInfoElement"
title="<DeviceInfo> Element: Unique Device Identification">
<t>The <DeviceInfo> element uniquely identifies the device the
<KeyPackage> is provisioned to. Since devices can come in different
form factors, such as hardware tokens, smart-cards, soft tokens in a mobile
phone or as a PC, this element allows different child element combinations to be used.
When combined, the values of the child elements MUST uniquely identify the device. For example,
for hardware tokens the combination of <SerialNo> and
<Manufacturer> elements uniquely identifies a device but the
<SerialNo> element alone is insufficient since two different
token manufacturers might issue devices with the same serial number (similar
to the Issuer Distinguished Name and serial number of a certificate). </t>
<t>The <DeviceInfo> element has the following child elements:
<list style="hanging">
<t hangText="<Manufacturer>:">This element indicates the
manufacturer of the device.</t>
<t hangText="<SerialNo>:">This element contains the serial
number of the device.</t>
<t hangText="<Model>:">This element describes the model of
the device (e.g., one-button-HOTP-token-V1).</t>
<t hangText="<IssueNo>:">This element contains the issue
number in case devices with the same serial number that are
distinguished by different issue numbers.</t>
<t hangText="<DeviceBinding>:">In a number of cases access
to lower layer device identifiers, such as a serial number, from a
PSKC implementation is difficult or impossible. For this purpose
an opaque identifier, carried in the <DeviceBinding>
element, is introduced that allows to bind keys to the device or to
a class of devices. When loading keys into a device, the value of
the <DeviceBinding> 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. </t>
<t hangText="<StartDate>: and <ExpiryDate>:"
>These two elements indicate the start 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 expressed in UTC form with no
timezone component. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds.</t>
</list> Depending on the device type certain child elements of the
<DeviceInfo> element MUST be included in order to
uniquely identify a device. This document does not enumerate the different
device types and therefore does not list the elements that are mandatory for
each type of device. </t>
</section>
<section anchor="CryptoModuleInfoElement"
title="<CryptoModuleInfo> Element: CryptoModule Identification">
<t>The <CryptoModuleInfo> element identifies the cryptographic module to which the
symmetric keys are or have been provisioned to. This 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 connected token)</t>
<t>The <CryptoModuleInfo> element has a single mandatory child element: <list style="hanging">
<t hangText="<Id>:"> This element carries a unique identifier for the
CryptoModule and is implementation specific. As such, it helps to identify a specific CryptoModule to which the key is being or was proivisioned.</t>
</list>
</t>
</section>
<section anchor="UserIdElement"
title="<UserId> Element: User Identification">
<t>The <UserId> element identifies the user using a distinguished
name, as defined in <xref target="RFC4514"/>. For example:
UID=jsmith,DC=example,DC=net </t>
<t>Although the syntax of the user identifier is defined there are no semantics
associated with this element, i.e., there are no checks enforcing that only
a specific user can use this key. As such, this element is for informational
purposes only.</t>
<t>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
associated with and as a child element of the <DeviceInfo>
element where it indicates that the entity the device belongs to. </t>
</section>
<section anchor="AlgorithmParametersElement"
title="<AlgorithmParameters> Element: Supplementary Information for OTP and CR Algorithms">
<t>The <AlgorithmParameters> element is a child element of the
<Key> element and this document defines two child elements:
<ChallengeFormat> and <ResponseFormat></t>
<t>
<list style="hanging">
<t hangText="<ChallengeFormat>:"><vspace blankLines="1"/>
The <ChallengeFormat> element defines the
characteristics of the challenge in a CR usage scenario whereby the
following attributes are defined: <list style="hanging">
<t hangText="'Encoding':"> This mandatory attribute defines the
encoding of the challenge accepted by the device and MUST be
one of the following values: <list style="hanging">
<t hangText="DECIMAL"> Only numerical digits</t>
<t hangText="HEXADECIMAL">Hexadecimal response</t>
<t hangText="ALPHANUMERIC">All letters and numbers (case
sensitive)</t>
<t hangText="BASE64">Base 64 encoded</t>
<t hangText="BINARY">Binary data</t>
</list>
</t>
<t hangText="'CheckDigit':"> This optional attribute indicates
whether a device needs to check the appended Luhn check
digit, as defined in <xref target="LUHN"/>, contained in a
challenge. This is only valid if the 'Encoding'
attribute is 'DECIMAL'. A value of TRUE indicates that the
device will check the appended Luhn check digit in a
provided challenge. A value of FALSE indicates that the device
will not check the appended Luhn check digit in the challenge.</t>
<t hangText="'Min':"> This mandatory attribute defines the
minimum size of the challenge accepted by the device for CR
mode. If the 'Encoding' attribute is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the
minimum number of digits/characters. If the 'Encoding'
attribute is 'BASE64' or 'BINARY', this value indicates the
minimum number of bytes of the unencoded value.</t>
<t hangText="'Max':">This mandatory attribute defines the
maximum size of the challenge accepted by the device for CR
mode. If the 'Encoding' attribute is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the
maximum number of digits/characters. If the 'Encoding'
attribute is 'BASE64' or 'BINARY', this value indicates the
maximum number of bytes of the unencoded value.</t>
</list>
</t>
<t hangText="<ResponseFormat>:">
<vspace blankLines="1"/> The <ResponseFormat> element
defines the characteristics of 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, this element contains the format
of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit PIN). The
following attributes are defined: <list style="hanging">
<t hangText="'Encoding':">This mandatory attribute defines the
encoding of the response generated by the device and MUST be
one of the following values: DECIMAL, HEXADECIMAL,
ALPHANUMERIC, BASE64, or BINARY.</t>
<t hangText="'CheckDigit':">This optional attribute indicates
whether the device needs to append a Luhn check digit, as
defined in <xref target="LUHN"/>, to the response. This is
only valid if the 'Encoding' attribute is 'DECIMAL'. If the
value is TRUE then the device will append a Luhn check digit
to the response. If the value is FALSE, then the device will
not append a Luhn check digit to the response.</t>
<t hangText="'Length':">This mandatory attribute defines the
length of the response generated by the device. If the
'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the number of
digits/characters. If the 'Encoding' attribute is 'BASE64'
or 'BINARY', this value indicates the number of bytes of the
unencoded value.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Transmission of Key Derivation Values">
<t><KeyProfileId> element, which is a child element of the
<Key> element, carries a unique identifier used between the
sending and receiving parties to establish a set of key attribute values that are
not transmitted within the container but agreed between the two parties out of
band. This element will then represent the unique reference to a set of
key attribute values. (For example, a smart card application personalisation profile
id related to attributes present on a smart card application that have influence
when computing a response.) Likewise, the sending and receiving parties, might agree to a
set of values related to the MasterCard's Chip Authentication Protocol
<xref target="CAP"/>. </t>
<t>For example, sending and receiving party would agree that KeyProfileId='1' would
represent a certain set of values (e.g., Internet authentication flag set to a
specific value). When sending keys these values would not be transmitted as key
attributes but only referred to via the <KeyProfileId> element set
to the specific agreed profile (in this case '1'). When the receiving party
receives the keys it can then associate all relevant key attributes contained in
the out of band agreed profile with the imported keys. Often this methodology is
used between the manufacturing and the validation service to avoid repeated transmission
of the same set of values.</t>
<t>The <KeyReference> element contains a reference to an external key to be used with a
key derivation scheme and no specific key is transported but only the
reference to the external key is used (e.g., the PKCS#11 key label).</t>
<t>
<figure anchor="example-key-derivation-values"
title="Example of a PSKC Document transmitting a HOTP key via key derivation values">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<KeyProfileId>keyProfile1</KeyProfileId>
<Data>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure> The key value will be derived using the value of the
<SerialNumber> element and an external key identified by the label
'MasterKeyLabel'. </t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section anchor="policy" title="Key policy - transmission of key usage policies and key PIN protection policy">
<t>This section illustrates the functionality of the <Policy> element
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> element.</t>
<t>If the <Policy> element contains child elements or values within
elements/attributes that are not understood by the recipient of the PSKC document
then the recipient MUST assume that key usage is not permitted. This statement
ensures that the lack of understanding of certain extensions does not lead to
unintended key usage. </t>
<t>We will start our description with an example that expands the example shown in <xref
target="example-suppl"/>. <figure anchor="example-pin"
title="Non-Encrypted HOTP Secret Key protected by PIN">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<PINPolicy MinLength="4" MaxLength="4"
PINKeyId="123456781" PINEncoding="DECIMAL"
PINUsageMode="Local"/>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="123456781"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="4" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNA==</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
<t>This document defines the following Policy child elements: <list style="hanging">
<t hangText="<StartDate> and <ExpiryDate>:">These
two elements denote the validity 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 expressed in UTC form, with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than milliseconds
and MUST NOT generate time instants that specify leap seconds. When this
element is absent the current time is assumed as the start time.</t>
<t hangText="<NumberOfTransactions>:">The value in this element
indicates the maximum number of times a key carried within
the PSKC document can be used. When this element is omitted then there is
no restriction regarding the number of times a key can be used. </t>
<t hangText="<KeyUsage>:"> The <KeyUsage> element
puts constraints on the intended usage of the key. The recipient of the PSKC
document MUST enforce the key usage. Currently, the following tokens are
registered by this document: <list style="hanging">
<t hangText="OTP:"> The key MUST only be used for OTP generation.</t>
<t hangText="CR:"> The key MUST only be used for Challenge/Response
purposes.</t>
<t hangText="Encrypt:">The key MUST only be used for data encryption
purposes.</t>
<t hangText="Integrity:">The key MUST only be used to generate a keyed
message digest for data integrity or authentication purposes.</t>
<t hangText="Verify:">The key MUST only be used to verify a keyed message digest for data integrity or authentication purposes. ( is the vice versa of Integrity) </t>
<t hangText="Unlock:"> The key MUST only be used for an inverse
challenge response in the case where a user has locked the device by
entering a wrong PIN too many times (for devices with PIN-input
capability).</t>
<t hangText="Decrypt:">The key MUST only be used for data decryption
purposes.</t>
<t hangText="KeyWrap:">The key MUST only be used for key wrap purposes.</t>
<t hangText="Unwrap:">The key MUST only be used for key unwrap purposes.</t>
<t hangText="Derive:">The key MUST only be used with a key derivation
function to derive a new key (see also Section 8.2.4 of <xref
target="NIST800-57"/>).</t>
<t hangText="Generate:">The key MUST only be used to generate a new key
based on a random number and the previous value of the key (see also
Section 8.1.5.2.1 of<xref target="NIST800-57"/>).</t>
</list> The element MAY also be repeated to allow several key usages to be
expressed. When this element is absent then no key usage constraint is
assumed, i.e., the key MAY be utilized for every usage. </t>
<t hangText="<PINPolicy>:"> The <PINPolicy> element
allows policy about the PIN usage to be associated with the key. The
following attributes are specified: <list style="hanging">
<t hangText="'PINKeyId':">This attribute contains the unique key id of
the key held within this container that contains the value of the
PIN that protects the key.</t>
<t hangText="'PINUsageMode':">This mandatory attribute indicates the way
the PIN is used during the usage of the key. The following values
are defined: <list style="hanging">
<t hangText="Local:">This value indicates that the PIN is
checked locally on the device before allowing the key to be
used in executing the algorithm.</t>
<t hangText="Prepend:">This value indicates that the PIN is
prepended to the OTP or response hence it MUST be checked by
the validation server.</t>
<t hangText="Append:">This value indicates that the PIN is
appended to the OTP or response hence it MUST be checked by
the validation server.</t>
<t hangText="Algorithmic:">This value indicates that the PIN is
used as part of the algorithm computation.</t>
</list>
</t>
<t hangText="'MaxFailedAttempts':"> This attribute indicates the maximum
number of times the PIN may be entered wrongly before it MUST NOT be
possible to use the key anymore. </t>
<t hangText="'MinLength':"> This attribute indicates the minimum length
of a PIN that can be set to protect the associated key. It MUST NOT be
possible to set a PIN shorter than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
indicates the number of digits/characters. If the 'PINFormat'
attribute is 'BASE64' or 'BINARY', this value indicates the number
of bytes of the unencoded value.</t>
<t hangText="'MaxLength':"> This attribute indicates the maximum lenght
of a PIN that can be set to protect this key. It MUST NOT be
possible to set a PIN longer than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
indicates the number of digits/characters. If the 'PINFormat'
attribute is 'BASE64' or 'BINARY', this value indicates the number
of bytes of the unencoded value. </t>
<t hangText="'PINEncoding':">This attribute indicates the encoding of
the PIN and MUST be one of the values: DECIMAL, HEXADECIMAL,
ALPHANUMERIC, BASE64, or BINARY.</t>
</list> If the 'PinUsageMode' attribute is set to "Local" then the device
MUST enforce the restriction indicated in the 'MaxFailedAttempts',
'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it MUST be
enforced on the server side. </t>
</list>
</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="EncryptionKeyDescription" title="Key protection methods">
<t>With the functionality described in the previous sections, information related to keys
had to be transmitted in clear text. With the help of the
<EncryptionKey> element, which is a child element of the
<KeyContainer> element, it is possible to encrypt keys and associated
information. The level of encryption is applied to the value of individual elements
and the applied encryption algorithm MUST be the same for all encrypted elements. Keys are protected using the following methods: pre-shared keys, passphrase-based
keys, and asymmetric keys.</t>
<section anchor="SymmetricKeyProtectionDescription"
title="Encryption based on Pre-Shared Keys">
<t><xref target="example-encr-psk"/> shows an example that illustrates the
encryption of the content of the <Secret> element using
AES128-CBC and PKCS5 Padding. The plaintext value of <Secret> is
'3132333435363738393031323334353637383930'. The name of the pre-shared secret is
"Example-Key1", as set in the <KeyName> element (which is a child
element of the <EncryptionKey> element). The value of the encryption key used
is '12345678901234567890123456789012'. Since 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 declared in the <MACMethod> element (in our example
"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is use as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key.) The result of the keyed
MAC computation is placed in the <ValueMAC> child element of <Secret>. </t>
<t>
<figure anchor="example-encr-psk"
title="AES-128-CBC Encrypted Pre-Shared Secret Key">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>
<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
R8+5I6m74doa0nRhaPejbt3elq9hLPGvxHgXVlYpbgA=
</xenc:CipherValue>
</xenc:CipherData>
</MACKey>
</MACMethod>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>ooo0Swn6s/myD4o05FCfBHN0560=</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
<t>When protecting the payload with pre-shared keys implementations MUST set the
name of the specific pre-shared key in the <KeyName> element
inside the <EncryptionKey> element. When the encryption method uses
a CBC mode that requires an explicit initialization vector (IV), the IV MUST be passed by
prepending it to the encrypted value.</t>
<t>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 KW-AES128 (with the URI
of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128
requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if
keys of a different length have to be protected then the usage of the key wrap
algorithm with padding, as described in <xref target="AESKWPAD"/> is RECOMMENDED. Some of the encryption algorithms that can optionally be implemented are:</t>
<t>
<figure>
<artwork><![CDATA[
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
]]></artwork>
</figure>
</t>
<section anchor="MACMethodDescription" title="MAC Method">
<t> When algorithms without integrity checks are used, such as AES-128-CBC, a keyed
MAC value MUST be placed in the <ValueMAC> element of the <Data> element. In this
case the MAC algorithm type MUST be set in the <MACMethod>
element of the <KeyContainer> element. The MAC key MUST be a randomly generated key
by the sender, a pre-shared one between the receiver and the sender, or one set by an application
protocol that uses KeyContainer. It is recommended that a sender generates a random MAC key.
When the sender generates such a random MAC key, the MAC key material MUST be encrypted
with the same encryption key specified in <EncryptionKey> element of the key container. The
encryption method and encrypted value MUST be set respectively in the <EncryptionMethod> element
and the <CipherData> element of the <MACKey> element in the <MACMethod> element.
The <MACKeyReference> element of the <MACMethod> element MAY be used to indicate
a pre-shared MAC key or a provisioning protocol derived MAC key.
Implementations of PSKC MUST support HMAC-SHA1 (with the URI of
http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-implement MAC
algorithm. Some of the MAC algorithms that can optionally be implemented are:</t>
<t>
<figure>
<artwork><![CDATA[
Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------
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-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Encryption based on Passphrase-based Keys">
<t><xref target="example-encr-passwd"/> shows an example that illustrates the
encryption of the content of the <Secret> element using
passphrase based encryption PBES2 as defined in <xref target="PKCS5"/>. When using passphrase based encryption, the <DerivedKey> element defined in W3C [W3C-DKEY] MUST be used to specify the passphrased-based
key. A <DerivedKey> element is set as the child element of <EncryptionKey> element of the key container.</t>
<t>
The <DerivedKey> element is used to specify the key derivation function and related parameters.
The encryption algorithm, namely PBES2 as specified in <xref target="PKCS5"/> ( URI 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2'), MUST be set in the 'Algorithm' attribute of <EncryptionMethod> element used inside the encrypted data elements.</t>
<t>When PBKDF2 is used, the attribute "Algorithm" of the element <dkey:KeyDerivationMethod> MUST be set to the URI 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The element
<dkey:KeyDerivationMethod> MUST include the <PBKDF2-params> child element to indicate the
PBKDF2 parameters, such as salt and iteration count.</t>
<t> 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>. </t>
<t>When the encryption method uses a CBC mode that uses an explicit initialization vector (IV) other than a
derived one, the IV MUST be passed by prepending it to the encrypted value.</t>
<t>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 <xref target="example-encr-passwd"/>. </t>
<t>In the example below, the following data is used. <list style="hanging">
<t hangText="Password: ">qwerty</t>
<t hangText="Salt: ">0x123eff3c4a72129c</t>
<t hangText="Iteration Count:">1000</t>
<t hangText="MAC Key: ">0xbdaab8d648e850d25a3289364f7d7eaaf53ce581</t>
<t hangText="OTP Secret: ">12345678901234567890</t>
</list> The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41". The initialization
vector (IV) is "0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to encrypt the randomly
chosen MAC key. A different IV can be used, say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the example.
The encryption with algorithm "AES-128-CBC" follows the specification defined in <xref target="XMLENC"/>. </t>
<t>
<figure anchor="example-encr-passwd"
title="Example of a PSKC Document using Encryption based on Passphrase-based Keys">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey>
<dkey:DerivedKey>
<dkey:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</pkcs5:PBKDF2-params>
</dkey:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<dkey:MasterKeyName>My Password 1</dkey:MasterKeyName>
</dkey:DerivedKey>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ
SWJblA7Dzi031L6FNnUrcjsGGcQ==
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc#hotp" Id="123456">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
<pskc:EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
</xenc:EncryptionMethod>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC>
</pskc:Secret>
</pskc:Data>
</pskc:Key>
</pskc:KeyPackage>
</pskc:KeyContainer>
]]></artwork>
</figure>
</t>
</section>
<section anchor="AsymmetricKeyProtectionDescription" title="Encryption based on Asymmetric Keys">
<t>When using asymmetric keys to encrypt child elements of the <Data>
element information about the certificate being used MUST be stated in the
<X509Data> element, which is a child element of the
<EncryptionKey> element. The encryption algorithm MUST be
indicated in the 'Algorithm' attribute of the <EncryptionMethod>
element. In the example shown in <xref target="example-encr-asymm"/> the
algorithm is set to "http://www.w3.org/2001/04/xmlenc#rsa_1_5".</t>
<t>
<figure anchor="example-encr-asymm"
title="Example of a PSKC Document using Encryption based on Asymmetric Keys">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" ?>
<KeyContainer
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001"
Version="1.0">
<EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</EncryptionKey>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key
Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
<t>Systems implementing PSKC MUST support the
http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm.
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is one example of optional implemnted asymmetric key encryption algorithm</t>
</section>
<section title="Padding of encrypted values for non-padded encryption algorithms">
<t>The sections above describe the use of different type of algorithms to protect the transported keys. When algorithms are used that do not have embedded padding (for example AES algorithm in CBC mode) and the keys transmitted are not og the cypher block length (for example a HOTP key that is 20 bytes long enctypted with AES that has an 8 byte block cypher) padding is required.</t>
<t>PSKC impllementations MUST use PKCS5 padding as described in <xref target="PKCS5"/>.
</t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section title="Digital Signature">
<t>PSKC allows a digital signature to be added to the XML document, as a child element
of the <KeyContainer> element. The description of the XML digital
signature can be found in <xref target="XMLDSIG"/>.</t>
<t>
<figure anchor="example-dsig" title="Digital Signature Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceInfo>
<Key Id="123"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
<Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Device">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>
CN=Example.com,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>
12345678
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</Signature>
</KeyContainer>
]]></artwork>
</figure>
</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="bulk" title="Bulk Provisioning">
<t>The functionality of bulk provisioning can be accomplished by repeating the
<KeyPackage> element multiple times within the
<KeyContainer> element indicating that multiple keys are provided to
different devices or cryptomodules. The <EncryptionKey> element then applies to all
<KeyPackage> elements. When provisioning multiple keys to the same device the <KeyPackage> element is repeated but the enclosed <DeviceInfo> element will contain the same sub elements that uniquely identify the single device.</t>
<t><xref target="example-bulk"/> shows an example utilizing these capabilities.</t>
<t>
<figure anchor="example-bulk" title="Bulk Provisioning Example">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo>
</DeviceInfo>
<Key Id="1"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>123456</SerialNo>
</DeviceInfo>
<Key Id="2"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="3"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-03-01T00:00:00Z</StartDate>
<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
<Key Id="4"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-04-01T00:00:00Z</StartDate>
<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
]]></artwork>
</figure>
</t>
</section>
<!-- ****************************************************************************************** -->
<section title="Extensibility">
<t>This section lists a few common extension points provided by PSKC: </t>
<t>
<list style="hanging">
<t hangText="New PSKC Version:">Whenever it is necessary to define a new version
of this document then a new version number has to be allocated to refer to
the new specification version. The version number is carried inside the
'Algorithm' attribute, as described in <xref target="basics"/>, and rules
for extensibililty are defined in <xref target="iana"/>.</t>
<t hangText="New XML Elements:">The usage of the XML schema and the available
extension points allows new XML elements to be added. Depending of type of
XML elements different ways for extensibility are offered. In some places
the <Extensions> element can be used and elsewhere the
"<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>" XML extension point is utilized.</t>
<t hangText="New XML Attributes:">The XML schema allows new XML attributes to be
added where XML extension points have been defined (see
"<xs:anyAttribute namespace="##other"/>" in <xref
target="schema"/>).</t>
<t hangText="New PSKC Algorithm Profiles:">This document defines two PSKC
algorithm profiles, see <xref target="profiles"/>. The following informational draft describes additional profiles <xref target="PSKC-ALGORITHM-PROFILES"/>. Further PSKC algorithm
profiles can be registered as described in <xref
target="SymmetricKeyAlgorithmIdentifierRegistry"/>.</t>
<t hangText="Algorithm URIs:">
<xref target="EncryptionKeyDescription"/> defines how keys and related data
can be protected. A number of algorithms can be used. The usage of new
algorithms can be used by pointing to a new algorithm URI. </t>
<t hangText="Policy:">
<xref target="policy"/> defines policies that can be attached to a key and
keying related data. The <Policy> element is one such item
that allows to restrict the usage of the key to certain functions, such as
"OTP usage only". Further values may be registered as described in <xref
target="iana"/>. </t>
</list>
</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="profiles" title="PSKC Algorithm Profile">
<section title="HOTP" anchor="hotp">
<t>
<list style="hanging">
<t hangText="Common Name:"> HOTP </t>
<t hangText="Class:"> OTP </t>
<t hangText="URN:">urn:ietf:params:xml:ns:keyprov:pskc#hotp</t>
<t hangText="Algorithm Definition:"> http://www.ietf.org/rfc/rfc4226.txt </t>
<t hangText="Identifier Definition:"> (this RFC) </t>
<t hangText="Registrant Contact:"> IESG </t>
<t hangText="Profiling:">
<list style="empty">
<t>The <KeyPackage> element MUST be present and the
<ResponseFormat> element, which is a child element of the
<AlgorithmParameters> element, MUST be used to
indicate the OTP length and the value format.</t>
<t>The <Counter> element (see <xref
target="KeyElement"/>) MUST be provided as meta-data for the
key. </t>
<t>The following additional constraints apply: <list style="symbols">
<t>The value of the <Secret> element MUST contain key
material with a length of at least 16 octets (128 bits),
if it is present.</t>
<t>The <ResponseFormat> element MUST have the
'Format' attribute set to "DECIMAL", and the 'Length'
attribute MUST indicate a length value between 6 and 9.</t>
<t>The <PINPolicy> element MAY be present but the
'PINUsageMode' attribute cannot be set to "Algorithmic".
</t>
</list>
</t>
<t>An example can be found in <xref target="example-suppl"/>. </t>
</list>
</t>
</list>
</t>
</section>
<section title="KEYPROV-PIN" anchor="pin">
<t>
<list style="hanging">
<t hangText="Common Name:"> KEYPROV-PIN </t>
<t hangText="Class:"> Symmetric static credential comparison </t>
<t hangText="URN:">urn:ietf:params:xml:ns:keyprov:pskc#pin</t>
<t hangText="Algorithm Definition:"> (this document) </t>
<t hangText="Identifier Definition"> (this document) </t>
<t hangText="Registrant Contact:"> IESG </t>
<t hangText="Profiling:">
<list style="empty">
<t>The <Usage> element MAY be present but no attribute of the
<Usage> element is required. The <ResponseFormat>
element MAY be used to indicate the PIN value format.</t>
<t>The <Secret> element (see <xref target="KeyElement"
/>) MUST be provided. </t>
<t>See the example in <xref target="example-pin"/>
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section anchor="schema" title="XML Schema">
<t>This section defines the XML schema for PSKC. </t>
<t>
<figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
elementFormDefault="qualified"
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#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACMethod"
type="pskc:MACMethodType" minOccurs="0"/>
<xs:element name="KeyPackage"
type="pskc:KeyPackageType" maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version"
type="pskc:VersionType" use="required"/>
<xs:attribute name="Id"
type="xs:ID" use="optional"/>
</xs:complexType>
<xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer"
type="xs:string" minOccurs="0"/>
<xs:element name="AlgorithmParameters"
type="pskc:AlgorithmParametersType"
minOccurs="0"/>
<xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/>
<xs:element name="KeyReference"
type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/>
<xs:element name="Data"
type="pskc:KeyDataType" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Policy"
type="pskc:PolicyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id"
type="xs:string" use="required"/>
<xs:attribute name="Algorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="KeyUsage"
type="pskc:KeyUsageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="NumberOfTransactions"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyDataType">
<xs:sequence>
<xs:element name="Secret"
type="pskc:binaryDataType" minOccurs="0"/>
<xs:element name="Counter"
type="pskc:longDataType" minOccurs="0"/>
<xs:element name="Time"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeInterval"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeDrift"
type="pskc:intDataType" minOccurs="0"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="binaryDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:base64Binary"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="intDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="stringDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:string"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="longDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:long"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PINPolicyType">
<xs:attribute name="PINKeyId"
type="xs:string" use="optional"/>
<xs:attribute name="PINUsageMode"
type="pskc:PINUsageModeType"/>
<xs:attribute name="MaxFailedAttempts"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MinLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MaxLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="PINEncoding"
type="pskc:ValueFormatType" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<xs:simpleType name="PINUsageModeType">
<xs:restriction base="xs:string">
<xs:enumeration value="Local"/>
<xs:enumeration value="Prepend"/>
<xs:enumeration value="Append"/>
<xs:enumeration value="Algorithmic"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="KeyUsageType">
<xs:restriction base="xs:string">
<xs:enumeration value="OTP"/>
<xs:enumeration value="CR"/>
<xs:enumeration value="Encrypt"/>
<xs:enumeration value="Integrity"/>
<xs:enumeration value="Verify"/>
<xs:enumeration value="Unlock"/>
<xs:enumeration value="Decrypt"/>
<xs:enumeration value="KeyWrap"/>
<xs:enumeration value="Unwrap"/>
<xs:enumeration value="Derive"/>
<xs:enumeration value="Generate"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceInfoType">
<xs:sequence>
<xs:element name="Manufacturer"
type="xs:string" minOccurs="0"/>
<xs:element name="SerialNo"
type="xs:string" minOccurs="0"/>
<xs:element name="Model"
type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo"
type="xs:string" minOccurs="0"/>
<xs:element name="DeviceBinding"
type="xs:string" minOccurs="0"/>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptoModuleInfoType">
<xs:sequence>
<xs:element name="Id" type="xs:string"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyPackageType">
<xs:sequence>
<xs:element name="DeviceInfo"
type="pskc:DeviceInfoType" minOccurs="0"/>
<xs:element name="CryptoModuleInfo"
type="pskc:CryptoModuleInfoType" minOccurs="0"/>
<xs:element name="Key"
type="pskc:KeyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AlgorithmParametersType">
<xs:choice>
<xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Min"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="Max"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="ResponseFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Length"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="ExtensionsType">
<xs:sequence>
<xs:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="definition"
type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MACMethodType">
<xs:sequence>
<xs:choice>
<xs:element name="MACKey"
type="xenc:EncryptedDataType" minOccurs="0"/>
<xs:element name="MACKeyReference"
type="xs:string" minOccurs="0"/>
</xs:choice>
<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="EncryptionScheme"
type="xenc:EncryptionMethodType"/>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
</xs:schema>
]]></artwork>
<postamble/>
</figure>
</t>
</section>
<!-- ****************************************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<section title="Content-type registration for 'application/pskc+xml'">
<t>This specification requests the registration of a new MIME type according to the
procedures of RFC 4288 <xref target="RFC4288"/> and guidelines in RFC 3023 <xref
target="RFC3023"/>.</t>
<t>
<list style="hanging">
<t hangText="MIME media type name:">application </t>
<t hangText="MIME subtype name:">pskc+xml </t>
<t hangText="Mandatory parameters:">none </t>
<t hangText="Optional parameters:">charset<vspace blankLines="1"/> Indicates
the character encoding of enclosed XML. </t>
<t hangText="Encoding considerations:"> Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC 3023 <xref
target="RFC3023"/>, Section 3.2.</t>
<t hangText="Security considerations:"> This content type is designed to
carry PSKC protocol payloads.</t>
<t hangText="Interoperability considerations:">None</t>
<t hangText="Published specification:">RFCXXXX [NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification.] </t>
<t hangText="Applications which use this media type:"> This MIME type is
being used as a symmetric key container format for transport and
provisioning of symmetric keys (One Time Password (OTP) shared secrets
or symmetric cryptographic keys) to different types of strong
authentication devices. As such, it is used for key provisioning
systems. </t>
<t hangText="Additional information:">
<list style="hanging">
<t hangText="Magic Number:">None </t>
<t hangText="File Extension:">.pskcxml </t>
<t hangText="Macintosh file type code:">'TEXT' </t>
</list>
</t>
<t hangText="Personal and email address for further information:">Philip
Hoyer, Philip.Hoyer@actividentity.com </t>
<t hangText="Intended usage:">LIMITED USE </t>
<t hangText="Author:"> This specification is a work item of the IETF KEYPROV
working group, with mailing list address
<keyprov@ietf.org>. </t>
<t hangText="Change controller:"> The IESG <iesg@ietf.org>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t> This section registers an XML schema as per the guidelines in <xref
target="RFC3688"/>.</t>
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:keyprov:pskc</t>
<t hangText="Registrant Contact:">IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com).</t>
<t hangText="XML Schema:">The XML schema to be registered is contained in
<xref target="schema"/>. Its first line is <figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
]]></artwork>
</figure> and its last line is<figure>
<artwork><![CDATA[
</xs:schema>
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration">
<t> This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in <xref
target="RFC3688"/>. </t>
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:keyprov:pskc</t>
<t hangText="Registrant Contact:">IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title>
</head>
<body>
<h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="PSKC Algorithm Profile Registry"
anchor="SymmetricKeyAlgorithmIdentifierRegistry">
<t> This specification requests the creation of a new IANA registry for PSKC
algorithm profiles in accordance with the principles set out in <xref
target="RFC5226">RFC 5226</xref>. </t>
<t> As part of this registry IANA will maintain the following information: </t>
<t>
<list style="hanging">
<t hangText="Common Name:"> The name by which the PSKC algorithm profile is
generally referred. </t>
<t hangText="Class:"> The type of PSKC algorithm profile registry entry
being created, such as encryption, Message Authentication Code (MAC),
One Time Password (OTP), Digest. </t>
<t hangText="URN:"> The URN to be used to identify the profile. </t>
<t hangText="Identifier Definition:"> IANA will be asked to add a pointer to
the specification containing information about the PSKC algorithm
profile registration. </t>
<t hangText="Algorithm Definition:"> A reference to the stable document in
which the algorithm being used with the PSKC is defined. </t>
<t hangText="Registrant Contact:"> Contact information about the party
submitting the registration request. </t>
<t hangText="PSKC Profiling:"> Information about PSKC XML elements and
attributes being used (or not used) with this specific profile of PSKC.
</t>
</list>
</t>
<t> PSKC algorithm profile identifier registrations are to be subject to Expert
Review as per <xref target="RFC5226">RFC 5226</xref>. </t>
<t> IANA is asked to add an initial value to the registry based on the PSKC HOTP
algorithm profile described in <xref target="profiles"/>. </t>
</section>
<section title="PSKC Version Registry">
<t>IANA is requested to create a registry for PSKC version numbers. The registry has
the following structure: <figure>
<artwork><![CDATA[
PSKC Version | Specification
+---------------------------+----------------
| 1.0 | [This document]
]]></artwork>
</figure>
</t>
<t> Standards action is required to define new versions of PSKC. It is not
envisioned to depreciate, delete, or modify existing PSKC versions. </t>
</section>
<section title="Key Usage Registry">
<t>IANA is requested to create a registry for key usage. A description of the
'KeyUsage' element can be found in <xref target="policy"/>. The registry has the
following structure: <figure>
<artwork><![CDATA[
Key Usage Token | Specification
+---------------------------+-------------------------------
| OTP | [Section 5 of this document]
| CR | [Section 5 of this document]
| Encrypt | [Section 5 of this document]
| Integrity | [Section 5 of this document]
| Verify | [Section 5 of this document]
| Unlock | [Section 5 of this document]
| Decrypt | [Section 5 of this document]
| KeyWrap | [Section 5 of this document]
| Unwrap | [Section 5 of this document]
| Derive | [Section 5 of this document]
| Generate | [Section 5 of this document]
+---------------------------+-------------------------------
]]></artwork>
</figure>
</t>
<t>Expert Review is required to define new key usage tokens. Each registration
request has to provide a description of the semantic. Using the same procedure
it is possible to depreciate, delete, or modify existing key usage tokens.</t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section title="Security Considerations">
<t>The portable key container carries sensitive information (e.g., cryptographic keys)
and may be transported across the boundaries of one secure perimeter to another. For
example, a container residing within the secure perimeter of a back-end provisioning
server in a secure room may be transported across the internet to an end-user device
attached to a personal computer. This means that special care must be taken to
ensure the confidentiality, integrity, and authenticity of the information contained
within.</t>
<section title="Payload confidentiality">
<t>By design, the container allows two main approaches to guaranteeing the
confidentiality of the information it contains while transported. </t>
<t>First, the container key data payload may be encrypted.</t>
<t>In this case no transport layer security is required. However, standard security
best practices apply when selecting the strength of the cryptographic algorithm
for payload encryption.
Symmetric cryptographic cipher should be used - the
longer the cryptographic key, the stronger the protection. Please see <xref target="SymmetricKeyProtectionDescription"/> for recommendations of payload protection using symmetric cryptographic ciphers.
In cases where the exchange of key encryption keys
between the sender and the receiver is not possible, asymmetric encryption of
the secret key payload may be employed, see <xref target="AsymmetricKeyProtectionDescription"/> . Similarly to symmetric key cryptography,
the stronger the asymmetric key, the more secure the protection is. </t>
<t>If the payload is encrypted with a method that uses one of the password-based
encryption methods provided above, the payload may be subjected to password
dictionary attacks to break the encryption password and recover the information.
Standard security best practices for selection of strong encryption passwords
apply.</t>
<t>Practical implementations should use PBESalt and PBEIterationCount when PBE
encryption is used. Different PBESalt value per key container should be used for
best protection.</t>
<t>The second approach to protecting the confidentiality of the payload is based on
using transport layer security. The secure channel established between the
source secure perimeter (the provisioning server from the example above) and the
target perimeter (the device attached to the end-user computer) utilizes
encryption to transport the messages that travel across. No payload encryption
is required in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature of the
payload does not encompass the entire payload. </t>
<t>Because of the fact that the plain text payload is protected only by the
transport layer security, practical implementation must ensure protection
against man-in-the-middle attacks. Validating the secure channel end-points is
critically important for eliminating intruders that may compromise the
confidentiality of the payload.</t>
</section>
<section title="Payload integrity">
<t>The portable symmetric key container provides a mean to guarantee the integrity
of the information it contains through digital signatures. For best security
practices, the digital signature of the container should encompass the entire
payload. This provides assurances for the integrity of all attributes. It also
allows verification of the integrity of a given payload even after the container
is delivered through the communication channel to the target perimeter and
channel message integrity check is no longer possible. </t>
</section>
<section title="Payload authenticity">
<t>The digital signature of the payload is the primary way of showing its
authenticity. The recipient of the container may use the public key associated
with the signature to assert the authenticity of the sender by tracing it back
to a preloaded public key or certificate. Note that the digital signature of the
payload can be checked even after the container has been delivered through the
secure channel of communication.</t>
<t>A weaker payload authenticity guarantee may be provided by the transport layer if
it is configured to digest each message it transports. However, no authenticity
verification is possible once the container is delivered at the recipient end.
This approach may be useful in cases where the digital signature of the
container does not encompass the entire payload. </t>
</section>
</section>
<!-- ****************************************************************************************** -->
<section title="Contributors">
<t>We would like Hannes Tschofenig for his text contributions to this document.</t>
</section>
<!-- ****************************************************************************************** -->
<section title="Acknowledgements">
<t> The authors of this draft would like to thank the following people for their
feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart Bajaj, Stu Veath,
Kevin Lewis, Philip Hallam-Baker, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders
Rundgren, Sean Turner and especially Robert Philpott. </t>
<t>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 discussion regarding to the
selection of encryption algorithms (KW-AES-128 vs. AES-128-CBC) and his input on the
keyed message digest computation.</t>
<t>This work is based on earlier work by the members of OATH (Initiative for Open
AuTHentication), see <xref target="OATH"/>, to specify a format that can be freely
distributed to the technical community.</t>
</section>
<!-- ****************************************************************************************** -->
</middle>
<back>
<references title="Normative References">
<reference anchor="PKCS5">
<front>
<title>PKCS #5: Password-Based Cryptography Standard</title>
<author>
<organization> RSA Laboratories </organization>
</author>
<date month="March" year="1999"/>
</front>
<seriesInfo name="Version" value="2.0"/>
<seriesInfo name="URL:" value="http://www.rsasecurity.com/rsalabs/pkcs/"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="">
<organization/>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="XMLDSIG">
<front>
<title>XML-Signature Syntax and Processing</title>
<author initials="D., at al." surname="Eastlake"
fullname="David Eastlake, at al.">
<organization> </organization>
</author>
<date month="February" year="2002"/>
</front>
<seriesInfo name="URL:" value="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/"/>
<seriesInfo name="W3C" value="Recommendation"/>
</reference>
<reference anchor="XMLENC">
<front>
<title>XML Encryption Syntax and Processing.</title>
<author initials="D. Eastlake and J. Reagle." surname="Eastlake"
fullname="D. Eastlake and J. Reagle.">
<organization> </organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="URL:" value="http://www.w3.org/TR/xmlenc-core/"/>
<seriesInfo name="W3C" value="Recommendation"/>
</reference>
<reference anchor="RFC4288">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document defines procedures for the specification and registration
of media types for use in MIME and other Internet protocols. This
document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="4288"/>
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author initials="M." surname="Murata" fullname="M. Murata">
<organization/>
</author>
<author initials="S." surname="St. Laurent" fullname="S. St. Laurent">
<organization/>
</author>
<author initials="D." surname="Kohn" fullname="D. Kohn">
<organization/>
</author>
<date year="2001" month="January"/>
</front>
<seriesInfo name="RFC" value="3023"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="M. Mealling">
<organization/>
</author>
<date year="2004" month="January"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF standards
which use Extensible Markup Language (XML) related items such as
Namespaces, Document Type Declarations (DTDs), Schemas, and Resource
Description Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
</reference>
<reference anchor="RFC4514">
<front>
<title>Lightweight Directory Access Protocol (LDAP): String Representation of
Distinguished Names</title>
<author initials="K." surname="Zeilenga" fullname="K. Zeilenga">
<organization/>
</author>
<date year="2006" month="June"/>
<abstract>
<t>The X.500 Directory uses distinguished names (DNs) as primary keys to
entries in the directory. This document defines the string
representation used in the Lightweight Directory Access Protocol (LDAP)
to transfer distinguished names. The string representation is designed
to give a clean representation of commonly used distinguished names,
while being able to represent any distinguished name.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4514"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="W3C-DKEY"
target="http://www.w3.org/TR/xmlsec-derivedkeys">
<front>
<title>XML Security Derived Keys</title>
<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
<organization/>
</author>
<date year="2009" month="February"/>
</front>
<seriesInfo name="W3C" value="Informational"/>
</reference>
<reference anchor="AESKWPAD"
target="http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt">
<front>
<title>Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm</title>
<author initials="R." surname="Housley">
<organization>Vigil Security</organization>
</author>
<author initials="M." surname="Dworkin">
<organization>NIST</organization>
</author>
<date month="March" year="2009" />
</front>
</reference>
<reference anchor="PSKC-ALGORITHM-PROFILES">
<front>
<title>Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles</title>
<author initials="P." surname="Hoyer" fullname="Philip Hoyer">
<organization/>
</author>
<author initials="M." surname="Pei" fullname="Ming Pei">
<organization/>
</author>
<author initials="S." surname="Machani" fullname="Salah Machani">
<organization/>
</author>
<author initials="A." surname="Doherty" fullname="Andrea Doherty">
<organization/>
</author>
<date year="2008" month="December"/>
</front>
<seriesInfo name="Internet Draft" value="Informational"/>
<seriesInfo name="URL:"
value="http://tools.ietf.org/html/draft-hoyer-keyprov-pskc-algorithm-profiles-00"/>
</reference>
<reference anchor="NIST800-57">
<front>
<title>NIST Special Publication 800-57, Recommendation for Key Management – Part
1: General (Revised)</title>
<author initials="E." surname="Barker" fullname="Elaine Barker">
<organization/>
</author>
<author initials="W." surname="Barker" fullname="William Barker">
<organization/>
</author>
<author initials="W." surname="Burr" fullname="William Burr">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="William Polk">
<organization/>
</author>
<author initials="M." surname="Smid" fullname="Miles Smid">
<organization/>
</author>
<date year="2007" month="March"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-57"/>
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="5226"/>
</reference>
<reference anchor="RFC2396">
<front>
<title>Uniform Resource Identifiers (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization/>
</author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization/>
</author>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization/>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization/>
</author>
<date year="1998" month="August"/>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="2396"/>
</reference>
<reference anchor="LUHN"
target="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=2950048">
<front>
<title>Luhn algorithm</title>
<author initials="H." surname="Luhn" fullname="Hans Peter Luhn">
<organization/>
</author>
<date year="1960" month="August"/>
<abstract>
<t>A a simple checksum formula used to validate a variety of identification
numbers as described in U.S. Patent 2,950,048</t>
</abstract>
</front>
<seriesInfo name="US Patent" value="2950048"/>
<format type="HTML"
target="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=2950048"/>
</reference>
<!-- <reference anchor="AlgorithmURIs">
<front>
<title>Additional XML Security Uniform Resource Identifiers</title>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake">
<organization/>
</author>
<date month="April" year="2005"/>
</front>
<seriesInfo name="RFC" value="4051"/>
</reference>
-->
<reference anchor="CAP">
<front>
<title>Chip Authentication Program Functional Architecture</title>
<author>
<organization> MasterCard International </organization>
</author>
<date month="September" year="2004"/>
</front>
<format type="TXT" octets="94506" target="ftp://ftp.isi.edu/in-notes/rfc2200.txt"/>
</reference>
<reference anchor="DSKPP">
<front>
<title>Dynamic Symmetric Key Provisioning Protocol</title>
<author initials="A." surname="Doherty" fullname="Andrea Doherty">
<organization/>
</author>
<author initials="M." surname="Pei" fullname="Mingliang Pei">
<organization/>
</author>
<author initials="S." surname="Machani" fullname="Salah Machani">
<organization/>
</author>
<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
<organization/>
</author>
<date month="February" year="2008"/>
</front>
<seriesInfo name="Internet Draft" value="Informational"/>
<seriesInfo name="URL:"
value="http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-05.txt"/>
</reference>
<reference anchor="HOTP">
<front>
<title>HOTP: An HMAC-Based One Time Password Algorithm</title>
<author initials="D." surname="MRaihi" fullname="David MRaihi">
<organization/>
</author>
<author initials="M." surname="Bellare" fullname="M. Bellare">
<organization/>
</author>
<author initials="F." surname="Hoornaert" fullname="F. Hoornaert">
<organization/>
</author>
<author initials="D." surname="Naccache" fullname="D. Naccache">
<organization/>
</author>
<author initials="O." surname="Ranen" fullname="O. Ranen">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4226"/>
</reference>
<!--
<reference anchor="PKCS12">
<front>
<title>PKCS #12: Personal Information Exchange Syntax Standard</title>
<author>
<organization> RSA Laboratories </organization>
</author>
<date year=""/>
</front>
<seriesInfo name="Version" value="1.0"/>
<seriesInfo name="URL:" value="http://www.rsasecurity.com/rsalabs/pkcs/"/>
<format type="TXT" octets="94506" target="http://www.ietf.org/rfc/rfc2200.txt"/>
</reference>
-->
<reference anchor="OATH">
<front>
<title>Initiative for Open AuTHentication</title>
<author>
<organization> </organization>
</author>
<date year=""/>
</front>
<seriesInfo name="URL:" value="http://www.openauthentication.org"/>
</reference>
<reference anchor="XMLNS">
<front>
<title>Namespaces in XML</title>
<author>
<organization></organization>
</author>
<date year="1999" month="January"/>
</front>
<seriesInfo name="W3C Recommendation" value=""/>
<seriesInfo name="URL:" value="http://www.w3.org/TR/1999/REC-xml-names-19990114"/>
</reference>
</references>
<section title="Use Cases">
<t>This section describes a comprehensive list of use cases that inspired the
development of this specification. These requirements were used to derive the
primary requirement that drove the design. These requirements are covered in the
next section.</t>
<t>These use cases also help in understanding the applicability of this specification to
real world situations.</t>
<section title="Online Use Cases">
<t>This section describes the use cases related to provisioning the keys using an
online provisioning protocol such as <xref target="DSKPP"/>.</t>
<section title="Transport of keys from Server to Cryptographic Module">
<t>For example, a mobile device user wants to obtain a symmetric key for use
with a Cryptographic Module on the device. The Cryptographic Module from
vendor A initiates the provisioning process against a provisioning system
from vendor B using a standards-based provisioning protocol such as <xref
target="DSKPP"/>. The provisioning entity delivers one or more keys in a
standard format that can be processed by the mobile device.</t>
<t>For example, in a variation of the above, instead of the user's mobile phone,
a key is provisioned in the user's soft token application on a laptop using
a network-based online protocol. As before, the provisioning system delivers
a key in a standard format that can be processed by the soft token on the
PC.</t>
<t>For example, the end-user or the key issuer wants to update or configure an
existing key in the Cryptographic Module and requests a replacement key
container. The container may or may not include a new key and may include
new or updated key attributes such as a new counter value in HOTP key case,
a modified response format or length, a new friendly name, etc.</t>
</section>
<section title="Transport of keys from Cryptographic Module to Cryptographic Module">
<t>For example, a user wants to transport a key from one Cryptographic Module to
another. There may be two cryptographic modules, one on a computer one on a
mobile phone, and the user wants to transport a key from the computer to the
mobile phone. The user can export the key and related data in a standard
format for input into the other Cryptographic Module.</t>
</section>
<section title="Transport of keys from Cryptographic Module to Server">
<t>For example, a user wants to activate and use a new key and related data
against a validation system that is not aware of this key. This key may be
embedded in the Cryptographic Module (e.g. SD card, USB drive) that the user
has purchased at the local electronics retailer. Along with the
Cryptographic Module, the user may get the key on a CD or a floppy in a
standard format. The user can now upload via a secure online channel or
import this key and related data into the new validation system and start
using the key.</t>
</section>
<section title="Server to server Bulk import/export of keys">
<t>From time to time, a key management system may be required to import or
export keys in bulk from one entity to another. </t>
<t>For example, instead of importing keys from a manufacturer using a file, a
validation server may download the keys using an online protocol. The keys
can be downloaded in a standard format that can be processed by a validation
system.</t>
<t>For example, in a variation of the above, an Over-The-Aire (OTA) key
provisioning gateway that provisions keys to mobile phones may obtain 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 provisioning gateway
and subsequently sent to the end-user's mobile phone.</t>
</section>
</section>
<section title="Offline Use Cases">
<t>This section describes the use cases relating to offline transport of keys from
one system to another, using some form of export and import model. </t>
<section title="Server to server Bulk import/export of keys">
<t>For example, Cryptographic Modules such as OTP authentication tokens, may
have their symmetric keys initialized during the manufacturing process in
bulk, requiring copies of the keys and algorithm data to be loaded into the
authentication system through a file on portable media. The manufacturer
provides the keys and related data in the form of a file containing records
in standard format, typically on a CD. Note that the token manufacturer and
the vendor for the validation system may be the same or different. Some
crypto modules will allow local PIN management (the device will have a PIN
pad) hence random initial PINs set at manufacturing should be transmitted
together with the respective keys they protect.</t>
<t>For example, an enterprise wants to port keys and related data from an
existing validation system A into a different validation system B. The
existing validation system provides the enterprise with a functionality that
enables export of keys and related data (e.g. for OTP authentication tokens)
in a standard format. Since the OTP tokens are in the standard format, the
enterprise can import the token records into the new validation system B and
start using the existing tokens. Note that the vendors for the two
validation systems may be the same or different. </t>
</section>
</section>
</section>
<section title="Requirements">
<t>This section outlines the most relevant requirements that are the basis of this work.
Several of the requirements were derived from use cases described above. <list
style="format R%d:">
<t>The format MUST support transport of multiple types of symmetric keys and
related attributes for algorithms including HOTP, other OTP,
challenge-response, etc.</t>
<t>The format MUST handle the symmetric key itself as well of attributes that
are typically associated with symmetric keys. Some of these attributes may
be <list style="symbols">
<t>Unique Key Identifier</t>
<t>Issuer information</t>
<t>Algorithm ID</t>
<t>Algorithm mode</t>
<t>Issuer Name</t>
<t>Key friendly name</t>
<t>Event counter value (moving factor for OTP algorithms)</t>
<t>Time value</t>
</list>
</t>
<t>The format SHOULD support both offline and online scenarios. That is it
should be serializable to a file as well as it should be possible to use
this format in online provisioning protocols such as <xref target="DSKPP"/></t>
<t>The format SHOULD allow bulk representation of symmetric keys</t>
<t>The format SHOULD allow bulk representation of PINs related to specific keys</t>
<t>The format SHOULD be portable to various platforms. Furthermore, it SHOULD be
computationally efficient to process.</t>
<t>The format MUST provide appropriate level of security in terms of data
encryption and data integrity. </t>
<t>For online scenarios the format SHOULD NOT rely on transport level security
(e.g., SSL/TLS) for core security requirements.</t>
<t>The format SHOULD be extensible. It SHOULD enable extension points allowing
vendors to specify additional attributes in the future.</t>
<t>The format SHOULD allow for distribution of key derivation data without the
actual symmetric key itself. This is to support symmetric key management
schemes that rely on key derivation algorithms based on a pre-placed master
key. The key derivation data typically consists of a reference to the key,
rather than the key value itself.</t>
<t>The format SHOULD allow for additional lifecycle management operations such
as counter resynchronization. Such processes require confidentiality between
client and server, thus could use a common secure container format, without
the transfer of key material.</t>
<t>The format MUST support the use of pre-shared symmetric keys to ensure
confidentiality of sensitive data elements. </t>
<t>The format MUST support a password-based encryption (PBE) <xref
target="PKCS5"/> scheme to ensure security of sensitive data elements.
This is a widely used method for various provisioning scenarios.</t>
<t>The format SHOULD support asymmetric encryption algorithms such as RSA to
ensure end-to-end security of sensitive data elements. This is to support
scenarios where a pre-set shared key encryption key is difficult to use.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:18:46 |