keyprov                                                         P. Hoyer
Internet-Draft                                             ActivIdentity
Intended status: Standards Track                                  M. Pei
Expires: August 26, December 11, 2009                                      VeriSign
                                                              S. Machani
                                                              Diversinet
                                                       February 22,
                                                            June 9, 2009

                Portable Symmetric Key Container (PSKC)
                     draft-ietf-keyprov-pskc-02.txt
                       draft-ietf-keyprov-pskc-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 26, December 11, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies a symmetric key format for transport and
   provisioning of symmetric keys (for to different types of crypto modules.
   For example One Time Password (OTP) shared secrets or symmetric
   cryptographic keys) keys to different types of
   crypto modules, such as a strong authentication device. devices.  The standard
   key transport format enables enterprises to deploy best-of-breed
   solutions combining components from different vendors into the same
   infrastructure.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology
     1.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Versions .  5
   3.  Portable Key Container Entities Overview and Relationships . .  6
   4.  <KeyContainer> Element: The Basics . . . . . . . . . . . . . .  8
     4.1.  <DeviceInfo> Element: Unique Device Identification . . . .  9
     4.2.  <Key>: Embedding Keying Material . . . .  4
     1.3.  Namespace Identifiers  . . . . . . . . . 10
     4.3.  <User> Element: User Identification . . . . . . . . .  4
       1.3.1.  Defined Identifiers  . . 11
     4.4.  <Usage> Element: Supplementary Information for OTP and
           CR Algorithms . . . . . . . . . . . . . . .  4
       1.3.2.  Referenced Identifiers . . . . . . . 12
   5.  Policy . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . 14
   6.  Protection of Keys and Related Data . . . . . .  6
   3.  Portable Key Container Entities Overview and Relationships . .  7
   4.  <KeyContainer> Element: The Basics . . . . . 19
     6.1.  Encryption based on Pre-Shared Keys . . . . . . . . .  9
     4.1.  <Key>: Embedding Keying Material and Key Related
           Information  . . 19
     6.2.  Encryption based on Passphrase-based Keys . . . . . . . . 22
     6.3.  Encryption based on Asymmetric Keys . . . . . . . . . . . 24
     6.4. . .  9
     4.2.  Transmission of Key Derivation Values supplementary Information  . . . . . . . . 11
       4.2.1.  <DeviceInfo> Element: Unique Device Identification . . 26
   7.  Digital Signature 12
       4.2.2.  <CryptoModuleInfo> Element: CryptoModule
               Identification . . . . . . . . . . . . . . . . . . . . 13
       4.2.3.  <UserId> Element: User Identification  . . 28
   8.  Bulk Provisioning . . . . . . 14
       4.2.4.  <AlgorithmParameters> Element: Supplementary
               Information for OTP and CR Algorithms  . . . . . . . . 14
     4.3.  Transmission of Key Derivation Values  . . . . . . . . 30
   9.  Extensibility . . 16
   5.  Key policy - transmission of key usage policies and key
       PIN protection policy  . . . . . . . . . . . . . . . . . . . . 18
   6.  Key protection methods . . 33
   10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . 23
     6.1.  Encryption based on Pre-Shared Keys  . . 34
     10.1. HOTP . . . . . . . . . 23
       6.1.1.  MAC Method . . . . . . . . . . . . . . . . . . 34
     10.2. KEYPROV-PIN . . . . 25
     6.2.  Encryption based on Passphrase-based Keys  . . . . . . . . 26
     6.3.  Encryption based on Asymmetric Keys  . . . . . . . . . . . 34
   11. XML Schema 29
     6.4.  Padding of encrypted values for non-padded encryption
           algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30
   7.  Digital Signature  . . 36
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
   8.  Bulk Provisioning  . 43
     12.1. Content-type registration for 'application/pskc+xml' . . . 43 . . . . . . . . . . . . . . . . . . 33
   9.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 36
   10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37
     10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     10.2. KEYPROV-PIN  . . . . . . . . . . . . . . . . . . . . . . . 37
   11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 46
     12.1. Content-type registration for 'application/pskc+xml' . . . 46
     12.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 44 47
     12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44 47
     12.4. PSKC Algorithm Profile Registry  . . . . . . . . . . . . . 45 48
     12.5. PSKC Version Registry  . . . . . . . . . . . . . . . . . . 46 49
     12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46 49
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 48 51
     13.1. Payload confidentiality  . . . . . . . . . . . . . . . . . 48 51
     13.2. Payload integrity  . . . . . . . . . . . . . . . . . . . . 49 52
     13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 49 52
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 53
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 54
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 55
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 52 55
     16.2. Informative References . . . . . . . . . . . . . . . . . . 52 55
   Appendix A.  Use Cases . . . . . . . . . . . . . . . . . . . . . . 54 57
     A.1.  Online Use Cases . . . . . . . . . . . . . . . . . . . . . 54 57
       A.1.1.  Transport of keys from Server to Cryptographic
               Module . . . . . . . . . . . . . . . . . . . . . . . . 54 57
       A.1.2.  Transport of keys from Cryptographic Module to
               Cryptographic Module . . . . . . . . . . . . . . . . . 54 57
       A.1.3.  Transport of keys from Cryptographic Module to
               Server . . . . . . . . . . . . . . . . . . . . . . . . 55 58
       A.1.4.  Server to server Bulk import/export of keys  . . . . . 55 58
     A.2.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . . 55 58
       A.2.1.  Server to server Bulk import/export of keys  . . . . . 55 58
   Appendix B.  Requirements  . . . . . . . . . . . . . . . . . . . . 57 60
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 62

1.  Introduction

   With increasing use of symmetric key based authentication systems, such as
   encryption of data at rest or systems used for strong authentication
   such as those based one time password 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 systems, thus making it hard to use
   tokens from vendor "Foo" with a server from vendor "Bar".

   This document proposes defines a standardized XML-based key container, called
   Portable Symmetric Key Container (PSKC), for transporting symmetric
   keys and key related meta data.  This  The document also specifies the
   information elements that are may be required for computing when the initial event symmetric key is
   utilized for specific purposes, such as the initial counter
   used by in the
   MAC-Based One Time Password Algorithm (HOTP) algorithm [HOTP] and these elements are algorithm.  It also applicable
   requests the creation of a IANA registry for other time-based
   algorithms.

2.  Terminology algorithm profiles where
   algorithms, their related meta-data and PSKC transmission profile can
   be recorded for centralised standardised reference.

1.1.  Key Words

   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 [RFC2119].

1.2.  Versions

   There is a provision made in the syntax for an explicit version
   number.  Only version "1.0" is currently specified.

1.3.  Namespace Identifiers

   This document uses Uniform Resource Identifiers [RFC2396] to identify
   resources, algorithms, and semantics..

1.3.1.  Defined Identifiers

   The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:

   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"

   References to qualified elements in the PSKC schema defined herein
   use the prefix "pskc".

1.3.2.  Referenced Identifiers

   The PSKC syntax presented in this document relies on algorithm
   identifiers and elements defined in the XML Signature [XMLDSIG]
   namespace:

   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

   References to the XML Signature namespace are represented by the
   prefix "ds".

   PSKC also relies on algorithm identifiers and elements defined in the
   XML Encryption [XMLENC] namespace:

   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"

   References to the XML Encryption namespace are represented by the
   prefix "xenc".

   When protecting keys in transport with passphrase-based keys, PSKC
   also relies on the derived key element defined in the W3C Derived Key
   [W3C-DKEY] namespace:

   xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"

   References to the W3C Derived Key namespace are represented by the
   prefix "dkey".

   When protecting keys in transport with passphrase-based keys, PSKC
   also relies on algorithm identifiers and elements defined in the
   PKCS#5 [PKCS5] namespace:

   xmlns:pkcs5=
   "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"

   References to the PKCS#5 namespace are represented by the prefix
   "pkcs5".

2.  Terminology

   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.

3.  Portable Key Container Entities Overview and Relationships

   The portable key container is based on an XML schema definition and
   contains the following main conceptual entities:

   1.  KeyContainer entity - representing the container that carries the
       keys a
       number of KeyPackages

   2.  Device  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 where
       the keys reside optionally bound to and a specific user CryptoModule

   3.  DeviceInfo entity - representing the information about the device
       and criteria to uniquely identify the device

   4.  CryptoModuleInfo entity - representing the information about the
       CryptoModule where the keys reside or are provisioned to

   5.  Key entity - representing the key transmitted

   5.  KeyData transported or provisioned

   6.  Data entity - representing data a list of meta-data related to the key including
       value either in plain or encrypted

   Figure 1 shows
       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')

   Figure 1 shows the high-level structure of the PSKC data elements.

      +---------------+

      -----------------
      | KeyContainer  |
      +---------------+
      |---------------|
      | EncryptionKey |
      | Signature     |
      | ...           |
      +---------------+
      -----------------
              |
              |
             /|\ 1..n
      +--------------+     +--------------+
      ----------------        ----------------
      | Device KeyPackage   |    1|    0..1| DeviceInfo   |
      +--------------+-----+--------------+
      | User
      |--------------|--------|--------------|
      |              |--      | SerialNumber |
      +--------------+
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |            +--------------+         |     ----------------
             /|\ 1..n
      +--------------+ 0..1   |
      ----------------  |     --------------------
      | Key          |
      +--------------+  | ID 0..1| CryptoModuleInfo |
      |--------------|   -----|------------------|
      | Id           |        | Id               |
      | Algorithm    |        |....              | User
      | UserId       |        --------------------
      | Policy       |
      | ....         |
      +--------------+
      ----------------
              |
              |
             /|\ 1..n      +------------+
      +--------------+ 0..n
          --------------------------------------- -  -
          | Plainvalue                     |              | KeyData
      ------------------  ----------------  -------- - -
      |     +----+-------+
      +--------------+ Data:Secret    |  | name Data:Counter |    either|  | value        +----------+ Data:other
      |----------------|  |--------------|  |-- - -
      | ..... EncryptedValue |   +------+---------+
      +--------------+  | EncryptedValue PlainValue   |
                         +----------------+
      | ValueMAC       |  ----------------
      ------------------

                                 Figure 1

   The following sections describe in detail all the entities and
   related XML schema elements and attributes.

4.  <KeyContainer> Element: The Basics

   In it's its most basic form form, a PSKC document uses the top-level element
   <KeyContainer> and a single <Device> <KeyPackage> element to carry key
   information.

   The following example shows such a simple PSKC document.  We will use
   it to describe the structure of the <KeyContainer> element and it's its
   child elements.

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0" id="exampleID1"
       Id="exampleID1"
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <Device>
           <DeviceInfo>
               <Manufacturer>Manufacturer</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
       <KeyPackage>
           <Key KeyId="12345678"
           KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage> Id="12345678"
               Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
               <Issuer>Issuer-A</Issuer>
               <Data>
                   <Secret>
                       <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
                       <PlainValue>MTIzNA==
                       </PlainValue>
                   </Secret>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
           </Key>
       </Device>
       </KeyPackage>
   </KeyContainer>

                Figure 2: Basic PSKC Key Container Example

   The attributes of the <KeyContainer> element have the following
   semantic:
   semantics:

   '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.

   'ID:'

   'Id:'  The 'ID' 'Id' attribute carries a unique identifier for the
      container.  As such, it helps to identify a specific key
      container.

   A <KeyContainer> element MUST contain at least one <Device> element.
   Multiple <Device> elements can be used container
      in cases when for bulk provisioning,
   see Section 8.  A <Device> MUST contain at least one <Key> element.
   A <Device> MAY be bound to a user.  A key SHOULD be bound to only one
   <Device> element. multiple containers are embedded in larger xml
      documents.

4.1.  <DeviceInfo> Element: Unique Device Identification  <Key>: Embedding Keying Material and Key Related Information

   The <DeviceInfo> element uniquely identifies the device following attributes of the <Key> element refers to.  Since devices can come in different form factors,
   such as hardware tokens, smart-cards, soft tokens in MUST be included at a mobile phone
   or as
   minimum:

   'Id':  This attribute carries a PC, this element allows different criteria to be used.
   Combined though the criteria MUST uniquely identify the device.  For
   example, globally unique identifier for hardware tokens the combination
      symmetric key.  The identifier is defined as a string of <SerialNo> and
   <Manufacturer> elements uniquely identifies
      alphanumeric characters.

   'Algorithm':  This attribute contains a device but unique identifier for the
   <SerialNo> element alone is insufficient since two different token
   manufacturers might issue devices with
      PSKC algorithm profile.  This profile associates specific
      semantics to the same serial number
   (similar to the Issuer Distinguished Name elements and serial number of a
   certificate).

   The <DeviceInfo> element has attributes contained in the following child elements:

   <Manufacturer>: <Key>
      element.  This element indicates the manufacturer of document describes profiles for open standards
      algorithms in Section 10.  Additional profiles are defined in the
      device.

   <SerialNo>:  This
      following information draft [PSKC-ALGORITHM-PROFILES]

   The <Key> element contains the serial has a number of the device.

   <Model>: optional child elements.  An
   initial set is described below:

   <Issuer>:  This element describes represents the model name of the device (e.g., one-
      button-HOTP-token-V1).

   <IssueNo>:  This element contains the issue number in case devices
      with the same serial number party that are distinguished by different
      issue numbers.

   <DeviceBinding>:  In issued
      the key.  For example, a number of cases access bank "Foobar Bank Inc." issuing hardware
      tokens to lower layer device
      identifiers, such as a serial number, from a PSKC implementation
      is difficult or not possible.  For their retail banking users may set this purpose an opaque
      identifier, carried in element to
      "Foobar Bank Inc.".

   <FriendlyName>:  A human readable name for the <DeviceBinding> element, is introduced secret key for easier
      reference.  This element serves informational purposes only.

   <AlgorithmParameters>:  This element carries parameters that allows to bind keys to
      influence the device or to a class result of devices.
      When loading keys into a device, the value algorithmic computation, for example
      response truncation and format in OTP and CR algorithms.  A more
      detailed discussion of the <DeviceBinding> element MUST can be checked against information provided found in Section 4.2.4.

   <Data>:  This element carries data about and related to the user
      via out-of-band mechanisms. key.  The implementation then ensures that
      following child elements are defined for the correct device or class of device is being used with respect
      to the provisioned key.

   <StartDate>: and <ExpiryDate>:  These two elements indicates 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.

   Depending on <Data> element:

      <Secret>:  This element carries the device type certain child elements value of the
   <DeviceInfo> element are necessary to include key itself in order to uniquely
   identify a device.
         binary representation.

      <Counter>:  This document does not enumerate the different
   device types and therefore does not list element contains the elements that are
   mandatory event counter for each type of device.

4.2.  <Key>: Embedding Keying Material

   The following attributes of event
         based OTP algorithms.

      <Time>:  This element contains the <Key> time for time based OTP
         algorithms.  (If time interval is used, this element MUST be included at carries
         the number of time intervals passed from a
   minimum:

   'KeyId': specific start
         point, normally algorithm dependent)

      <TimeInterval>:  This attribute element carries a globally unique identifier for the
      symmetric key.  The identifier is defined as a string of
      alphanumeric characters.

   'KeyAlgorithm': time interval value for
         time based OTP algorithms.

      <TimeDrift>:  This attribute element contains a unique identifier for the
      PSKC algorithm profile.  This profile associates a specific
      semantic to device clock drift value
         for time-based OTP algorithms.  The value indicates the elements and attributes contained in number
         of seconds that the <Key>
      element.  More information about device clock may drift each day.

      All the PSKC algorithm profile
      defined in this document can be found in Section 10.

   The <Key> element has a number of optional child elements.  An
   initial set is described below:

   <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.".

   <FriendlyName>:  A human readable name for the secret key for easier
      reference.  This element serves informational purposes only.

   <Usage>:  This element provides supplementary information for usage
      with OTP and CR algorithms.  A more detailed discussion of the
      element can be found in Section 4.4.

   <Data>:  This element carries data about and related to the key.  The
      follow child elements are defined for the <Data> element:

      <Secret>:  This element carries the value of the key itself in a
         binary representation.

      <Counter>:  This element contains the event counter for event
         based OTP algorithms.

      <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)

      <TimeInterval>:  This element carries the time interval value for
         time based OTP algorithms.

      <TimeDrift>:  This element contains the device clock drift value
         for time based OTP algorithms.  The value indicates number of
         seconds that the device clock may drift each day.

      All these elements listed above (and those elements listed above (and those defined in the future)
      obey a simple structure in that they MUST support child elements
      to convey the content data value in either plaintext and in or encrypted format:

      Plain Text:

      Plaintext:  The <PlainValue> element carries plaintext content value that
         is typed, for example to xs:integer.

      Encrypted Content:

      Encrypted:  The <EncryptedValue> element carries encrypted
         content. value

      Additionally, it MUST be possible to carry a <ValueMac> element,
      which is populated with a MAC generated from the unencrypted encrypted value
      in case the encryption algorithm does not support integrity
      checks, MAY be included as a child element.  The example shown at Figure 2
      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.

4.3.  <User> Element: User Identification

   The <User> element identifies the user

4.2.  Transmission of the device using a
   distinguished name, as defined in [RFC4514].  For example:
   UID=jsmith,DC=example,DC=net

   There is no semantic associated with this element, i.e., there are no
   checks enforcing that only supplementary Information

   A PSKC document can contain a specific number of additional information
   regarding device identification, cryptomodule identification, user can use this key.  As
   such, this element is for informational purposes only.

4.4.  <Usage> Element: Supplementary Information
   identification and parameters for usage with OTP and CR
      Algorithms algorithms.
   The <Usage> element following example, see Figure 3, is used as a child element of reference for the <Key>
   subsequent sub-sections.

   <?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>

       Figure 3: PSKC Key Container Example with Supplementary Data

4.2.1.  <DeviceInfo> Element: Unique Device Identification

   The <DeviceInfo> element and 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
   document defines two element allows different child elements: <ChallengeFormat> and
   <ResponseFormat>

   <ChallengeFormat>:

      The <ChallengeFormat> element defines
   combinations to be used.  When combined, the characteristics values of the
      challenge in a CR usage scenario whereby child
   elements MUST uniquely identify the following attributes
      are defined:

      'Encoding':  This mandatory attribute defines device.  For example, for
   hardware tokens the encoding combination of <SerialNo> and <Manufacturer>
   elements uniquely identifies a device but the
         challenge accepted by <SerialNo> element
   alone is insufficient since two different token manufacturers might
   issue devices with the device same serial number (similar to the Issuer
   Distinguished Name and MUST be one serial number of a certificate).

   The <DeviceInfo> element has the following values:

         DECIMAL  Only numerical digits

         HEXADECIMAL  Hexadecimal response

         ALPHANUMERIC  All letters and numbers (case sensitive)

         BASE64  Base 64 encoded

         BINARY  Binary data

      'CheckDigit': child elements:

   <Manufacturer>:  This optional attribute element indicates whether a device
         needs to check the appended Luhn check digit, as defined in
         [LUHN], contained in a provided challenge. manufacturer of the
      device.

   <SerialNo>:  This is only valid
         if element contains the 'Encoding' attribute is 'DECIMAL'.  A value serial number of TRUE
         indicates that the device will check device.

   <Model>:  This element describes the appended Luhn check
         digit in a provided challenge.  A value model of indicates that the device will not check appended Luhn check digit in challenge.

      'Min': (e.g., one-
      button-HOTP-token-V1).

   <IssueNo>:  This mandatory attribute defines element contains the minimum size of issue number in case devices
      with the
         challenge accepted same serial number that are distinguished by the different
      issue numbers.

   <DeviceBinding>:  In a number of cases access to lower layer device for CR mode.  If the
         'Encoding' attribute
      identifiers, such as a serial number, from a PSKC implementation
      is 'DECIMAL', 'HEXADECIMAL' difficult or
         'ALPHANUMERIC' impossible.  For this value indicates the minimum number of
         digits/characters.  If purpose an opaque
      identifier, carried in the 'Encoding' attribute <DeviceBinding> element, is 'BASE64' or
         'BINARY', this value indicates introduced
      that allows to bind keys to the minimum number of bytes device or to a class of devices.
      When loading keys into a device, the unencoded value.

      'Max':  This mandatory attribute defines the maximum size value of the
         challenge accepted by <DeviceBinding>
      element MUST be checked against information provided to the device for CR mode.  If user
      via out-of-band mechanisms.  The implementation then ensures that
      the
         'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' correct device or
         'ALPHANUMERIC' this value indicates the maximum number class of
         digits/characters.  If the 'Encoding' attribute device is 'BASE64' or
         'BINARY', this value indicates the maximum number of bytes of being used with respect
      to the unencoded value.

   <ResponseFormat>:

      The <ResponseFormat> element defines provisioned key.

   <StartDate>: and <ExpiryDate>:  These two elements indicate the characteristics start
      and end date of a device (such as the
      result of one on a computation 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 defines
      MUST NOT generate time instants that specify leap seconds.

   Depending on the format device type certain child elements of the OTP or the
      response
   <DeviceInfo> element MUST be included in order to uniquely identify a challenge.  For cases where the key is a PIN value,
      this element contains
   device.  This document does not enumerate the format of different device types
   and therefore does not list the PIN itself (e.g., DECIMAL,
      length 4 elements that are mandatory for a 4 digit PIN). each
   type of device.

4.2.2.  <CryptoModuleInfo> Element: CryptoModule Identification

   The following attributes <CryptoModuleInfo> element identifies the cryptographic module to
   which the symmetric keys are
      defined:

      'Encoding': or have been provisioned to.  This mandatory attribute defines
   allows the encoding identification of the
         response generated by the specific cases where a device and MUST be MAY
   contain more than one of the
         following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,
         or BINARY.

      'CheckDigit': crypto module (e.g. a PC hosting a TPM and a
   connected token)

   The <CryptoModuleInfo> element has a single mandatory child element:

   <Id>:  This optional attribute indicates whether element carries a unique identifier for the
         device needs CryptoModule
      and is implementation specific.  As such, it helps to append identify a Luhn check digit, as defined in
         [LUHN],
      specific CryptoModule to which the response.  This is only valid if the 'Encoding'
         attribute is 'DECIMAL'.  If the value key is TRUE then being or was
      proivisioned.

4.2.3.  <UserId> Element: User Identification

   The <UserId> element identifies the device
         will append user using a Luhn check digit to distinguished name,
   as defined in [RFC4514].  For example: UID=jsmith,DC=example,DC=net

   Although the response.  If syntax of the value user identifier is FALSE then the device will not append defined there are no
   semantics associated with this element, i.e., there are no checks
   enforcing that only a Luhn check digit to
         the response.

      'Length': specific user can use this key.  As such, this
   element is for informational purposes only.

   This mandatory attribute defines the length element may appear in two places, namely as a child element of
   the
         response generated by the device.  If the 'Encoding' attribute
         is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value <Key> element where it indicates the number of digits/characters.  If user with whom the 'Encoding'
         attribute key is 'BASE64' or 'BINARY', this value indicates the
         number of bytes of the unencoded value.

5.  Policy

   This section illustrates the functionality
   associated with and as a child element of the <Policy> <DeviceInfo> element
   within PSKC
   where it indicates that allows policy to be attached to a key the entity the device belongs to.

4.2.4.  <AlgorithmParameters> Element: Supplementary Information for OTP
        and related
   meta data.  This CR Algorithms

   The <AlgorithmParameters> element is a child element of the <Key> element.

   If the <Policy>
   element contains and this document defines two child elements or values within
   elements/attributes that are not understood by elements:
   <ChallengeFormat> and <ResponseFormat>

   <ChallengeFormat>:

      The <ChallengeFormat> element defines the recipient characteristics of the
   PSKC document then the recipient MUST assume that key
      challenge in a CR usage is not
   permitted.  This statement ensures that scenario whereby the lack of understanding following attributes
      are defined:

      'Encoding':  This mandatory attribute defines the encoding of
   certain extension does not lead to unintended key usage.

   We will start our description with an example that expands the
   example shown in Figure 3.

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0" id="exampleID1"
     xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <Device>
           <DeviceInfo>
               <Manufacturer>Manufacturer</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
           <Key KeyId="12345678"
           KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage>
               <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>
           <Key KeyId="123456781"
             KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#pin">
               <Issuer>Issuer</Issuer>
               <Usage>
                   <ResponseFormat Length="4" Encoding="DECIMAL"/>
               </Usage>
               <Data>
                   <Secret>
                       <PlainValue>MTIzNA==</PlainValue>
                   </Secret>
               </Data>
           </Key>
       </Device>
   </KeyContainer>

         Figure 3: Non-Encrypted HOTP Secret Key protected
         challenge accepted by PIN

   This document defines the following elements:

   <StartDate> device and <ExpiryDate>:  These two elements denote the validity
      period of a key.  It MUST be ensured that the key is only used
      between one of the start
         following values:

         DECIMAL  Only numerical digits

         HEXADECIMAL  Hexadecimal response

         ALPHANUMERIC  All letters and numbers (case sensitive)

         BASE64  Base 64 encoded
         BINARY  Binary data

      'CheckDigit':  This optional attribute indicates whether a device
         needs to check the end date (inclusive).  The value MUST be
      expressed appended Luhn check digit, as defined 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
         [LUHN], contained in a challenge.  This is absent then only valid if the current time
         'Encoding' attribute is
      assumed as a start time.

   <NumberOfTransactions>:  The 'DECIMAL'.  A value in this element of TRUE indicates a
      restriction regarding
         that the number of times a key carried within device will check the
      PSKC document can be applied.  When 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.

      '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 element value indicates the minimum number of
         digits/characters.  If the 'Encoding' attribute is omitted then
      there 'BASE64' or
         'BINARY', this value indicates the minimum number of bytes of
         the unencoded value.

      'Max':  This mandatory attribute defines the maximum size of the
         challenge accepted by the device for CR mode.  If the
         'Encoding' attribute is no restriction regarding 'DECIMAL', 'HEXADECIMAL' or
         'ALPHANUMERIC' this value indicates the maximum number of times a key
         digits/characters.  If the 'Encoding' attribute is
      used.

   <KeyUsage>:  The <KeyUsage> element puts constraints on 'BASE64' or
         'BINARY', this value indicates the intended
      usage maximum number of bytes of
         the key. unencoded value.

   <ResponseFormat>:

      The recipient <ResponseFormat> element defines the characteristics of the PSKC document MUST enforce
      result of a computation and defines the key usage.  Currently, format of the following tokens are registered by
      this document:

      OTP:  The key MUST only be used for OTP generation.

      CR:  The key MUST only be used for Challenge/Response purposes.

      Encrypt:  The key MUST only be used for data encryption purposes.

      Integrity:  The key MUST only be used to generate a keyed message
         digest for data integrity or authentication purposes.

      Unlock:  The key MUST only be used for an inverse challenge
         response in the case
      response to a user has locked challenge.  For cases where the device by entering key is a
         wrong PIN too many times (for devices with PIN-input
         capability).

      Decrypt:  The key MUST only be used for data decryption purposes.

      KeyWrap:  The key MUST only be used for key wrap purposes.

      Unwrap:  The key MUST only be used for key unwrap purposes.

      Derive:  The key MUST only be used with a key derivation function
         to derive a new key (see also Section 8.2.4 of [NIST]).

      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[NIST]).

      Verify:  The key MUST only be used to verify the digest or
         signatures ( is the vice verso of Integrity)

      The element MAY also be repeated to allow several key usages to be
      expressed.  When value,
      this element is absent then no key usage
      constraint is assumed, i.e., contains the key MAY be utilized for every
      usage.

   <PINPolicy>:  The <PINPolicy> element allows policy about format of the PIN
      usage to be associated with the key. itself (e.g., DECIMAL,
      length 4 for a 4 digit PIN).  The following attributes are
      specified:

      'PINKeyId':
      defined:

      'Encoding':  This mandatory attribute contains defines the unique key id encoding of the key
         held within this container that contains
         response generated by the value device and MUST be one of the PIN
         that protects the key.

      'PINUsageMode':
         following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,
         or BINARY.

      'CheckDigit':  This mandatory optional attribute indicates whether the way
         device needs to append a Luhn check digit, as defined in
         [LUHN], to the
         PIN response.  This is used during only valid if the usage of 'Encoding'
         attribute is 'DECIMAL'.  If the key.  The following values
         are defined:

         Local:  This value indicates that the PIN is checked locally on TRUE then the device before allowing the key to be used in executing
            the algorithm.

         Prepend:  This value indicates that the PIN is prepended to the
            OTP or response hence it MUST be checked by the validation
            server.

         Append:  This value indicates that the PIN is appended
         will append a Luhn check digit to the
            OTP or response hence it MUST be checked by response.  If the validation
            server.

         Algorithmic:  This value indicates that the PIN
         is used as part
            of the algorithm computation.

      'MaxFailedAttempts':  This attribute indicates the maximum number
         of times FALSE, then the PIN can be entered wrongly before it MUST NOT be
         possible device will not append a Luhn check digit to use
         the key anymore.

      'MinLength': response.

      'Length':  This mandatory attribute indicates defines the minimum length of a PIN
         that can be set to protect this key.  It MUST NOT be possible
         to set a PIN shorter than this value. the
         response generated by the device.  If the 'PINFormat' 'Encoding' attribute
         is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
         indicates the number of digits/characters.  If the
         'PINFormat' 'Encoding'
         attribute is 'BASE64' or 'BINARY', this value indicates the
         number of bytes of the unencoded value.

      'MaxLength':  This attribute indicates the maximum lenght

4.3.  Transmission 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 Key Derivation Values

   <KeyProfileId> element, which is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
         value indicates the number a child element of digits/characters.  If the
         'PINFormat' attribute is 'BASE64' or 'BINARY', this value
         indicates <Key>
   element, carries a unique identifier used between the number of bytes sending and
   receiving parties to establish a set of the unencoded value.

      'PINEncoding':  This key attribute indicates values that are
   not transmitted within the encoding of container but agreed between the PIN
         and MUST be one two
   parties out of band.  This element will then represent the values: DECIMAL, HEXADECIMAL,
         ALPHANUMERIC, BASE64, or BINARY.

      If the 'PinUsageMode' attribute is unique
   reference to a set of key attribute values.  (For example, a smart
   card application personalisation profile id related to "Local" then the device
      MUST enforce the restriction indicated in the 'MaxFailedAttempts',
      'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it
      MUST be enforced attributes
   present on a smart card application that have influence when
   computing a response.)  Likewise, the server side.

6.  Protection of Keys sending and Related Data

   With the functionality described in the previous sections information
   related to keys had receiving parties,
   might agree to be transmitted in clear text.  With the help a set of values related to the <EncryptionKey> element, which is MasterCard's Chip
   Authentication Protocol [CAP].

   For example, sending and receiving party would agree that
   KeyProfileId='1' would represent a child element certain set of the
   <KeyContainer> element, it is possible values (e.g.,
   Internet authentication flag set to encrypt a specific value).  When sending
   keys and associated
   information.  The level of encryption is applied these values would not be transmitted as key attributes but only
   referred to via the value of
   individual elements and <KeyProfileId> element set to the applied encryption algorithm MUST be specific agreed
   profile (in this case '1').  When the
   same for elements.  Key encryption is supported based on receiving party receives the
   following credentials: pre-shared keys, passphrase-based keys, and
   asymmetric
   keys

6.1.  Encryption based on Pre-Shared Keys

   Figure 4 shows an example that illustrates it can then associate all relevant key attributes contained in
   the encryption out of band agreed profile with the
   content of imported keys.  Often this
   methodology is used between the <Secret> element using AES128-CBC, manufacturing and the plaintext value
   of <Secret> is '3132333435363738393031323334353637383930'.  The name validation
   service to avoid repeated transmission of the pre-shared secret is "Example-Key1", as same set in the <KeyName>
   element (which is a child element of the <EncryptionKey> element). values.

   The value of the <KeyReference> element contains a reference to an external key to
   be used is '12345678901234567890123456789012'.
   Since AES128-CBC does not provide integrity checks with a keyed MAC key derivation scheme and no specific key is
   applied to the encrypted value using
   transported but only the algorithm indicated in
   <MACAlgorithm> element (in our example
   "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used).  The result
   of reference to the keyed MAC computation external key is placed in used (e.g.,
   the <ValueMAC> element. PKCS#11 key label).

   <?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>
     <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
     </MACAlgorithm>
     <Device> 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 KeyId="12345678"
         KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> Id="12345678"
            Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
             <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
             </Usage>
               </AlgorithmParameters>
               <KeyProfileId>keyProfile1</KeyProfileId>
               <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>zdrZbGBj9BDZJzunbfAG3kyZyYc=
                     </ValueMAC>
                 </Secret>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
               <Policy>
                   <KeyUsage>OTP</KeyUsage>
               </Policy>
           </Key>
     </Device>
       </KeyPackage>
   </KeyContainer>

   Figure 4: AES-128-CBC Encrypted Pre-Shared Secret Key

   When protecting the payload with pre-shared keys implementations MUST
   set the name Example of the specific pre-shared a PSKC Document transmitting a HOTP key in via key
                             derivation values

   The key value will be derived using the <KeyName> element
   inside value of the <EncryptionKey> element.

   For systems implementing PSKC it is RECOMMENDED to support AES-128-
   CBC (with <SerialNumber>
   element and an external key identified by the URI label 'MasterKeyLabel'.

5.  Key policy - transmission of http://www.w3.org/2001/04/xmlenc#aes128-cbc) key usage policies and
   KW-AES128 (with key PIN
    protection policy

   This section illustrates the URI functionality of
   http://www.w3.org/2001/04/xmlenc#kw-aes128).  Please note that KW-
   AES128 requires that the key <Policy> element
   within PSKC that allows policy to be protected must be attached to a multiple of 8
   bytes.  Hence, if keys of key and its
   related meta data.  This element is a different length have to be protected child element of the <Key>
   element.

   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.

   We will start our description with an example that expands the
   example shown in Figure 3.

   <?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>

         Figure 5: Non-Encrypted HOTP Secret Key protected by PIN

   This document defines the following Policy child elements:

   <StartDate> and <ExpiryDate>:  These two elements denote the validity
      period of a key.  It MUST be ensured that the key wrap algorithm is only used
      between the start and the end date (inclusive).  The value MUST be
      expressed in UTC form, with padding, 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 described the start time.

   <NumberOfTransactions>:  The value in [I-D.housley-aes-key-wrap-with-pad] is RECOMMENDED.  An example
   list this element indicates the
      maximum number of optionally-to-implement encryption algorithms times a key carried within the PSKC document can
      be found
   below:

 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 used.  When algorithms without integrity checks this element is omitted then there is no
      restriction regarding the number of times a key can be used.

   <KeyUsage>:  The <KeyUsage> element puts constraints on the intended
      usage of the key.  The recipient of the PSKC document MUST enforce
      the key usage.  Currently, the following tokens are used, such as AES-128-
   CBC, registered by
      this document:

      OTP:  The key MUST only be used for OTP generation.

      CR:  The key MUST only be used for Challenge/Response purposes.

      Encrypt:  The key MUST only be used for data encryption purposes.

      Integrity:  The key MUST only be used to generate a keyed MAC message
         digest for data integrity or authentication purposes.

      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)

      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).

      Decrypt:  The key MUST only be used for data decryption purposes.

      KeyWrap:  The key MUST only be used for key wrap purposes.

      Unwrap:  The key MUST only be used for key unwrap purposes.

      Derive:  The key MUST only be used with a key derivation function
         to derive a new key (see also Section 8.2.4 of [NIST800-57]).

      Generate:  The key MUST only be used to generate a new key based
         on a random number and the previous value using of the key (see also
         Section 8.1.5.2.1 of[NIST800-57]).

      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.

   <PINPolicy>:  The <PINPolicy> element allows policy about the PIN
      usage to be associated with the key.  The following attributes are
      specified:

      'PINKeyId':  This attribute contains the same unique key as id of the key encryption
         held within this container that contains the value of the PIN
         that protects the key.

      'PINUsageMode':  This mandatory attribute indicates the way the
         PIN is used during the usage of the key.  The following values
         are defined:

         Local:  This value indicates that the PIN is checked locally on
            the device before allowing the key
   MUST to be placed used in executing
            the <ValueMAC> element of algorithm.

         Prepend:  This value indicates that the <Data> element.  In
   this case PIN is prepended to the MAC algorithm type
            OTP or response hence it MUST be set in checked by the <MACAlgorithm>
   element of validation
            server.

         Append:  This value indicates that the <KeyContainer> element.  Implementations of PSKC PIN is appended to the
            OTP or response hence it MUST
   support HMAC-SHA1 (with be checked by the URI of
   http://www.w3.org/2000/09/xmldsig#hmac-sha1) validation
            server.

         Algorithmic:  This value indicates that the PIN is used as part
            of the mandatory-to-
   implement MAC algorithm.  An example list algorithm computation.

      'MaxFailedAttempts':  This attribute indicates the maximum number
         of optionally-to-implement
   MAC algorithms can times the PIN may be found below:

   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

6.2.  Encryption based on Passphrase-based Keys

   To entered wrongly before it MUST NOT be able
         possible to support passphrase based key encryption keys as defined
   in PKCS#5 the following PBE related parameters have been introduced
   into PSKC.  Implementations of PSKC MUST support the PKCS#5
   recommended PBKDF2 and PBES2 algorithms.  Differing from the PKCS#5
   XML schema definition, use the PBKDF2 and PBES2 are specified in two
   separate elements in a <KeyContainer> element:

      (a) PBKDF2 is specified via key anymore.

      'MinLength':  This attribute indicates the <DerivedKey> element, which is a
      child element minimum length of a PIN
         that can be set to protect the <EncryptionKey> element.

      (b) PBES2 is specified by associated key.  It MUST NOT be
         possible to set a PIN shorter than this value.  If the 'Algorithm'
         'PINFormat' attribute (with the is 'DECIMAL', 'HEXADECIMAL' or
         'ALPHANUMERIC' this value set to
      http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2) indicates the number of digits/
         characters.  If the <EncryptionMethod> element used inside 'PINFormat' attribute is 'BASE64' or
         'BINARY', this value indicates the encrypted data
      elements.

   The attributes number of bytes of the <DerivedKey> element have the following
   semantic:

   'xml:id':
         unencoded value.

      'MaxLength':  This attribute carries indicates the unique identifier for maximum lenght of a PIN
         that can be set to protect this key.

   'Type':  This attribute was included for conformance with XML
      encryption.  It is an optional attribute identifying type
      information about MUST NOT be possible
         to set a PIN longer than this value.  If the plaintext form of 'PINFormat'
         attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
         value indicates the encrypted content.
      Please see Section 3.1 of [XMLENC] for more details.

   The elements number of digits/characters.  If the <DerivedKey> element have
         'PINFormat' attribute is 'BASE64' or 'BINARY', this value
         indicates the following semantic:

   <CarriedKeyName>:  This element carries a friendly name number of bytes of the key.

   <KeyDerivationMethod>: unencoded value.

      'PINEncoding':  This element defines how key encryption key
      is derived.  The 'Algorithm' attribute is used to indicate indicates the key
      derivation method.  When PBKDF2 is used, encoding of the URI
      http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 PIN
         and MUST be used.  When PBKDF2 is used, it MUST include the <PBKDF2-params>
      child element to indicate the PBKDF2 parameters, such as salt and
      iteration count.

   <ReferenceList>:  This element contains a list of IDs one of the elements
      that have been encrypted by this key.

   When PBES2 values: DECIMAL, HEXADECIMAL,
         ALPHANUMERIC, BASE64, or BINARY.

      If the 'PinUsageMode' attribute is used for encryption, set to "Local" then the URL
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 device
      MUST be
   specified as enforce the 'Algorithm' attribute of <xenc:EncryptionMethod>
   element.  The underlying encryption scheme restriction indicated in the 'MaxFailedAttempts',
      'MinLength', 'MaxLength' and initialization vector 'PINEncoding' attribute, otherwise it
      MUST be expressed enforced on the server side.

6.  Key protection methods

   With the functionality described in the <pskc:EncryptionScheme> 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 <xenc:EncryptionMethod>.

   When PKCS#5 password based the <KeyContainer> element, it is possible to encrypt keys
   and associated information.  The level of encryption is used, applied to
   the <EncryptionKey>
   element value of individual elements and <xenc:EncryptionMethod> element the applied encryption algorithm
   MUST be used in exactly the form as shown in Figure 5.

   In same for all encrypted elements.  Keys are protected
   using the following methods: pre-shared keys, passphrase-based keys,
   and asymmetric keys.

6.1.  Encryption based on Pre-Shared Keys

   Figure 6 shows an example below, that illustrates the following data encryption of the
   content of the <Secret> element using AES128-CBC and PKCS5 Padding.
   The plaintext value of <Secret> is used.

   Password:   qwerty

   Salt:   0x123eff3c4a72129c

   Iteration Count:  1000

   OTP Secret:   12345678901234567890
   '3132333435363738393031323334353637383930'.  The derived 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 "0x651e63cd57008476af1ff6422cd02e41".
   This key '12345678901234567890123456789012'.
   Since AES128-CBC does not provide integrity checks a keyed MAC is also used
   applied to calculate 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 secret MAC key
   "12345678901234567890".  The is randomly generated, in our case
   '1122334455667788990011223344556677889900', and encrypted with the
   above encryption with algorithm "AES-128-CBC"
   follows key.)  The result of the specification defined keyed MAC computation is
   placed in [XMLENC]. the <ValueMAC> child element of <Secret>.

 <?xml version="1.0" encoding="UTF-8"?>
 <KeyContainer Version="1.0"
     xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
     xmlns:pkcs5=
      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
     Version="1.0">
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
     <EncryptionKey>
         <DerivedKey>
             <CarriedKeyName>Passphrase1</CarriedKeyName>
             <KeyDerivationMethod
                 Algorithm=
 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
                 <pkcs5:PBKDF2-params>
                     <pkcs5:Salt>
                         <pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified>
                     </pkcs5:Salt>
                     <pkcs5:IterationCount>1000</pkcs5:IterationCount>
                     <pkcs5:KeyLength>16</pkcs5:KeyLength>
                     <pkcs5:PRF/>
                 </pkcs5:PBKDF2-params>
             </KeyDerivationMethod>
             <xenc:ReferenceList>
                 <xenc:DataReference URI="#ED"/>
             </xenc:ReferenceList>
         </DerivedKey>
         <ds:KeyName>Pre-shared-key</ds:KeyName>
     </EncryptionKey>
     <Device>
     <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>TokenVendorAcme</Manufacturer>
             <Manufacturer>Manufacturer</Manufacturer>
             <SerialNo>987654321</SerialNo>
         </DeviceInfo>
         <CryptoModuleInfo>
             <Id>CM_ID_001</Id>
         </CryptoModuleInfo>
         <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
         KeyId="123456">
             <Issuer>Example-Issuer</Issuer>
             <Usage> Id="12345678"
             Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
             <Issuer>Issuer</Issuer>
             <AlgorithmParameters>
                 <ResponseFormat Length="8" Encoding="DECIMAL"/>
             </Usage>
             </AlgorithmParameters>
             <Data>
                 <Secret>
                 <EncryptedValue Id="ED">
                     <EncryptedValue>
                         <xenc:EncryptionMethod Algorithm=
 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
                         <EncryptionScheme Algorithm=
 "http://www.w3.org/2001/04/xmlenc#aes128-cbc">
                         </EncryptionScheme>
                     </xenc:EncryptionMethod>
             Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                         <xenc:CipherData>
                             <xenc:CipherValue>
       oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
                           pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
                             </xenc:CipherValue>
                         </xenc:CipherData>
                     <ns2:ValueMAC>cOpiQ/H7Zlj6ywiYWtwgz9cRaOA=
                     </ns2:ValueMAC>
                     </EncryptedValue>
                     <ValueMAC>ooo0Swn6s/myD4o05FCfBHN0560=</ValueMAC>
                 </Secret>
                 <Counter>
                     <PlainValue>0</PlainValue>
                 </Counter>
             </Data>
         </Key>
     </Device>
     </KeyPackage>
 </KeyContainer>

           Figure 5: Example 6: AES-128-CBC Encrypted Pre-Shared Secret Key

   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.

   For systems implementing PSKC Document using Encryption based on
                           Passphrase-based Keys

6.3.  Encryption based on Asymmetric Keys

   When using asymmetric 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 encrypt child elements be
   protected then the usage of the key wrap algorithm with padding, as
   described in [AESKWPAD] is RECOMMENDED.  Some of the encryption
   algorithms that can optionally be implemented are:

 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

6.1.1.  MAC Method

   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 information about element.  In this case the certificate being used MAC algorithm type MUST be stated set
   in the <X509Data> element, which <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 child 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
   <EncryptionKey> element. key
   container.  The encryption algorithm method and encrypted value MUST be indicated set
   respectively in the 'Algorithm' attribute of the <EncryptionMethod> element.  In element and the example shown <CipherData>
   element of the <MACKey> element in Figure 6 the algorithm is set to
   "http://www.w3.org/2001/04/xmlenc#rsa_1_5".

   <?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>
       <MACAlgorithm>
           http://www.w3.org/2000/09/xmldsig#hmac-sha1
       </MACAlgorithm>
       <Device>
           <DeviceInfo>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
           <Key
               KeyId="MBK000000001"
               KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Example-Issuer</Issuer>
               <Usage>
                   <ResponseFormat Length="6" Encoding="DECIMAL"/>
               </Usage>
               <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>
       </Device>
   </KeyContainer>

      Figure 6: Example <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 Document using 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:

   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

6.2.  Encryption based on
                              Asymmetric Passphrase-based Keys

   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

   Figure 7 shows an example that illustrates the encryption of an
   optional-to-implement algorithm.

6.4.  Transmission the
   content of Key Derivation Values

   <KeyProfileId> element, which the <Secret> element using passphrase based encryption
   PBES2 as defined in [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 a set as
   the child element of <EncryptionKey> element of the <Key>
   element, carries a unique identifier key container.

   The <DerivedKey> element is used between to specify the sending key derivation
   function and
   receiving party to establish a related parameters.  The encryption algorithm, namely
   PBES2 as specified in [PKCS5] ( URI
   'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2'), MUST
   be set of key in the 'Algorithm' attribute values that are
   not transmitted within of <EncryptionMethod> element
   used inside the container but agreed between encrypted data elements.

   When PBKDF2 is used, the two
   parties out attribute "Algorithm" of band.  This element will then represent the unique
   reference to a element <dkey:
   KeyDerivationMethod> MUST be set of 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. the URI
   'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'.  The sending and
   element <dkey:KeyDerivationMethod> MUST include the receiving party would agree to a set
   of values related <PBKDF2-params>
   child element to indicate the MasterCard's Chip Authentication Protocol
   (CAP) [CAP].

   For example, sending PBKDF2 parameters, such as salt 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).
   iteration count.

   When sending
   keys these values would not 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 transmitted as key attributes but only
   referred to via expressed in the <KeyProfileId>
   <pskc:EncryptionScheme> element, which is a child element set of <xenc:
   EncryptionMethod>.

   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 specific agreed
   profile (in this case '1'). encrypted value.

   When PKCS#5 password based encryption is used, the receiving party receives <EncryptionKey>
   element and <xenc:EncryptionMethod> element MUST be used in exactly
   the
   keys it can then associate all relevant key attributes contained form as shown in Figure 7.

   In the out of band agreed profile with example below, the imported keys.  Often this
   methodology following data is used.

   Password:   qwerty

   Salt:   0x123eff3c4a72129c

   Iteration Count:  1000

   MAC Key:   0xbdaab8d648e850d25a3289364f7d7eaaf53ce581

   OTP Secret:   12345678901234567890

   The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41".
   The initialization vector (IV) is
   "0xa13be8f92db69ec992d99fd1b5ca05f0".  This key is also used between to
   encrypt the manufacturing and randomly chosen MAC key.  A different IV can be used,
   say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the validation
   service to avoid transmission of mainly example.  The
   encryption with algorithm "AES-128-CBC" follows the same set specification
   defined in [XMLENC].

  <?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>
      Figure 7: Example of values.

   The <KeyReference> element contains a reference PSKC Document using Encryption based on
                           Passphrase-based Keys

6.3.  Encryption based on Asymmetric Keys

   When using asymmetric keys to an external key
   when key derivation schemes are encrypt child elements of the <Data>
   element information about the certificate being used and no specific key MUST be stated
   in the <X509Data> element, which is
   transported but only a child element of the reference to
   <EncryptionKey> element.  The encryption algorithm MUST be indicated
   in the external key is used (e.g., 'Algorithm' attribute of the PKCS#11 key label). <EncryptionMethod> element.  In
   the example shown in Figure 8 the algorithm is set to
   "http://www.w3.org/2001/04/xmlenc#rsa_1_5".

   <?xml version="1.0" encoding="UTF-8"?> encoding="UTF-8" ?>
   <KeyContainer Version="1" id="exampleID1"
   xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <Device>
       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>Manufacturer</Manufacturer>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
           <Key KeyId="12345678"
           KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
               Id="MBK000000001"
               Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Example-Issuer</Issuer>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Length="6" Encoding="DECIMAL"/>
               </Usage>
               <KeyProfileId>keyProfile1</KeyProfileId>
               <KeyReference>MasterKeyLabel</KeyReference>
               </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>
               <Policy>
                   <KeyUsage>OTP</KeyUsage>
               </Policy>
           </Key>
       </Device>
       </KeyPackage>
   </KeyContainer>

   The key value will be derived using the serialnumber and an external
   key identified by the label 'MasterKeyLabel'.

      Figure 7: 8: Example of a PSKC Document transmitting using Encryption based on
                              Asymmetric Keys

   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

6.4.  Padding of encrypted values for non-padded encryption algorithms

   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 via key
                             derivation values that is 20 bytes long enctypted with AES that has an 8
   byte block cypher) padding is required.

   PSKC impllementations MUST use PKCS5 padding as described in [PKCS5].

7.  Digital Signature

   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 [XMLDSIG].

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
       xmlns:pkcs5=
       "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
       Version="1">
       <Device>
       Version="1.0">
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>0755225266</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
           KeyId="123"> Id="123"
           Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Example-Issuer</Issuer>
               <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="6" Encoding="DECIMAL"/>
               </Usage>
               </AlgorithmParameters>
               <Data>
                   <Secret>
                       <PlainValue>
                           MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
                       </PlainValue>
                   </Secret>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
           </Key>
       </Device>
       </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>

                    Figure 8: 9: Digital Signature Example

8.  Bulk Provisioning

   The functionality of bulk provisioning can be accomplished by
   repeating the <Device> <KeyPackage> element multiple times within the
   <KeyContainer> element indicating that multiple keys are provided to
   different devices. devices or cryptomodules.  The <EncryptionKey> element then
   applies to all
   <Device> <KeyPackage> elements.  Furthermore, within a single <Device> element  When provisioning multiple
   keys to the
   <Key> same device the <KeyPackage> element may also be is repeated providing different keys and meta
   data for a but the
   enclosed <DeviceInfo> element will contain the same sub elements that
   uniquely identify the single device.

   Figure 9 10 shows an example utilizing these capabilities.

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1" Version="1.0"
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <Device>
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>654321</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
           KeyId="1"> Id="1"
           Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage>
               </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>
       </Device>
       <Device>
       </KeyPackage>
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>123456</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
           KeyId="2"> Id="2"
           Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage>
               </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>
       </Device>
       <Device>
       </KeyPackage>
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>TokenVendorAcme</Manufacturer>
               <SerialNo>9999999</SerialNo>
           </DeviceInfo>
           <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
           KeyId="3"> Id="3"
           Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage>
               </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 KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
           KeyId="4"> Id="4"
           Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
               <Issuer>Issuer</Issuer>
               <Usage>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </Usage>
               </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>
       </Device>
       </KeyPackage>
   </KeyContainer>

                   Figure 9: 10: Bulk Provisioning Example

9.  Extensibility

   This section lists a few common extension points provided by PSKC:

   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
      Section 4, and rules for extensibililty are defined in Section 12.

   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.

   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 Section 11).

   New PSKC Algorithm Profiles:  This document defines two PSKC
      algorithm profiles, see Section 10.  The following informational
      draft describes additional profiles [PSKC-ALGORITHM-PROFILES].
      Further PSKC algorithm profiles can be registered as described in
      Section 12.4.

   Algorithm URIs:  Section 6 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.

   Policy:  Section 5 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 Section 12.

10.  PSKC Algorithm Profile

10.1.  HOTP

   Common Name:  HOTP

   Class:  OTP

   URN:  urn:ietf:params:xml:ns:keyprov:pskc#hotp

   Algorithm Definition:  http://www.ietf.org/rfc/rfc4226.txt

   Identifier Definition:  (this RFC)

   Registrant Contact:  IESG

   Profiling:

         The <Usage> <KeyPackage> element MUST be present.  The present and the
         <ResponseFormat> element, which is a child element of the <Usage> element
         <AlgorithmParameters> element, MUST be used to indicate the OTP
         length and the value format.

         The <Counter> element (see Section 4.2) 4.1) MUST be provided as
         meta-data for the key.

         The following additional constraints apply:

         +  The value of the <Secret> element MUST contain key material
            with a length of at least 16 octets (128 bits), if it is
            present.

         +  The <ResponseFormat> element MUST have the 'Format'
            attribute set to "DECIMAL", and the 'Length' attribute MUST
            indicate a length value between 6 and 9.

         +  The <PINPolicy> element MAY be present but the
            'PINUsageMode' attribute cannot be set to "Algorithmic".

         An example can be found in Figure 2. 3.

10.2.  KEYPROV-PIN

   Common Name:  KEYPROV-PIN
   Class:  Symmetric static credential comparison

   URN:  urn:ietf:params:xml:ns:keyprov:pskc#pin

   Algorithm Definition:  (this document)

   Identifier Definition  (this document)

   Registrant Contact:  IESG

   Profiling:

         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.

         The <Secret> element (see Section 4.2) 4.1) MUST be provided.

         See the example in Figure 3 5

11.  XML Schema

   This section defines the XML schema for PSKC.

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema
    targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc" 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"/>
 "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="MACAlgorithm" type="pskc:KeyAlgorithmType" name="MACMethod"
                     type="pskc:MACMethodType" minOccurs="0"/>
                <xs:element name="Device" type="pskc:DeviceType"
            minOccurs="1" 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" 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="Usage"
              type="pskc:UsageType"/> 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" maxOccurs="1"/> 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="KeyId" name="Id"
                type="xs:string" use="required"/>
           <xs:attribute name="KeyAlgorithm" name="Algorithm"
                type="pskc:KeyAlgorithmType" use="optional"/>
          <xs:attribute name="KeyProperties"
          type="xs:IDREF" 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"/>
                     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" maxOccurs="1"/> minOccurs="0"/>
                <xs:element name="Counter"
                     type="pskc:longDataType"
              minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
                <xs:element name="Time"
                     type="pskc:intDataType"
              minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
                <xs:element name="TimeInterval"
                     type="pskc:intDataType"
              minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
                <xs:element name="TimeDrift"
                     type="pskc:intDataType"
              minOccurs="0" maxOccurs="1"/> 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="DerivedKeyType">
          <xs:sequence>
              <xs:element name="KeyDerivationMethod"
                type="pskc:KeyDerivationMethodType" minOccurs="0"/>
              <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
              <xs:element name="CarriedKeyName" type="xs:string"
                  minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="id" type="xs:ID" use="optional"/>
          <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
      </xs:complexType>
      <xs:complexType name="KeyDerivationMethodType">
          <xs:sequence>
              <xs:any namespace="##other" processContents="lax"
                                                  minOccurs="0"
              maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="Algorithm" type="xs:anyURI"
          use="required"/>
      </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="DeviceType"> 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"
            maxOccurs="unbounded"/>
          <xs:element name="User" type="xs:string" minOccurs="0"/>
                <xs:element name="Extensions"
                     type="pskc:ExtensionsType" minOccurs="0"
                     maxOccurs="unbounded"/>
           </xs:sequence>
      </xs:complexType>
      <xs:complexType name="UsageType"> 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="DerivedKey" type="pskc:DerivedKeyType"/> 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>

12.  IANA Considerations

12.1.  Content-type registration for 'application/pskc+xml'

   This specification requests the registration of a new MIME type
   according to the procedures of RFC 4288 [RFC4288] and guidelines in
   RFC 3023 [RFC3023].

   MIME media type name:  application

   MIME subtype name:  pskc+xml

   Mandatory parameters:  none

   Optional parameters:  charset

      Indicates the character encoding of enclosed XML.

   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], Section 3.2.

   Security considerations:  This content type is designed to carry PSKC
      protocol payloads.

   Interoperability considerations:  None

   Published specification:  RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number of this specification.]

   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.

   Additional information:

      Magic Number:  None

      File Extension:  .pskcxml

      Macintosh file type code:  'TEXT'
   Personal and email address for further information:  Philip Hoyer,
      Philip.Hoyer@actividentity.com

   Intended usage:  LIMITED USE

   Author:  This specification is a work item of the IETF KEYPROV
      working group, with mailing list address <keyprov@ietf.org>.

   Change controller:  The IESG <iesg@ietf.org>

12.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:ns:keyprov:pskc

   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
      (Philip.Hoyer@actividentity.com).

   XML Schema:  The XML schema to be registered is contained in
      Section 11.  Its first line is

   <?xml version="1.0" encoding="UTF-8"?>

      and its last line is

   </xs:schema>

12.3.  URN Sub-Namespace Registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:ns:keyprov:pskc

   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
      (Philip.Hoyer@actividentity.com).

   XML:

   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:1.0</h2>
     <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

12.4.  PSKC Algorithm Profile Registry

   This specification requests the creation of a new IANA registry for
   PSKC algorithm profiles in accordance with the principles set out in
   RFC 5226 [RFC5226].

   As part of this registry IANA will maintain the following
   information:

   Common Name:  The name by which the PSKC algorithm profile is
      generally referred.

   Class:  The type of PSKC algorithm profile registry entry being
      created, such as encryption, Message Authentication Code (MAC),
      One Time Password (OTP), Digest.

   URN:  The URN to be used to identify the profile.

   Identifier Definition:  IANA will be asked to add a pointer to the
      specification containing information about the PSKC algorithm
      profile registration.

   Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

   Registrant Contact:  Contact information about the party submitting
      the registration request.

   PSKC Profiling:  Information about PSKC XML elements and attributes
      being used (or not used) with this specific profile of PSKC.

   PSKC algorithm profile identifier registrations are to be subject to
   Expert Review as per RFC 5226 [RFC5226].

   IANA is asked to add an initial value to the registry based on the
   PSKC HOTP algorithm profile described in Section 10.

12.5.  PSKC Version Registry

   IANA is requested to create a registry for PSKC version numbers.  The
   registry has the following structure:

     PSKC Version              | Specification
   +---------------------------+----------------
   | 1 1.0                       | [This document]

   Standards action is required to define new versions of PSKC.  It is
   not envisioned to depreciate, delete, or modify existing PSKC
   versions.

12.6.  Key Usage Registry

   IANA is requested to create a registry for key usage.  A description
   of the 'KeyUsage' element can be found in Section 5.  The registry
   has the following structure:

     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]
   | Unlock Verify                    | [Section 5 of this document]
   | Decrypt Unlock                    | [Section 5 of this document]
   | KeyWrap Decrypt                   | [Section 5 of this document]
   | Unwrap KeyWrap                   | [Section 5 of this document]
   | Derive Unwrap                    | [Section 5 of this document]
   | Generate Derive                    | [Section 5 of this document]
   | Verify Generate                  | [Section 5 of this document]
   +---------------------------+-------------------------------

   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.

13.  Security Considerations

   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.

13.1.  Payload confidentiality

   By design, the container allows two main approaches to guaranteeing
   the confidentiality of the information it contains while transported.

   First, the container key data payload may be encrypted.

   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.  At the time  Please see Section 6.1 for
   recommendations of this writing both
   3DES and AES are mandatory algorithms but 3DES may be dropped in the
   relatively near future.  Applications concerned with algorithm
   longevity are advised to use AES-256-CBC. 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. employed, see Section 6.3 .  Similarly
   to symmetric key cryptography, the stronger the asymmetric key, the
   more secure the protection is.

   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.

   Practical implementations should use PBESalt and PBEIterationCount
   when PBE encryption is used.  Different PBESalt value per key
   container should be used for best protection.

   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.

   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.

13.2.  Payload integrity

   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.

13.3.  Payload authenticity

   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.

   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.

14.  Contributors

   We would like Hannes Tschofenig for his text contributions to this
   document.

15.  Acknowledgements

   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.

   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.

   This work is based on earlier work by the members of OATH (Initiative
   for Open AuTHentication), see [OATH], to specify a format that can be
   freely distributed to the technical community.

16.  References

16.1.  Normative References

   [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
              Standard", Version 2.0,
              URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names",
              RFC 4514, June 2006.

   [XMLDSIG]  Eastlake, D., "XML-Signature Syntax and Processing",
              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
              W3C Recommendation, February 2002.

   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
              URL: http://www.w3.org/TR/xmlenc-core/,
              W3C Recommendation, December 2002.

16.2.  Informative References

   [AESKWPAD]
              Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", March 2009, <http:
              //www.ietf.org/internet-drafts/
              draft-housley-aes-key-wrap-with-pad-02.txt>.

   [CAP]      MasterCard International, "Chip Authentication Program
              Functional Architecture", September 2004.

   [DSKPP]    Doherty, A., Pei, M., Machani, S., and M. Nystrom,
              "Dynamic Symmetric Key Provisioning Protocol", Internet
              Draft Informational, URL: http://www.ietf.org/
              internet-drafts/draft-ietf-keyprov-dskpp-05.txt,
              February 2008.

   [HOTP]     MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226, December 2005.

   [I-D.housley-aes-key-wrap-with-pad]
              Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm with Padding",
              draft-housley-aes-key-wrap-with-pad-00 (work in progress),
              January 2009.

   [LUHN]     Luhn, H., "Luhn algorithm", US Patent 2950048,
              August 1960, <http://patft.uspto.gov/netacgi/
              nph-Parser?patentnumber=2950048>.

   [NIST]

   [NIST800-57]
              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
              "NIST Special Publication 800-57, Recommendation for Key
              Management - Part 1: General (Revised)", NIST Special
              Publication 800-57, March 2007.

   [OATH]     "Initiative for Open AuTHentication",
              URL: http://www.openauthentication.org.

   [PSKC-ALGORITHM-PROFILES]
              Hoyer, P., Pei, M., Machani, S., and A. Doherty,
              "Additional Portable Symmetric Key Container (PSKC)
              Algorithm Profiles", Internet Draft Informational, URL:
               http://tools.ietf.org/html/
              draft-hoyer-keyprov-pskc-algorithm-profiles-00,
              December 2008.

   [RFC2396]  Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.
              Masinter, "Uniform Resource Identifiers (URI): Generic
              Syntax", BCP 26, RFC 2396, August 1998.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [W3C-DKEY]
              Nystrom, M., "XML Security Derived Keys",
              W3C Informational, February 2009,
              <http://www.w3.org/TR/xmlsec-derivedkeys>.

   [XMLNS]    "Namespaces in XML", W3C Recommendation ,
              URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
              January 1999.

Appendix A.  Use Cases

   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.

   These use cases also help in understanding the applicability of this
   specification to real world situations.

A.1.  Online Use Cases

   This section describes the use cases related to provisioning the keys
   using an online provisioning protocol such as [DSKPP].

A.1.1.  Transport of keys from Server to Cryptographic Module

   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 [DSKPP].  The provisioning entity
   delivers one or more keys in a standard format that can be processed
   by the mobile device.

   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.

   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.

A.1.2.  Transport of keys from Cryptographic Module to Cryptographic
        Module

   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.

A.1.3.  Transport of keys from Cryptographic Module to Server

   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.

A.1.4.  Server to server Bulk import/export of keys

   From time to time, a key management system may be required to import
   or export keys in bulk from one entity to another.

   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.

   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.

A.2.  Offline Use Cases

   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.

A.2.1.  Server to server Bulk import/export of keys

   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.

   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.

Appendix B.  Requirements

   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.

   R1:   The format MUST support transport of multiple types of
         symmetric keys and related attributes for algorithms including
         HOTP, other OTP, challenge-response, etc.

   R2:   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

         *  Unique Key Identifier

         *  Issuer information

         *  Algorithm ID

         *  Algorithm mode

         *  Issuer Name

         *  Key friendly name

         *  Event counter value (moving factor for OTP algorithms)

         *  Time value

   R3:   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 [DSKPP]

   R4:   The format SHOULD allow bulk representation of symmetric keys

   R5:   The format SHOULD allow bulk representation of PINs related to
         specific keys

   R6:   The format SHOULD be portable to various platforms.
         Furthermore, it SHOULD be computationally efficient to process.

   R7:   The format MUST provide appropriate level of security in terms
         of data encryption and data integrity.

   R8:   For online scenarios the format SHOULD NOT rely on transport
         level security (e.g., SSL/TLS) for core security requirements.

   R9:   The format SHOULD be extensible.  It SHOULD enable extension
         points allowing vendors to specify additional attributes in the
         future.

   R10:  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.

   R11:  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.

   R12:  The format MUST support the use of pre-shared symmetric keys to
         ensure confidentiality of sensitive data elements.

   R13:  The format MUST support a password-based encryption (PBE)
         [PKCS5] scheme to ensure security of sensitive data elements.
         This is a widely used method for various provisioning
         scenarios.

   R14:  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.

Authors' Addresses

   Philip Hoyer
   ActivIdentity, Inc.
   117 Waterloo Road
   London, SE1  8UL
   UK

   Phone: +44 (0) 20 7744 6455
   Email: Philip.Hoyer@actividentity.com

   Mingliang Pei
   VeriSign, Inc.
   487 E. Middlefield Road
   Mountain View, CA  94043
   USA

   Phone: +1 650 426 5173
   Email: mpei@verisign.com

   Salah Machani
   Diversinet, Inc.
   2225 Sheppard Avenue East
   Suite 1801
   Toronto, Ontario  M2J 5C2
   Canada

   Phone: +1 416 756 2324 Ext. 321
   Email: smachani@diversinet.com