keyprov                                                         P. Hoyer
Internet-Draft                                             ActivIdentity
Intended status: Standards Track                                  M. Pei
Expires: May 9, August 25, 2008                                        VeriSign
                                                              S. Machani
                                                              Diversinet
                                                                S. Chang
                                                                 Gemalto
                                                        November 6, 2007
                                                       February 22, 2008

                    Portable Symmetric Key Container
       draft-ietf-keyprov-portable-symmetric-key-container-02.txt
       draft-ietf-keyprov-portable-symmetric-key-container-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 9, August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   This document specifies a symmetric key 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.  The standard token format enables
   enterprises to deploy best-of-breed solutions combining components
   from different vendors into the same infrastructure.

   This work is a joint effort by the members of OATH (Initiative for
   Open AuTHentication) to specify a format that can be freely
   distributed to the technical community.  The authors believe that a
   common and shared specification will facilitate adoption of two-
   factor authentication on the Internet by enabling interoperability
   between commercial and open-source implementations.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Credential  Key migration by end-user  . . . . . . . . . . . . . .  6
       3.1.2.  Bulk import of new credentials keys  . . . . . . . . . . . . . . .  6
       3.1.3.  Bulk migration of existing credentials keys  . . . . . . . .  6 . . .  7
       3.1.4.  Credential  Key upload case  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Online Use Cases . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Online provisioning a credential key to end-user's
               authentication token . . . . . . . . . . . . . . . . .  7
       3.2.2.  Server to server provisioning of credentials keys  . . . . . . . .  8
       3.2.3.  Online update of an existing authentication token
               credential
               key  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Symmetric  Portable Key Attributes . . . . . container definition  . . . . . . . . . . . . . . 11
     5.1.  Common Attributes  . . . . . . . . .  KeyContainer . . . . . . . . . . . 11
       5.1.1.  Data (OPTIONAL) . . . . . . . . . . . . 11
     5.2.  Device . . . . . . . 11
       5.1.2.  KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11
       5.1.3.  Usage (MANDATORY) . . . . 13
       5.2.1.  DeviceId . . . . . . . . . . . . . . 12
       5.1.4.  KeyId (MANDATORY) . . . . . . . . . 13
     5.3.  Key  . . . . . . . . . 13
       5.1.5.  Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 13
       5.1.6.  FriendlyName 14
       5.3.1.  Data (OPTIONAL)  . . . . . . . . . . . . . . . 13
       5.1.7.  AccessRules (OPTIONAL) . . . . 17
       5.3.2.  Usage (MANDATORY)  . . . . . . . . . . . . 13
       5.1.8.  EncryptionMethod (MANDATORY when 'Data' attribute
               is encrypted)) . . . . . . 17
       5.3.3.  ValueFormat  . . . . . . . . . . . . . . 13
       5.1.9.  DigestMethod (MANDATORY when Digest is present) . . . 14
       5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . 21
       5.3.4.  PINPolicy  . . 14
       5.1.11. Logo (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17 . 22
   6.  Key  Usage and profile of algorithms for the portable symmetric
       key container XML schema definitions .  . . . . . . . . . . . . 18
     6.1.  XML Schema Types . . . . . . . . . . . . 24
     6.1.  Usage of EncryptionKey to protect keys in transit  . . . . 24
       6.1.1.  Protecting keys using a pre-shared key via
               symmetric algorithms . . . . . 18
       6.1.1.  KeyType . . . . . . . . . . . . 24
       6.1.2.  Protecting keys using passphrase based encryption
               keys . . . . . . . . . . . 19
       6.1.2.  UsageType . . . . . . . . . . . . . . 25
     6.2.  Protecting keys using asymmetric algorithms  . . . . . . . 27
     6.3.  Profile of Key Algorithm . 21
       6.1.3.  DeviceType . . . . . . . . . . . . . . . . 28
       6.3.1.  OTP Key Algorithm Identifiers  . . . . . . 22
       6.1.4.  DeviceIdType . . . . . . 28
       6.3.2.  PIN key value compare algorithm identifier . . . . . . 28
   7.  Reserved data attribute names  . . . . . . . . . 23
       6.1.5.  UserType Type . . . . . . . 30
   8.  Formal Syntax  . . . . . . . . . . . . . 24
       6.1.6.  KeyContainerType . . . . . . . . . . . 31
   9.  Security Considerations  . . . . . . . . 25
       6.1.7.  EncryptionMethodType . . . . . . . . . . . 35
     9.1.  Payload confidentiality  . . . . . . 26
       6.1.8.  DigestMethodType . . . . . . . . . . . 35
     9.2.  Payload integrity  . . . . . . . . 28
     6.2.  KeyAlgorithmType . . . . . . . . . . . . 36
     9.3.  Payload authenticity . . . . . . . . . 29
     6.3.  ValueFormat . . . . . . . . . . 36
   10. Acknowledgements . . . . . . . . . . . . . 29
     6.4.  Data elements . . . . . . . . . . 37
   11. Appendix A - Example Symmetric Key Containers  . . . . . . . . 38
     11.1. Symmetric Key Container with a single Non-Encrypted
           HOTP Secret Key  . . . . 29
       6.4.1.  KeyContainer . . . . . . . . . . . . . . . . . 38
     11.2. Symmetric Key Container with a single PIN protected
           Non-Encrypted HOTP Secret Key  . . . . 29
   7.  Formal Syntax . . . . . . . . . . 38
     11.3. Symmetric Key Container with a single AES-256-CBC
           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . 31
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 39
     8.1.  Payload confidentiality  . . . . . . . . . . . . . . . . . 39
     8.2.  Payload integrity  . . . . . . . . . . . . . . . . . . . . 40
     8.3.  Payload authenticity . . . . . . . . . . 39
     11.4. Symmetric Key Container with signature and a single
           Password-based Encrypted HOTP Secret Key . . . . . . . . . 40
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
   10. Appendix A - Example Symmetric Key Containers  . . . . . . . . 42
     10.1. Symmetric Key Container with a single Non-Encrypted
           HOTP Secret Key  . . . . . . . . . . . . . . . . . . . . . 42
     10.2.
     11.5. Symmetric Key Container with a single Password-based RSA 1.5
           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 42
   11.
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
   Intellectual Property and Copyright Statements . . . . . . . . . . 47

1.  Introduction

   With increasing use of symmetric key based authentication systems
   such as systems based one time password (OTP) and challenge response
   mechanisms, there is a need for vendor interoperability and a
   standard format for importing, exporting or provisioning symmetric
   key based credentials
   keys from one system to another.  Traditionally authentication server
   vendors and service providers have used proprietary formats for
   importing, exporting and provisioning these
   credentials keys into their systems
   making it hard to use tokens from vendor A with a server from vendor
   B.

   This Internet draft describes a standard format for serializing
   symmetric key based credentials keys such as OTP shared secrets for system import, export
   or network/protocol transport.  The goal is that the format will
   facilitate dynamic provisioning and transfer of a symmetric key keys such
   as an OTP shared secret or an encryption key of different types.  In
   the case of OTP shared secrets, the format will facilitate dynamic
   provisioning using an OTP online provisioning protocol to different
   flavors of embedded tokens for OTP credentials or allow customers to import new or
   existing tokens in batch or single instances into a compliant system.

   This draft also specifies the token key attributes required for
   interoperability computation
   such as the initial event counter used in the HOTP algorithm [HOTP].
   It is also applicable for other time-based or proprietary algorithms.

   To provide an analogy, in public key environments the PKCS#12 format
   [PKCS12] is commonly used for importing and exporting private keys
   and certificates between systems.  In the environments outlined in
   this document where OTP credentials keys may be transported directly down to
   smartcards or devices with limited computing capabilities, a format
   with small (size in bytes) and explicit shared secret configuration
   attribute information is desirable, avoiding complexity of PKCS#12.
   For example, one would have to use opaque data within PKCS#12 to
   carry shared secret attributes used for OTP calculations, whereas a
   more explicit attribute schema definition is better for
   interoperability and efficiency.

2.  Conventions used in this document

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

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   In the text below, OTP refers to one time password.

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

3.1.  Offline Use Cases

   This section describes the use cases relating to offline transport of
   credentials
   keys from one system to another, using some form of export and import
   model.

3.1.1.  Credential  Key migration by end-user

   A user wants to migrate a credential key from one authentication token
   (container) to a different authentication token.  For example, the
   authentication tokens may be soft tokens on two different systems
   (computers or mobile phones).  The user can export the credential key and
   related data in a standard format for import into the other
   authentication token.

   The key protection mechanism may rely on password-based encryption
   for soft tokens, a pre-placed hardware-protected transfer key shared
   between the two systems or may also rely on asymmetric keys/ PKI if
   available.

3.1.2.  Bulk import of new credentials keys

   Tokens are manufactured in bulk and associated credentials (key
   records) keys and algorithm
   data need to be loaded into the validation system through a file on
   portable media.  The manufacturer provides the credentials 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.

   In this case the file usually is protected by a symmetric transport
   key which was communicated separately outside of the file between the
   two parties.

   Some devices 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.

3.1.3.  Bulk migration of existing credentials keys

   An enterprise wants to port credentials 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 credentials (OTP keys and related data (e.g. for
   OTP 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.

   In this case the file usually is protected by a symmetric transport
   key which was communicated separately outside of the file between the
   two validation systems.

   In this case it is also important to be able to communicate the
   existing assignment (binding) of a device to a specific user.

3.1.4.  Credential  Key upload case

   User wants to activate and use a new credential key and related data against a
   validation system that is not aware of this credential. key.  This credential key may be
   embedded in the authentication token (e.g.  SD card, USB drive) that
   the user has purchased at the local electronics retailer.  Along with
   the authentication token, the user may get the credential key on a CD or a
   floppy in a standard format.  The user can now upload via a secure
   online channel or import this credential key and related data into the new
   validation system and start using the credential. key.

   The key protection mechanism may rely on password-based encryption,
   or a pre-placed hardware-protected transfer key shared between the
   token manufacturer and the validation system(s) if available.

3.2.  Online Use Cases

   This section describes the use cases related to provisioning the
   credentials keys
   using some form of a online provisioning protocol.

3.2.1.  Online provisioning a credential key to end-user's authentication token

   A mobile device user wants to obtain an OTP credential (shared
   secret) key for use with an OTP
   soft token on the device.  The soft token client 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 system delivers one or more OTP credential(s) keys in a
   standard format that can be processed by the mobile device.  The user
   can download a payload that contains more than one credential. key.

   In a variation of the above, instead of the user's mobile phone, a
   credential
   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 an OTP credential key in a standard format that can be processed
   by the soft token on the PC.

3.2.2.  Server to server provisioning of credentials keys

   Sometimes, instead of importing token information keys from a manufacturer using a
   file, an OTP validation server may download the credential
   seed records keys using an online
   protocol.  The credentials keys can be downloaded in a standard format that can
   be processed by a validation system.

   In another scenario, an OTA (over-the-air) credential key provisioning gateway
   that provisions credentials keys to mobile phones may obtain
   credentials key material from the credential a
   key issuer using an online protocol.  The
   credentials keys are delivered in a
   standard format that can be processed by the OTA credential key provisioning
   gateway and subsequently sent to the end-user's mobile phone.

3.2.3.  Online update of an existing authentication token credential key

   The end-user or the credential key issuer wants to update or configure an
   existing credential key in the authentication token and requests a replacement credential
   key container.  The container may or may not include a new secret key and
   may include new or updated secret key attributes such as a new counter value
   in HOTP credential key case, a new
   logo, a modified response format or length, a new
   friendly name, etc.

4.  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 key credentials keys and related attributes for algorithms including
         HOTP, other OTP, challenge-
         response, 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

         *  Issuer logo

         *  Credential  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

   R4:   The format SHOULD allow bulk representation of symmetric key
         credentials. 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.

   R6:

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

   R7:

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

   R8:

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

   R9:

   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.

   R10:

   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.

   R11:

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

   R12:

   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.

   R13:

   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
         encryption key is difficult to use.

5.  Symmetric  Portable Key Attributes container definition

   The symmetric key includes a number of data attributes that define
   the type of the portable key its usage and associated meta-information
   required during the provisioning, configuration, access or usage in
   the host device.

5.1.  Common Attributes

5.1.1.  Data (OPTIONAL)

   Defines the data attributes of the symmetric key.  Each is a name
   value pair which has both a base64 encoded value and a base 64
   encoded ValueDigest.  The value can be encrypted.  If the container
   has been encrypted the ValueDigest MUST be populated with the digest
   of the unencrypted value.

   This is also where the key value is held, therefore based on an XML schema definition and
   contains the following
   list of attribute names main entities:

   1.  KeyContainer entity as defined in Section 5.1

   2.  Device entity as defined in Section 5.2

   3.  Key entity as defined in Section 5.3

   Additionally other XML schema types have been reserved:

      SECRET: the shared secret key value in binary, base64 encoded

      COUNTER: the event counter for event based OTP algorithms. 8 bytes
      unsigned integer defined and are
   detailed in big endian (i.e. network byte order) form
      base64 encoded

      TIME: the time for time based OTP algorithms. 8 bytes unsigned
      integer in big endian (i.e. network byte order) form base64
      encoded (Number relevant subsections of seconds since 1970)

      TIME_INTERVAL: the time interval value for time based OTP
      algorithms. 8 bytes unsigned integer in big endian (i.e. network
      byte order) form base64 encoded.

      TIME_DRIFT: the device clock drift value for time based OTP
      algorithms. this document

   A KeyContainer MAY contain one or more Device entities.  A Device MAY
   contain one or more Key entities

   The value figure below indicates number of seconds that the device
      clock may drift each day. 2 bytes unsigned integer in big endian
      (i.e. network byte order) form base64 encoded.

5.1.2.  KeyAlgorithm (MANDATORY)

   Defines the type of algorithm a possible relationship diagram of the secret key. a
   container.

   --------------------------------------------
   | KeyContainer                             |
   |                                          |
   |  ------------------   -----------------  |
   |  | Device 1       |   | Device n      |  |
   |  |                |   |               |  |
   |  |  ------------  |   | ------------  |  |
   |  |  | Key 1    |  |   | | Key n    |  |  |
   |  |  ------------  |   | ------------  |  |
   |  |                |   |               |  |
   |  |                |   |               |  |
   |  |  ------------  |   | ------------  |  |
   |  |  | Key m    |  |   | | Key p    |  |  |
   |  |  ------------  |   | ------------  |  |
   |  ------------------   -----------------  |
   |                                          |
   --------------------------------------------

   The following
   algorithm URIs are among the default support list.

   o  http://www.w3.org/2001/04/xmlenc#tripledes-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes128-cbc
   o  http://www.w3.org/2001/04/xmlenc#aes192-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes256-cbc

   o  http://www.ietf.org/keyprov/pskc#hotp

5.1.2.1.  OTP Key Algorithm Identifiers

   OTP key algorithm URIs have not been defined section describe in a commonly available
   standard specification.  This document defines detail all the following URIs for
   the known open standard OTP algorithms.

5.1.2.1.1.  HOTP

   Standard document: RFC4226

   Identifier: http://www.ietf.org/keyprov/pskc#hotp

   Note that the actual URL will be finalized once a URL for this
   document is determined.

5.1.2.1.2.  Other OTP Algorithms

   An implementation should refer to vendor supplied OTP key algorithm
   URIs for proprietary algorithms.

5.1.3.  Usage (MANDATORY)

   Defines the intended usage of entities and related
   XML schema elements and attributes:

5.1.  KeyContainer

   The KeyContainer represents the key and is a combination of container entity.  A Container
   MAY contain more than one or Device entity; each Device entity MAY
   contain more than one Key entity.

   The KeyContainer is defined as follows:

 <xs:complexType name="KeyContainerType">
         <xs:sequence>
                 <xs:element name="EncryptionKey"
                         type="ds:KeyInfoType" minOccurs="0"/>
                         <xs:element name="MACAlgorithm"
                         type="pskc:KeyAlgorithmType" minOccurs="0"/>
                         <xs:element name="Device"
                         type="pskc:DeviceType" maxOccurs="unbounded"/>
                 <xs:element name="Signature"
                         type="ds:SignatureType" minOccurs="0"/>
         </xs:sequence>
   <xs:attribute name="Version" type="pskc:VersionType" use="required"/>
 </xs:complexType>

   The elements of the KeyContainer have the following (set to true):

      OTP: meanings:

   o  <EncryptionKey (OPTIONAL)>, Identifies the key will be encryption key,
      algorithm and possible parameters used for OTP generation

      CR: to protect the key will be used for Challenge/Response purposes

      Encrypt: Secret Key
      data in the key will be used container, for data encryption purposes

      Sign: profile and usage please see
      Section 6.1

   o  <MACAlgorithm (OPTIONAL)>, Identifies the key will be algorithm used to
      generate a signature or keyed
      hashing for data integrity or authentication purposes.

      Unlock: digest of the key will be the Secret Key data values when
      protection algorithms are used for an inverse challenge response in that do not have integrity checks.
      The digest guarantees the case a user has locked integrity and the device by entering a wrong PIN too
      many times (for devices with PIN-input capability)

   Additional attributes that are specific to authenticity of the
      key data. for profile and usage type MAY be
   required. please see Section 6.1 describes OTP and CR specific attributes.

5.1.4.  KeyId (MANDATORY)

   A unique and global identifier of 6.1.1

   o  <Device>, the symmetric key.  The identifier
   is defined host Device for one or more Keys as a string of alphanumeric characters.

5.1.5.  Issuer (MANDATORY) defined in
      Section 5.2 The key issuer name, this is normally the name KeyContainer MAY contain multiple Device data
      elements, allowing for bulk provisioning of keys.

   o  <Signature (OPTIONAL)>, the organization
   that issues the key to the end user signature value of the key.  For example MyBank
   issuing hardware tokens to their retail banking users 'MyBank' would
   be Container.
      When the issuer.  The Issuer is defined as a String.

5.1.6.  FriendlyName (OPTIONAL)

   The user friendly name that signature is assigned applied to the secret key for easy
   reference.  The FriendlyName is defined entire container, it MUST use
      XML Signature methods as a String.

5.1.7.  AccessRules (OPTIONAL)

   Defines a set of access rules and policies for defined in [XMLSIG].  It MAY be omitted
      when application layer provisioning or transport layer
      provisioning protocols provide the protection integrity and authenticity of
      the
   key on payload between the host Device.  Currently only sender and the UserPIN policy is
   defined.  The UserPIN policy specifies whether recipient of the user MUST enter container.
      When required, this specification recommends using a
   PIN (for devices symmetric key
      based signature with PIN input capability) the same key used in order to unlock or
   authenticate to the device hosting encryption of the
      secret key container. data.  The UserPIN signature is enveloped.

   o  <Version (MANDATORY)>, the version number for the portable key
      container format (the XML schema defined as a Boolean (TRUE or FALSE).  When in this document).

5.2.  Device

   The Device represents the user PIN is required, Device entity in the policy MUST Container.  A Device
   MAY be set bound to TRUE.  If the UserPIN a user and MAY contain more than one keys.  It is NOT provided,
   implementations SHALL default the value to FALSE.

5.1.8.  EncryptionMethod (MANDATORY when 'Data' attribute
   recommended that a key is encrypted))

   Identifies the encryption algorithm and possible parameters used bound to
   protect the Secret Key data in the container.  The encryption
   algorithm URI can be one and only one Device.

   The Device is defined as follows:

<xs:complexType name="DeviceType">
  <xs:sequence>
    <xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>
    <xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>
    <xs:element name="UserId" type="xs:string" minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

   The elements of the following.

   o  http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2

   o  http://www.w3.org/2001/04/xmlenc#tripledes-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes128-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes192-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes256-cbc

   o  http://www.w3.org/2001/04/xmlenc#rsa-1_5

   o  http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
   o  http://www.w3.org/2001/04/xmlenc#kw-tripledes

   o  http://www.w3.org/2001/04/xmlenc#kw-aes128

   o  http://www.w3.org/2001/04/xmlenc#kw-aes256 Device have the following meanings:

   o  http://www.w3.org/2001/04/xmlenc#kw-aes512

   When an PBE algorithm is used  <DeviceId>, a unique identifier for encryption, the URI
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 and the
   encryption algorithm device, defined in PBEEncryptionParamType defines
      Section 5.2.1

   o  <Key>, represents the exact PBE key derivation and encryption algorithms.

   When entity as defined in Section 5.3

   o  <UserId>, optionally identifies the value is not provided, implementations SHALL ensure owner or the
   privacy user of the key data through other standard mechanisms e.g.
   transport level encryption.

   When
      Device TODO

5.2.1.  DeviceId

   The DeviceId represents the container (payload) identifying criteria to uniquely identify
   the device that contains more than one key and
   EncryptionMethod is specified, the same encryption key MUST be used associated keys.  Since devices can come
   in different form factors such as hardware tokens, smartcards, soft
   tokens in a mobile phone or PC etc this type allows different
   criteria to encrypt all be used.  Combined though the key data elements in criteria MUST uniquely
   identify the container.

5.1.9.  DigestMethod (MANDATORY when Digest is present)

   Identifies device.  For example for hardware tokens the algorithm combination
   of SerialNo and possible parameters used to generate Manufacturer will uniquely identify a
   digest of the device but not
   SerialNo alone since two different token manufacturers might issue
   devices with the Secret Key data.  The digest guarantees same serial number (similar to the
   integrity IssuerDN and the authenticity
   serial number of the key data.

   See Section 6.1.8 for more information a certificate).  For keys hold on Digest data value type.

5.1.10.  OTP and CR specific Attributes (OPTIONAL)

   When banking cards the key usage is set to OTP or CR, additional attributes MUST be
   provided to support
   identification of the OTP and/or device is often done via the response computation as
   required by Primary Account
   Number (PAN, the underlying algorithm and to customize or configure big number printed on the outcome front of the computation (format, length card) and usage modes).

5.1.10.1.  ChallengeFormat (MANDATORY)

   The ChallengeFormat attribute defines the characteristics an
   expiry date of the
   challenge in card.  DeviceId is an extensible type that allows
   all these different ways to uniquely identify a CR usage scenario. specific key
   containing device.

   The Challenge attribute DeviceId is defined
   by as follows:

   <xs:complexType name="DeviceIdType">
   <xs:sequence>
       <xs:element name="Manufacturer" type="xs:string"/>
       <xs:element name="SerialNo" type="xs:string"/>
       <xs:element name="Model" type="xs:string" minOccurs="0"/>
       <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
   </xs:sequence>
   </xs:complexType>

   The elements of DeviceId have the following sub-attributes:

   1.  Format (MANDATORY)

          Defines meanings:

   o  <Manufacturer>, the format manufacturer of the challenge accepted by device.

   o  <SerialNo>, the device and
          MUST be one serial number of the values defined in Section 6.3
   2.  CheckDigit (OPTIONAL)

          Defines if the device needs to check or the appended Luhn check
          digit contained PAN (primary
      account number) in a provided challenge.  This is only valid
          if case of EMV (Europay-MasterCard-Visa) smart
      cards.

   o  <Model>, the Format attribute is 'DECIMAL'.  Value MUST be:

             TRUE device will check model of the appended Luhn check digit in a
             provided challenge

             FALSE device will not check appended Luhn check digit in
             challenge

   3.  Min (MANDATORY)

          Defines (e.g one-button-HOTP-token-V1)

   o  <IssueNo>, the minimum size issue number in case of smart cards with the challenge accepted by the
          device for CR mode.

          If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates the minimum number of
          digits/characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates same
      PAN, equivalent to a PSN (PAN Sequence Number).

   o  <ExpiryDate>, the minimum number of bytes expiry date of a device (such as the unencoded value.

          Value MUST be:

             Unsigned integer.

   4.  Max (MANDATORY)

          Defines one on an
      EMV card,used when issue numbers are not printed on cards).

   o  <StartDate>, the maximum size start date of a device (such as the challenge accepted by one on an EMV
      card,used when issue numbers are not printed on cards).

5.3.  Key

   The Key represents the
          device for CR mode.

          If key entity in the Format attribute KeyContainer.  The Key is 'DECIMAL', 'HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates the maximum number
   defined as follows:

   <xs:complexType name="KeyType">
     <xs:sequence>
       <xs:element name="Issuer" type="xs:string" minOccurs="0"/>
       <xs:element name="Usage" type="pskc:UsageType"/>
       <xs:element name="CardAppPersoProfileId" type="xs:string"
         minOccurs="0"/>
       <xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>
       <xs:element name="Data" type="pskc:DataType" minOccurs="0"
         maxOccurs="unbounded"/>
       <xs:element name="PINPolicy" type="pskc:PINPolicyType"
         minOccurs="0"/>
       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="KeyId" type="xs:string" use="required"/>
     <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
       use="required"/>
   </xs:complexType>

   The attributes of
          digits/characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates Key entity have the maximum number of bytes following meanings:

   o  KeyId (MANDATORY), a unique and global identifier of the unencoded value.

          Value MUST be:

             Unsigned integer.

5.1.10.2.  ResponseFormat (MANDATORY) symmetric
      key.  The ResponseFormat attribute defines the characteristics identifier is defined as a string of alphanumeric
      characters.

   o  <KeyAlgorithm (MANDATORY)>, the
   result unique URI of a computation.  This defines the format type of
      algorithm to use with the OTP or secret key, for profiles are described
      in Section 6.3

   The elements of the response to a challenge.  The Response attribute is defined by Key entity have the following sub-attributes:

   1.  Format (MANDATORY)

          Defines the format of the response generated by meanings:

   o  <Issuer (OPTIONAL)>, The key issuer name, this is normally the device and
          MUST be one
      name of the values defined in Section 6.3

   2.  CheckDigit (OPTIONAL)

          Defines if organization that issues the device needs to append a Luhn check digit key to the response.  This is only valid if end user of
      the Format attribute is
          'DECIMAL'.  Value MUST be:

             TRUE device will append a Luhn check digit key.  For example MyBank issuing hardware tokens to their
      retail banking users 'MyBank' would be the response.

             FALSE device will not append issuer.  The Issuer is
      defined as a Luhn check digit to the
             response.

   3.  Length (MANDATORY)

          Defines String.

   o  <Usage (MANDATORY)>, defines the length intended usage of the response generated by the device.

          If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates key and
      related metadata as defined in Section 5.3.2

   o  <CardAppPersoProfileId (OPTIONAL)>, A uniquie identifier used
      between the number sending and receiving party of digits/
          characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates the number of bytes container to
      establish a set of constant values related to a key that are not
      transmitted via the unencoded value.

          Value MUST be:

             Unsigned integer.

5.1.10.3.  AppProfileId (OPTIONAL)

   Defines the container.  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.  An example could be an EMV MasterCard CAP
      [CAP] application on a card that
   contains attributes or uses fixed personalised with data for a specific
      batch of cards such as:

         IAF Internet authentication flag

         CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
         VISA 13, VISA14)

         AIP (Application Interchange Profile), 2 bytes

         TVR Terminal Verification Result, 5 bytes

         CVR The card verification result

         AmountOther

         TransactionDate

         TerminalCountryCode

         TransactionCurrencyCode

         AmountAuthorised

         IIPB

      These values are not contained within attributes in the container
      but are shared between the manufacturing and the validation
      service through this unique AppProfileId.

5.1.11.  Logo (OPTIONAL)

   Specifies the logo image information associated with a key. CardAppPersoProfileId.  The logo
   type
      CardAppPersoProfileId is defined in as a separate schema file with namespace
   urn:ietf:params:xml:ns:keyprov:logo:1.0.

6.  Key container XML schema definitions String.

   o  <FriendlyName (OPTIONAL)>, The portable user friendly name that is assigned
      to the secret key container for easy reference.  The FriendlyName is defined by
      as a String.

   o  <Data (OPTIONAL)>, the following entities:

   1.  KeyContainer entity

   2.  Device entity

   3.  Key entity

   4.  User entity

   A KeyContainer MAY contain one or more Device entities.  A Device MAY
   contain one or more Key entities and may be associated element carrying the data related to one or more
   User entities.

   The figure below indicates a possible relationship diagram the
      key as defined in Section 5.3.1

   o  <PINPolicy (OPTIONAL)>, the policy of a
   container.

   --------------------------------------------
   | KeyContainer                             |
   |                                          |
   |  ------------------   -----------------  |
   |  | Device 1       |   | Device n      |  |
   |  |                |   |               |  |
   |  |  ------------  |   | ------------  |  |
   |  |  | Key 1    |  |   | | Key n    |  |  |
   |  |  ------------  |   | ------------  |  |
   |  |                |   |               |  |
   |  |                |   |               |  |
   |  |  ------------  |   | ------------  |  |
   |  |  | Key m    |  |   | | Key p    |  |  |
   |  |  ------------  |   | ------------  |  |
   |  ------------------   -----------------  |
   |      |                  |        |       |
   |      |                  |        |       |
   |  ----------        ---------- ---------- |
   |  | User 1 |        | User 1 | | User n | |
   |  ----------        ---------- ---------- |
   |                                          |
   --------------------------------------------

6.1.  XML Schema Types

   The following types are the PIN relating to the
      usage of this key as defined in Section 5.3.4

   o  <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not
      be possible to represent use this key after this date

   o  <StartDate (OPTIONAL)>, the start date of the key, it MUST not be
      possible to use this key before this date

5.3.1.  Data (OPTIONAL)

   Defines the portable key
   container entities and associated attributes.

6.1.1.  KeyType

   The KeyType represents data attributes of the key entity symmetric key.  Each is a name
   value pair which has either a plain value (in case of no encryption)
   or an encrypted value as defined in EncryptedDataType in XML
   Encryption.

   This is also where the KeyContainer.  The
   KeyType key value is transported, Section 7 defines a
   list of reserved attribute names.

   Data element is defined as follows:

   <complexType name="KeyType">
     <sequence>
        <element name="Issuer" type="string"/>
        <element name="Usage" type="pskc:UsageType"/>
        <element name="FriendlyName" type="string" minOccurs="0"/>
        <element name="Data" type="pskc:DataType" minOccurs="0"
        maxOccurs="unbounded"/>
        <element name="AccessRules" minOccurs="0">
           <complexType>
             <simpleContent>
             <extension base="string">
               <attribute name="UserPIN" type="boolean"
               default="false"/>
             </extension>
            </simpleContent>
           </complexType>
        </element>
        <element name="Logo" type="logo:LogoType" minOccurs="0"/>
        <element name="Expiry" type="string"

<xs:complexType name="DataType">
    <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"/>
     </sequence>
     <attribute name="KeyId" type="string" use="required"/>
     <attribute name="KeyAlgorithm" type=
     "pskc:KeyAlgorithmType"
    </xs:sequence>
    <xs:attribute name="Name" type="xs:string" use="required"/>
   </complexType>
</xs:complexType>

   The components attributes of the KeyType Data element have the following meanings (see meanings:

   o  Name, defines the name of the name-value pair, Section 5 for further information): 7 defines a
      list of reserved attribute names

   The elements of the Data element have the following meanings:

   o  <Usage>  The <PlainValue> conveys an unencrypted value of type UsageType the name-value
      pair in base 64 encoding.

   o  The <EncryptedValue> element in the DataType conveys an encrypted
      value of the name-value pair inside an EncryptedDataType as
      defined in XML Encryption.

   o  The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed
      MAC value of the unencrypted data for the cases where the key
      protection algorithm does not support integrity checks

5.3.2.  Usage (MANDATORY)

   The Usage element defines the usage attribute(s) of the key entity.
   Usage is defined as follows:

  <xs:complexType name="UsageType">
      <xs:sequence>
              <xs:element name="ResponseFormat">
                      <xs:complexType>
                          <xs:attribute name="Format"
                          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="ChallengeFormat" minOccurs="0">
                      <xs:complexType>
                          <xs:attribute name="Format"
                          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:sequence>
      <xs:attribute name="OTP" type="xs:boolean" default="false"/>
      <xs:attribute name="CR" type="xs:boolean" default="false"/>
      <xs:attribute name="Integrity" type="xs:boolean" default="false"/>
      <xs:attribute name="Encrypt" type="xs:boolean" default="false"/>
      <xs:attribute name="Unlock" type="xs:boolean" default="false"/>
  </xs:complexType>

   The attributes of the Secret Key. The Usage attribute is described in Section 5.1.3.

   o  <Issuer> identifies element define the issuer intended usage of the Secret Key. The Issuer
      attribute is described in Section 5.1.5.

   o  <FriendlyName> is
   key and are a user friendly name that is assigned combination of one or more of the following (set to
   true):

   o  OTP, the
      Secret Key key will be used for easy reference. OTP generation

   o  <Data> conveys  CR, the key will be used for Challenge/Response purposes

   o  Encrypt, the key will be used for data attributes (eg encryption purposes

   o  Integrity, the Secret Key) in name
      (string) value (base64 encoded) pairs.  The value can key will be
      encrypted, in this case used to generate a keyed message digest of the non-encrypted
      for data is
      present.  The <Data> component is further described below. integrity or authentication purposes.

   o  <AccessRules> Defines  Unlock, the rules key will be used for accessing an inverse challenge response in
      the credential on case a user has locked the device e.g. a password must be provided by entering a wrong PIN too
      many times (for devices with PIN-input capability)

5.3.2.1.  OTP and CR specific Usage elements (OPTIONAL)

   When the user key usage is set to view
      credential info OTP or use the credential CR, additional attributes MUST be
   provided to generate an support the OTP response

   o  KeyId is a global identifier of and/or the Secret Key. See Section 5.1.4.

   o  KeyAlgorithm defines response computation as
   required by the underlying algorithm used with and to customize or configure
   the Secret Key. The
      type values are defined in Section 6.2.

   o  Logo outcome of type LogoType associates display logos with this Secret
      Key

   o  Expiry the computation (format, length and usage modes).

5.3.2.1.1.  ChallengeFormat element (MANDATORY)

   The ChallengeFormat element defines the expiry date characteristics of the Secret Key
   challenge in format DD/MM/
      YYYY a CR usage scenario.  The <Data> Challenge element is of type <DataType> and is defined as follows:

   <complexType name="DataType">
     <sequence>
       <element name="Value" type="base64Binary"/>
       <element name="ValueDigest" type="base64Binary" minOccurs="0"/>
       <attribute name="Name" type="string" use="required"/>
     </sequence>
   </complexType>

   The 'Name' attribute defines
   by the following attributes:

   o  Format (MANDATORY)

         Defines the name format of the name-value pair, challenge accepted by the
   following list device and
         MUST be one of attribute names have been reserved:

      SECRET: the key key value values defined in binary, base64 encoded

      COUNTER: Section 5.3.3

   o  CheckDigit (OPTIONAL)

         Defines if the event counter for event based OTP algorithms. 8 bytes
      unsigned integer in big endian (i.e. network byte order) form
      base64 encoded

      TIME: device needs to check the time for time based OTP algorithms. 8 bytes unsigned
      integer appended Luhn check
         digit contained in big endian (i.e. network byte order) form base64
      encoded (Number of seconds since 1970)

      TIME_INTERVAL: a provided challenge.  This is only valid if
         the time interval value for time based OTP
      algorithms. 8 bytes unsigned integer Format attribute is 'DECIMAL'.  Value MUST be:

            TRUE device will check the appended Luhn check digit in big endian (i.e. network
      byte order) form base64 encoded.

   The <Value> element a
            provided challenge

            FALSE device will not check appended Luhn check digit in
            challenge

   o  Min (MANDATORY)

         Defines the DataType conveys the value minimum size of the name-
   value pair in base 64 encoding.  The value MAY be encrypted or in
   clear text as per the EncryptionMethod data element in challenge accepted by the
   KeyContainer (see Section 6.1.6
         device for details about KeyContainerType).
   When CR mode.

         If the value Format attribute is encrypted, the digest 'DECIMAL', 'HEXADECIMAL' or
         'ALPHANUMERIC' this value in 'ValueDigest' MUST
   be provided.  The digest MUST be calculated on indicates the unencrypted minimum number of
         digits/characters.

         If the Format attribute is 'BASE64' or 'BINARY', this value
   and MUST use
         indicates the Digest algorithms specified in DigestMethodType
   element minimum number of bytes of the KeyContainer.  The MAC key for the MAC calculation
   should use unencoded value.

         Value MUST be:

            Unsigned integer.

   o  Max (MANDATORY)

         Defines the same key as maximum size of the encryption key specified in challenge accepted by the
   EncryptionMethod unless a separate MAC key is specified.  When PBE
   method is used
         device for encryption, a different password CR mode.

         If the Format attribute is recommended
   for 'DECIMAL', 'HEXADECIMAL' or
         'ALPHANUMERIC' this value indicates the MAC key derivation.  When maximum number of
         digits/characters.

         If the key data Format attribute is in clear text, the
   KeyContainer payload signature MAY be used to check 'BASE64' or 'BINARY', this value
         indicates the integrity maximum number of bytes of the key octets.

6.1.2.  UsageType unencoded value.

         Value MUST be:

            Unsigned integer.

5.3.2.1.2.  ResponseFormat element (MANDATORY)

   The UsageType ResponseFormat element defines the usage attribute characteristics of the key entity.  The
   UsageType is defined as follows:

   <complexType name="UsageType">
     <sequence>
       <element name="ResponseFormat">
         <complexType>
           <attribute name="Format" type="pskc:ValueFormat"
           use="required"/>
           <attribute name="Length" type="unsignedInt"
           use="required"/>
           <attribute name="CheckDigits" type="boolean"
           default="false"/>
         </complexType>
       </element>
       <element name="ChallengeFormat" minOccurs="0">
         <complexType>
           <attribute name="Format" type="pskc:ValueFormat"
           use="required"/>
           <attribute name="Min" type="unsignedInt" use="required"/>
           <attribute name="Max" type="unsignedInt" use="required"/>
           <attribute name="CheckDigits" type="boolean"
           default="false"/>
         </complexType>
       </element>
       <element name="AppProfileId" type="string" minOccurs="0"/>
     </sequence>
     <attribute name="OTP" type="boolean"
     default="false"/>
     <attribute name="CR" type="boolean"
     default="false"/>
     <attribute name="Sign" type="boolean" default="false"/>
     <attribute name="Encrypt" type="boolean" default="false"/>
     <attribute name="Unlock" type="boolean" default="false"/>
   </complexType>

   The UsageType components have the following meanings:

   o  <ResponseFormat> holds the algorithm response attributes.

   o  <ChallengeFormat> hold the challenge attributes in CR based
      algorithm computations.

   o  <AppProfileId> Is result
   of a computation.  This defines the unique shared identifier for out format of band
      shared common parameters.

6.1.3.  DeviceType

   The DeviceType type represents the Device entity in OTP or of the Container.  A
   Device MAY be bound
   response to a user and MAY contain more than one keys.  It
   is recommended that a key is bound to one and only one Device. challenge.  The DeviceType Response attribute is defined as follows:

   <complexType name="DeviceType">
     <sequence>
       <element name="DeviceId" type="pskc:DeviceIdType"
       minOccurs="0"/>
       <element name="Key" type="pskc:KeyType"
       maxOccurs="unbounded"/>
       <element name="User" type="pskc:UserType" minOccurs="0"/>
     </sequence>
   </complexType>

   The components of the DeviceType have the following meanings:

   o  <DeviceId>, a unique identifier for the device, defined by the
      DeviceId type.

   o  <Key>, represents the key entity defined by the KeyType.
   following attributes:

   o  <User>, optionally identifies the owner or the user of the Device,
      as defined by  Format (MANDATORY)

         Defines the UserType .

6.1.4.  DeviceIdType

   The DeviceId type represents format of the identifying criteria to uniquely
   identify response generated by the device that contains and
         MUST be one of the associated keys.  Since devices
   can come in different form factors such as hardware tokens,
   smartcards, soft tokens values defined in Section 5.3.3

   o  CheckDigit (OPTIONAL)

         Defines if the device needs to append a mobile phone or PC etc this type allows
   different criteria Luhn check digit to be used.  Combined though the criteria MUST
   uniquely identify the device.  For example for hardware tokens
         response.  This is only valid if the
   combination of SerialNo and Manufacturer Format attribute is
         'DECIMAL'.  Value MUST be:

            TRUE device will uniquely identify append a Luhn check digit to the response.

            FALSE device but will not SerialNo alone since two different token manufacturers
   might issue devices with the same serial number (similar append a Luhn check digit to the
   IssuerDN and serial number of a certificate).  For keys hold on
   banking cards
            response.

   o  Length (MANDATORY)
         Defines the identification length of the device response generated by the device.

         If the Format attribute is often done via 'DECIMAL', 'HEXADECIMAL' or
         'ALPHANUMERIC' this value indicates the
   Primary Account Number (PAN, number of digits/
         characters.

         If the Format attribute is 'BASE64' or 'BINARY', this value
         indicates the big number printed on of bytes of the front unencoded value.

         Value MUST be:

            Unsigned integer.

5.3.3.  ValueFormat

   The ValueFormat element defines allowed formats for challenges or
   responses in OTP algorithms.

   ValueFormat is defined as follows:

   <simpleType name="ValueFormat">
     <restriction base="string">
       <enumeration value="DECIMAL"/>
       <enumeration value="HEXADECIMAL"/>
       <enumeration value="ALPHANUMERIC"/>
       <enumeration value="BASE64"/>
       <enumeration value="BINARY"/>
     </restriction>
   </simpleType>

      DECIMAL Only numerical digits

      HEXADECIMAL Hexadecimal response

      ALPHANUMERIC All letters and numbers (case sensitive)

      BASE64 Base 64 encoded

      BINARY Binary data, this is mainly used in case of connected
      devices

5.3.4.  PINPolicy

   The PINPolicy element defines a mean to define how the card) and an expiry date usage of the card.  DeviceId is an extensible
   type that allows all these different ways to uniquely identify a
   specific key containing device. is protected by a PIN.  The DeviceIdType PIN itself can be
   transmitted using the container as another Key

   PINPolicy is defined as follows:

   <complexType name="DeviceIdType">
    <sequence>
     <element name="Manufacturer" type="string"/>
     <element name="SerialNo" type="string"/>
     <element name="Model" type="string" minOccurs="0"/>
     <element name="IssueNo" type="string" minOccurs="0"/>
     <element name="Expiry" type="string"

  <xs:complexType name="PINPolicyType">
      <xs:sequence>
          <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
          <xs:element name="WrongPINtry" type="xs:unsignedInt"
            minOccurs="0"/>
    </sequence>
   </complexType>
      </xs:sequence>
      <xs:attribute name="PINKeyId" type="xs:string" use="required"/>
  </xs:complexType>

   The components attributes of the DeviceId type PINPolicy have the following meanings: meaning

   o  <Manufacturer>,  PINKeyId, the manufacturer unique key Id within this container that contains
      the value of the device.

   o  <Model>, PIN that protects the model key

   The elements of PINPolicy have the device (e.g one-button-HOTP-token-V1) following meaning

   o  <SerialNo>,  <PINUsageMode>, the serial number of way the device or PIN is used during the PAN (primary
      account number) in case usage of EMV (Europay-MasterCard-Visa) smart
      cards.

   o  <IssueNo>, the issue number
      key as defined in case of smart cards with the same
      PAN, equivalent to a PSN (PAN Sequence Number). Section 5.3.4.1

   o  <Expiry>,  <WrongPINtry>, the expiry date number of a device (such as times the one on an EMV
      card,used when issue numbers are PIN can be entered wrongly
      before it MUST not printed on cards).  In format
      DD/MM/YYYY

6.1.5.  UserType Type

   The UserType represents the identifying criteria to uniquely identify
   the user who is bound be possible to this device.

   The UserType is defined as follows:

   <complexType name="UserType">
     <sequence>
       <sequence>
         <element name="UserId" type="string" minOccurs="0"/>
         <element name="FirstName" type="string" minOccurs="0"/>
         <element name="LastName" minOccurs="0"/>
       </sequence>
       <element name="Org" type="string" minOccurs="0"/>
     </sequence>
   </complexType>

   The components of the UserType type have the following meanings:

   o  <FirstName>, user first name.

   o  <LastName>, user last name.

   o  <UserId>, user id (UID) or user name.

   o  <Org>, user organization name.

6.1.6.  KeyContainerType

   The KeyContainerType represents use the key container entity.  A
   Container MAY contain more than one Device entity; each Device entity
   MAY contain more than one Key entity. anymore

5.3.4.1.  PINUsageMode

   The KeyContainerType PINUsageMode element defines how the PIN is used with a specific
   key

   PINUsageMode is defined as follows:

    <complexType name="KeyContainerType">
      <sequence>
        <element name="EncryptionMethod" minOccurs="0">
          <complexType>
            <complexContent>
              <extension base="pskc:EncryptionMethodType"/>
            </complexContent>
          </complexType>
        </element>
        <element name="DigestMethod">
          <complexType>
            <complexContent>
              <extension base="pskc:DigestMethodType"/>
            </complexContent>
          </complexType>
        </element>
        <element name="Device" type="pskc:DeviceType"
                 maxOccurs="unbounded"/>
        <element name="Signature" type="ds:SignatureType"
                 minOccurs="0"/>
      </sequence>
      <attribute name="Version" type="pskc:VersionType" use="required"/>
    </complexType>

   <xs:complexType name="PINUsageModeType">
       <xs:choice maxOccurs="unbounded">
           <xs:element name="Local"/>
           <xs:element name="Prepend"/>
           <xs:element name="InAlgo"/>
       </xs:choice>
   </xs:complexType>

   The components elements of the KeyContainer PINPolicy have the following meanings: meaning

   o  Version,  <Local>, the version number for PIN is checked locally on the portable key container format
      (the XML schema defined in this document).

   o  <EncryptionMethod>, device before allowing
      the encryption method used key to protect be used in executing the Key
      data attributes algorithm

   o  <DigestMethod>,  <Prepend>, the digest method used PIN is prepended to sign the unencrypted OTP or response hance it
      MUST be chacked by the
      Secret Key data attributes validation server

   o  <Device>,  <InAlgo>, the host Device for one or more Keys.

   o  <Signature>, contains PIN is used as part of the signature value algorithm computation

6.  Usage and profile of algorithms for the Container.  When portable symmetric key
    container

   This section details the use of the XML encryption and XML signature is applied
   elements to protect the entire container, it MUST use XML
      Signature methods as defined keys transported in [XMLSIG].  The the cotainer.  It also
   profiles the number of algorithms supported by XML encryption and XML
   signature to a mandatory subset for interoperability.

   When no algorithm is
      enveloped.

6.1.7.  EncryptionMethodType provided the values within the container are
   unencrypted, implementations SHALL ensure the privacy of the key data
   through other standard mechanisms e.g. transport level encryption.

6.1.  Usage of EncryptionKey to protect keys in transit

   The EncryptionMethodType EncryptionKey element in the KeyContainer defines the key,
   algorithm and parameters used to encrypt the Secret Key data
   attributes in the Container.  The encryption is applied on each
   individual Secret Key data in the Container.  The encryption method
   MUST be the same for all Secret Key data in the container.

   The EncryptionMethodType is defined as follows:

     <complexType name="EncryptionMethodType">
       <sequence>
         <element name="EncKeyLabel" minOccurs="0"/>
         <choice>
           <sequence>
             <element name="KeyInfo"
                      type="ds:KeyInfoType" minOccurs="0"/>
             <element name="OAEPParams"
                      type="base64Binary" minOccurs="0"/>
           </sequence>
           <sequence>
             <element name="PBEEncryptionParam"
                      type="pskc:PBEEncryptionParamType" minOccurs="0"/>
             <element name="IV" type="base64Binary" minOccurs="0"/>
           </sequence>
           <any namespace="##other" processContents="strict"/>
         </choice>
       </sequence>
       <attribute name="Algorithm"
                  type="anyURI" use="required"/>
     </complexType>

       <complexType name="PBEEncryptionParamType">
       <sequence>
         <element name="PBESalt" type="base64Binary"
                  minOccurs="0"/>
         <element name="PBEIterationCount" type="int"
                  minOccurs="0"/>
       </sequence>
       <attribute name="EncryptionAlgorithm" type="anyURI"/>
     </complexType>

   The components following sections define specifically the different supported
   means to protect the keys:

6.1.1.  Protecting keys using a pre-shared key via symmetric algorithms

   When protecting the payload with pre-shared keys implementations
   SHOULD set the name of the EncryptionMethodType have specific pre-shared key in the KeyName
   element of the EncryptionKey of the KeyContainer.  For example:

   <KeyContainer Version="1.0"
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
     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>
       ....

   The following
   meanings:

   o  <EncKeyLabel>: identifies a unique label for a pre-shared
      encryption key.

   o  Algorithm: identifies is the list of symmetric key encryption algorithm and
   possible parameters used to protect the Secret Key data.  If EncryptionMethod is absent data in
      KeyContainerType, implementations the
   container.  Systems implementing PSKC MUST guarantee support the privacy MANDATORY
   algorithms detailed below.

   The encryption algorithm URI can be one of the Secret Key Data through other mechanisms e.g. through
      transport level security. following.

   o  <KeyInfo>: conveys the information of the key if an RSA algorithm
      has been used.  http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY
   o  <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has
      been used.  http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY

   o  <PBEEncryptionParam>: conveys the PBE parameters if a password-
      based encryption (PBE) algorithm has been used.  http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL

   o

      *  <PBESalt>: conveys the Salt when [PKCS5] password-based
         encryption is applied.

      *  <PBEIterationCount>: conveys the iteration count  http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY

   o  http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY

   o  http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY

   o  http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY

   o  http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL

   When algorithms without integrity checks are used (e.g.
   http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value in
         [PKCS5] password-based encryption if it is different from using
   the
         default value.

      *  <EncryptionAlgorithm>: specifies same key as the encryption algorithm after
         a PBE key is derived.  For example, PBE-AES128-CBC should use
         URI http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc

   o  <IV>: conveys SHOULD be placed in the initialization vector for CBC based encryption
      algorithms.  It is recommended for security reasons to transmit
      this value out ValueMAC
   element of band and treat it the same manner as the key
      value.

6.1.8.  DigestMethodType

   The DigestMethodType defines Data element.  In this case the MAC algorithm and parameters used to
   create type
   MUST be set in the digest on MACAlgorithm element in the unencrypted Secret Key data key container entity
   as defined in Section 5.1.  Implementations of PSKC MUST support the
   Container.
   MANDATORY MAC algorithms detailed below.  The digest is applied on each individual Secret Key data MACAlgorithm URI can be
   one of the following:

   o  http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY

   For example:

   <KeyContainer Version="1.0"
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
     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>
       .....

6.1.2.  Protecting keys using passphrase based encryption keys

   To be able to support passphrase based encryption keys as defined in
   PKCS#5 the Container before encryption.  The digest method MUST be following XML representation of the
   same for all Secret Key data PBE relates parameters
   have been introduced in the container.  Unless a different
   digest key is specified it is assumed that keyed digest algorithms
   will use schema.  Although the same key as for encryption

   The DigestMethodType approach is defined as follows:

     <complexType name="DigestMethodType">
       <sequence>
         <element name="DigestKeyLabel"
   extensible implementations of PSKC MUST support the
   KeyDerivationMethod algorithm URI of
   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2.

   <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"/>
       </sequence>
       <attribute
       </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" minOccurs="0"
                 maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="Algorithm"
                  type="anyURI" type="xs:anyURI" use="required"/>
     </complexType>
   </xs:complexType>

   The components attributes of the DigestMethodType DerivedKey have the following meanings:

   o  Algorithm, identifies  ID (OPTIONAL), the digest algorithm unique ID for this key

   o  Type (OPTIONAL), TODO

   The elements of the DerivedKey have the following meanings:

   o  <KeyDerivationMethod>: URI of the algorithms used to protect derive the
      Secret Key data.
      key e.g.
      (http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)

   o  <DigestKeyLabel>: identifies  <ReferenceList (OPTIONAL)>: a unique label for a pre-shared
      digest key.

6.2.  KeyAlgorithmType

   The KeyAlgorithmType defines list of IDs of the algorithms in which elements that
      have been encrypted by this key

   o  <CarriedKeyName (OPTIONAL)>: friendly name of the Secret Key
   data is used.  It refers to anyURI.

6.3.  ValueFormat

   The ValueFormat defines allowed formats for challenges or responses
   in key

   When using the OTP algorithms.

   The ValueFormat is defined as follows:

   <simpleType name="ValueFormat">
     <restriction base="string">
       <enumeration value="DECIMAL"/>
       <enumeration value="HEXADECIMAL"/>
       <enumeration value="ALPHANUMERIC"/>
       <enumeration value="BASE64"/>
       <enumeration value="BINARY"/>
     </restriction>
   </simpleType>

      DECIMAL Only numerical digits

      HEXADECIMAL Hexadecimal response

      ALPHANUMERIC All letters PKCS5 PBE algorithm
   (URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
   and numbers (case sensitive)

      BASE64 Base 64 encoded

      BINARY Binary data, this is mainly related parameters, the DerivedKey element MUST be used in case within
   the EncryptionKey element of connected
      devices

6.4.  Data elements

6.4.1.  KeyContainer

   The the KeyContainer data element is defined as:

   <element name="KeyContainer" type="pskc:KeyContainerType"/> in exactly the form as
   shown below:

<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
  xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
  xmlns:pkcs-5=
    "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
  Version="1.0">
    <EncryptionKey>
      <DerivedKey Id="#Passphrase1">
        <CarriedKeyName>Passphrase1</CarriedKeyName>
        <KeyDerivationMethod
          Algorithm=
        "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
          <Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
            <Salt>
              <Specified>Df3dRAhjGh8=</Specified>
            </Salt>
            <IterationCount>2000</IterationCount>
            <KeyLength>16</KeyLength>
            <PRF/>
          </Parameters>
        </KeyDerivationMethod>
      </DerivedKey>
    </EncryptionKey>
....

6.2.  Protecting keys using asymmetric algorithms

   The KeyContainer data element following is the list of type KeyContainerType defined in
   Section 6.1.6.

   The EncryptionMethod asymmetric key encryption algorithm and
   possible parameters used to protect the Secret Key data element in the KeyContainer defines
   container.  Systems implementing PSKC MUST support the MANDATORY
   algorithms detailed below.  The encryption algorithm URI can be one
   of the following.

   o  http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY

   o  http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL

   For example:

   TODO

6.3.  Profile of Key Algorithm

   This section profiles the type(s) of algorithm of that can be used to protect by
   the key(s) transported in the container.  The following algorithm
   URIs are among the default support list.

   o  http://www.w3.org/2001/04/xmlenc#tripledes-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes128-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes192-cbc

   o  http://www.w3.org/2001/04/xmlenc#aes256-cbc

   o  http://www.ietf.org/keyprov/pskc#hotp

   o  http://www.ietf.org/keyprov/pskc#valuecompare

6.3.1.  OTP Key data.  In Algorithm Identifiers

   OTP key algorithm URIs have not been defined in a multi-key
   KeyContainer, commonly available
   standard specification.  This document defines the same encryption method and following URIs for
   the same encryption key
   MUST known open standard OTP algorithms.

6.3.1.1.  HOTP

   Standard document: RFC4226

   Identifier: http://www.ietf.org/keyprov/pskc#hotp

   Note that the actual URL will be used finalized once a URL for all this
   document is determined.

6.3.1.2.  Other OTP Algorithms

   An implementation should refer to vendor supplied OTP key data elements.

   The KeyContainer data element MAY contain multiple Device data
   elements, allowing algorithm
   URIs for bulk provisioning of keys.

   The Signature data element is of type <ds:Signature> as proprietary algorithms.

6.3.2.  PIN key value compare algorithm identifier

   PIN key algorithm URIs have not been defined in
   [XMLSIG] and MAY be omitted in a commonly available
   standard specification.  This document defines the KeyContainer following URIs for
   a straight value comaprison of the transported secret key data element as
   when
   application layer provisioning or transport layer provisioning
   protocols provide required to compare a PIN.

   Identifier: http://www.ietf.org/keyprov/pskc#valuecompare

   Note that the integrity and authenticity of actual URL will be finalized once a URL for this
   document is determined.

7.  Reserved data attribute names

   The following key data attribute names have been reserved:

      SECRET: the payload
   between shared secret key value in binary, base64 encoded

      COUNTER: the sender and event counter for event based OTP algorithms. 8 bytes
      unsigned integer in big endian (i.e. network byte order) form
      base64 encoded

      TIME: the recipient time for time based OTP algorithms. 8 bytes unsigned
      integer in big endian (i.e. network byte order) form base64
      encoded (Number of seconds since 1970)

      TIME_INTERVAL: the container.  When
   required, this specification recommends using a symmetric key time interval value for time based
   signature with the same key used OTP
      algorithms. 8 bytes unsigned integer in big endian (i.e. network
      byte order) form base64 encoded.

      TIME_DRIFT: the encryption device clock drift value for time based OTP
      algorithms.  The value indicates number of seconds that the secret key
   data.  The signature is enveloped.

7. device
      clock may drift each day. 2 bytes unsigned integer in big endian
      (i.e. network byte order) form base64 encoded.

8.  Formal Syntax

   The following syntax specification uses the widely adopted XML schema
   format as defined by a W3C recommendation
   (http://www.w3.org/TR/xmlschema-0/).  It is a complete syntax
   definition in the XML Schema Definition format (XSD)

   All implementations of this standard must comply with the schema
   below.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
  xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.0"
  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:container:1.0"
  elementFormDefault="qualified" attributeFormDefault="unqualified"
  version="1.0">
    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
    schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
      schemaLocation=
      "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
      xmldsig-core-schema.xsd"/>
    <xs:import namespace="urn:ietf:params:xml:ns:keyprov:logo:1.0"
    schemaLocation="keyprov-logo-1.0.xsd"/> namespace="http://www.w3.org/2001/04/xmlenc#"
      schemaLocation="http://www.w3.org/TR/2002/
      REC-xmlenc-core-20021210/xenc-schema.xsd"/>

    <xs:complexType name="KeyContainerType">
    <xs:sequence>
        <xs:element name="EncryptionMethod" minOccurs="0">
        <xs:complexType>
          <xs:complexContent>
            <xs:extension base="pskc:EncryptionMethodType"/>
          </xs:complexContent>
        </xs:complexType>
      </xs:element> name="EncryptionKey" type="ds:KeyInfoType"
          minOccurs="0"/>
        <xs:element name="DigestMethod" minOccurs="0">
        <xs:complexType>
          <xs:complexContent>
            <xs:extension base="pskc:DigestMethodType"/>
          </xs:complexContent>
        </xs:complexType>
      </xs:element> name="MACAlgorithm" type="pskc:KeyAlgorithmType"
          minOccurs="0"/>
        <xs:element name="Device" type="pskc:DeviceType"
          maxOccurs="unbounded"/>
        <xs:element name="Signature" type="ds:SignatureType"
          minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="Version" type="pskc:VersionType"
      use="required"/>
    </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"/> type="xs:string" minOccurs="0"/>
            <xs:element name="Usage" type="pskc:UsageType"/>
            <xs:element name="CardAppPersoProfileId" type="xs:string"
              minOccurs="0"/>
            <xs:element name="FriendlyName" type="xs:string"
              minOccurs="0"/>
            <xs:element name="Data" type="pskc:DataType" minOccurs="0"
              maxOccurs="unbounded"/>
            <xs:element name="AccessRules" minOccurs="0">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:string">
              <xs:attribute name="UserPIN" type="xs:boolean"
                default="false"/>
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element> name="PINPolicy" type="pskc:PINPolicyType"
              minOccurs="0"/>
            <xs:element name="Logo" type="logo:LogoType" name="ExpiryDate" type="xs:dateTime"
              minOccurs="0"/>
            <xs:element name="Expiry" type="xs:string" name="StartDate" type="xs:dateTime"
              minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="KeyId" type="xs:string" use="required"/>
        <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
          use="required"/>
    </xs:complexType>
    <xs:complexType name="DeviceIdType"> name="DerivedKeyType">
        <xs:sequence>
            <xs:element name="Manufacturer" type="xs:string"/>
      <xs:element name="SerialNo" type="xs:string"/>
      <xs:element name="Model" type="xs:string" name="KeyDerivationMethod"
              type="pskc:KeyDerivationMethodType" minOccurs="0"/>
            <xs:element name="IssueNo" type="xs:string" ref="xenc:ReferenceList" minOccurs="0"/>
            <xs:element name="Expiry" 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="DeviceType"> name="KeyDerivationMethodType">
        <xs:sequence>
      <xs:element name="DeviceId" type="pskc:DeviceIdType"
               minOccurs="0"/>
      <xs:element name="Key" type="pskc:KeyType"
            <xs:any namespace="##other" minOccurs="0"
            maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:complexType name="PINPolicyType">
        <xs:sequence>
            <xs:element name="PINUsageMode"
              type="pskc:PINUsageModeType"/>
            <xs:element name="User" type="pskc:UserType" name="WrongPINtry" type="xs:unsignedInt"
              minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="PINKeyId" type="xs:string"
          use="required"/>
    </xs:complexType>
    <xs:complexType name="UserType">
    <xs:sequence> name="PINUsageModeType">
            <xs:choice maxOccurs="unbounded">
                    <xs:element name="Local"/>
                    <xs:element name="Prepend"/>
                    <xs:element name="Embed"/>
            </xs:choice>
    </xs:complexType>
    <xs:complexType name="DeviceIdType">
        <xs:sequence>
        <xs:element name="UserId" name="Manufacturer" type="xs:string"/>
        <xs:element name="SerialNo" type="xs:string"/>
        <xs:element name="Model" type="xs:string" minOccurs="0"/>
        <xs:element name="FirstName" name="IssueNo" type="xs:string" minOccurs="0"/>
        <xs:element name="LastName" name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
        <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="DeviceType">
      <xs:sequence>
        <xs:element name="DeviceId" type="pskc:DeviceIdType"
          minOccurs="0"/>
        <xs:element name="Key" type="pskc:KeyType"
          maxOccurs="unbounded"/>
        <xs:element name="Org" name="UserId" type="xs:string" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
    <xs:complexType name="UsageType">
        <xs:sequence>
            <xs:element name="ResponseFormat">
                <xs:complexType>
                    <xs:attribute name="Format"
                      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="ChallengeFormat" minOccurs="0">
                <xs:complexType>
                    <xs:attribute name="Format"
                      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="AppProfileId" type="xs:string" minOccurs="0"/>
            </xs:sequence>
            <xs:attribute name="OTP" type="xs:boolean" default="false"/>
            <xs:attribute name="CR" type="xs:boolean" default="false"/>
            <xs:attribute name="Sign" name="Integrity" type="xs:boolean"
              default="false"/>
            <xs:attribute name="Encrypt" type="xs:boolean"
              default="false"/>
            <xs:attribute name="Unlock" type="xs:boolean"
              default="false"/>
    </xs:complexType>
    <xs:complexType name="EncryptionMethodType"> name="DataType">
        <xs:sequence>
      <xs:element name="EncKeyLabel" minOccurs="0"/>
            <xs:choice>
        <xs:sequence>
          <xs:element name="KeyInfo"
                   type="ds:KeyInfoType" minOccurs="0"/>
          <xs:element name="OAEPParams"
                   type="xs:base64Binary" minOccurs="0"/>
        </xs:sequence>
        <xs:sequence>
                <xs:element name="PBEEncryptionParam"
                   type="pskc:PBEEncryptionParamType" minOccurs="0"/> name="PlainValue" type="xs:base64Binary"/>
                <xs:element name="IV" type="xs:base64Binary" minOccurs="0"/>
        </xs:sequence>
        <xs:any namespace="##other" processContents="strict"/> name="EncryptedValue"
                  type="xenc:EncryptedDataType"/>
            </xs:choice>
    </xs:sequence>
    <xs:attribute name="Algorithm"
               type="xs:anyURI" use="required"/>
  </xs:complexType>

  <xs:complexType name="PBEEncryptionParamType">
    <xs:sequence>
            <xs:element name="PBESalt" name="ValueMAC" type="xs:base64Binary"
              minOccurs="0"/>
      <xs:element name="PBEIterationCount" type="xs:int"
               minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="EncryptionAlgorithm" type="xs:anyURI"/>
  </xs:complexType>

  <xs:complexType name="DigestMethodType">
    <xs:sequence>
      <xs:element name="DigestKeyLabel" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="Algorithm"
               type="xs:anyURI" name="Name" type="xs:string" use="required"/>
    </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:element name="KeyContainer" type="pskc:KeyContainerType"/>

  <xs:complexType name="DataType">
    <xs:sequence>
      <xs:element name="Value" type="xs:base64Binary"/>
      <xs:element name="ValueDigest"
               type="xs:base64Binary" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="Name" type="xs:string"
               use="required"/>
  </xs:complexType>
</xs:schema>

   LogoType is defined in the following schema.

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

   <schema xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.0"
     targetNamespace="urn:ietf:params:xml:ns:keyprov:logo:1.0"
     elementFormDefault="qualified" attributeFormDefault="unqualified"
     version="1.0">

     <!-- LogoType -->
     <complexType name="LogoType">
       <annotation>
         <documentation xml:lang="en">
           Type to include logo information.
         </documentation>
       </annotation>
       <sequence>
         <element name="CommunityLogos" type="logo:LogoInfoType"
           minOccurs="0" maxOccurs="unbounded"/>
         <element name="IssuerLogo" type="logo:LogoInfoType"
           minOccurs="0"/>
         <element name="OtherLogos" type="logo:LogoInfoType"
           minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
     </complexType>

     <complexType name="LogoInfoType">
       <annotation>
         <documentation xml:lang="en">
           Define logo information for a given logo. It can either embed
           full logo data information, or includes only a reference URI
           where the full log data information with type LogoDataType
           can be downloaded.
         </documentation>
       </annotation>
       <sequence>
         <choice>
           <element name="LogoData" type="logo:LogoDataType"/>
           <element name="LogReference" type="anyURI"/>
         </choice>
       </sequence>
     </complexType>

     <complexType name="LogoDataType">
       <annotation>
         <documentation xml:lang="en">
           Define logo data information for a given logo image.
         </documentation>
       </annotation>
       <sequence>
         <element name="LogoImageDetails"
           type="logo:LogoImageDetailsType"/>
         <element name="LogoImageInfo" type="logo:LogoImageInfoType"
           minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="LogoImageDetailsType">
       <annotation>
         <documentation xml:lang="en">
           Define logo image data for a given logo image.
         </documentation>
       </annotation>
       <sequence>
         <choice>
           <element name="ImageData" type="base64Binary"/>
           <element name="ImageReference" type="anyURI"/>
         </choice>
       </sequence>
       <attribute name="MIMEType" type="logo:MIMETypeType"
         use="required"/>
     </complexType>

     <complexType name="LogoImageInfoType">
       <annotation>
         <documentation xml:lang="en">
           Define logo image parameters for a given logo image.
         </documentation>
       </annotation>
       <sequence>
         <element name="Size" type="integer" minOccurs="0"/>
         <element name="xSize" type="integer" minOccurs="0"/>
         <element name="ySize" type="integer" minOccurs="0"/>
         <element name="Resolution" type="logo:LogoImageResolutionType"
           minOccurs="0"/>
       </sequence>
       <attribute name="colored" type="boolean" default="true"/>
       <attribute name="lang" type="string" use="optional"/>
     </complexType>

     <complexType name="LogoImageResolutionType">
       <annotation>
         <documentation xml:lang="en">
           Define logo image resolution parameters.
         </documentation>
       </annotation>
       <sequence>
         <element name="NumBits" type="integer"/>
         <element name="TableSize" type="integer"/>
       </sequence>
     </complexType>

     <!-- MimeTypeType -->
     <simpleType name="MIMETypeType">
       <annotation>
         <documentation xml:lang="en">
           Can be one of the following supported image content types.
         </documentation>
       </annotation>
       <restriction base="string">
         <enumeration value="image/gif"/>
         <enumeration value="image/jpeg"/>
       </restriction>
     </simpleType>
   </schema>

8.

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

8.1.

9.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 of this writing both
   3DES and AES are recommended algorithms but 3DES may be dropped in
   the relatively near future.  Applications concerned with algorithm
   longevity are advised to use AES.  In cases where the exchange of
   encryption keys between the sender and the receiver is not possible,
   asymmetric encryption of the secret key payload may be employed.
   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
   [Schneier].

   Practical implementations should use PBESalt and PBEIterationCount
   when PBE encryption is used.  Different PBESalt value per credential
   record 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 [Schneier].  Validating
   the secure channel end-points is critically important for eliminating
   intruders that may compromise the confidentiality of the payload.

8.2.

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

8.3.

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

9.

10.  Acknowledgements

   The authors of this draft would like to thank the following people
   for their contributions and support to make this a better
   specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
   Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
   Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders
   Rundgren.

10.

11.  Appendix A - Example Symmetric Key Containers

   All examples are syntactically correct and compatible with the XML
   schema in section 7.  However, <Signature>,

11.1.  Symmetric Key <Value> and Container with a single Non-Encrypted HOTP Secret
       Key
   <ValueDigest> data values are fictitious

10.1.

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0"
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
       <Device>
           <DeviceId>
               <Manufacturer>ACME</Manufacturer>
               <SerialNo>0755225266</SerialNo>
           </DeviceId>
           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
             KeyId="0755225266">
               <Issuer>AnIssuer</Issuer>
               <Usage OTP="true">
                   <ResponseFormat Length="6" Format="DECIMAL"/>
               </Usage>
               <Data Name="COUNTER">
                   <PlainValue>AprkuA==</PlainValue>
               </Data>
               <Data Name="SECRET">
                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
               </Data>
               <ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
           </Key>
       </Device>
   </KeyContainer>

11.2.  Symmetric Key Container with a single PIN protected Non-Encrypted
       HOTP Secret Key
   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0
       keyprov-pskc-1.0.xsd" Version="1.0"> Version="1.0"
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
       <Device>
           <DeviceId>
           <Manufacturer>Token Manufacturer</Manufacturer>
           <SerialNo>98765432188</SerialNo>
           <Expiry>12/31/2012</Expiry>
               <Manufacturer>ACME</Manufacturer>
               <SerialNo>0755225266</SerialNo>
           </DeviceId>
           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
           KeyId="77654321871">
         <Issuer>Credential Issuer</Issuer>
             KeyId="0755225266">
               <Issuer>AnIssuer</Issuer>
               <Usage OTP="true">
                   <ResponseFormat Format="DECIMAL" Length="6"/> Length="6" Format="DECIMAL"/>
               </Usage>
           <FriendlyName>MyFirstToken</FriendlyName>
               <Data Name="COUNTER">
                   <PlainValue>AprkuA==</PlainValue>
               </Data>
               <Data Name="SECRET">
             <Value>
               zOkqJENSsh6b2hdXz1WBK/oprbY=
             </Value>
                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
               </Data>
               <PINPolicy PINKeyId="07552252661">
                   <PINUsageMode>
                       <Local/>
                   </PINUsageMode>
               </PINPolicy>
           </Key>
           <Key KeyId="07552252661"
             KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
               <Usage>
                   <ResponseFormat Length="4" Format="DECIMAL"/>
               </Usage>
               <Data Name="COUNTER">
             <Value>AAAAAAAAAAA=</Value> Name="SECRET">
                   <PlainValue>MTIzNA==</PlainValue>
               </Data>
           <Expiry>10/30/2012</Expiry>
           </Key>
       </Device>
   </KeyContainer>

10.2.

11.3.  Symmetric Key Container with a single Password-based AES-256-CBC Encrypted HOTP
       Secret Key

<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
  xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0
      keyprov-pskc-1.0.xsd" Version="1.0">
      <EncryptionMethod Algorithm=
         "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
        <PBEEncryptionParam EncryptionAlgorithm=
          "http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc">
          <PBESalt>y6TzckeLRQw=</PBESalt>
          <PBEIterationCount>1024</PBEIterationCount>
        </PBEEncryptionParam>
        <IV>c2FtcGxlaXY=</IV>
      </EncryptionMethod>
      <DigestMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
  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>
        <DeviceId>
          <Manufacturer>Token Manufacturer</Manufacturer>
          <SerialNo>98765432187</SerialNo>
          <Expiry>12/31/2012</Expiry>
            <Manufacturer>ACME</Manufacturer>
            <SerialNo>0755225266</SerialNo>
        </DeviceId>
        <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
          KeyId="77654321870">
        <Issuer>Credential Issuer</Issuer>
          KeyId="0755225266">
            <Issuer>AnIssuer</Issuer>
            <Usage OTP="true">
                <ResponseFormat Format="DECIMAL" Length="6"/> Length="8" Format="DECIMAL"/>
            </Usage>
          <FriendlyName>MyFirstToken</FriendlyName>
            <Data Name="SECRET">
            <Value>
              JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg==
            </Value>
            <ValueDigest>
              i8j+kpbfKQsSlwmJYS99lQ==
            </ValueDigest> Name="COUNTER">
                <PlainValue>AprkuA==</PlainValue>
            </Data>
            <Data Name="COUNTER">
            <Value>AAAAAAAAAAA=</Value> Name="SECRET">
                <EncryptedValue>
                    <xenc:EncryptionMethod
               Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                    <xenc:CipherData>
                      <xenc:CipherValue>
                        kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
                      </xenc:CipherValue>
                    </xenc:CipherData>
                </EncryptedValue>
                <ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>
            </Data>
          <Expiry>10/30/2012</Expiry>
        </Key>
    </Device>
</KeyContainer>

11.

11.4.  Symmetric Key Container with signature and a single Password-
       based Encrypted HOTP Secret Key

 <?xml version="1.0" encoding="UTF-8"?>
 <pskc:KeyContainer
   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
   xmlns:pkcs-5=
     "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Version="1.0">
     <pskc:EncryptionKey>
       <pskc:DerivedKey Id="#Passphrase1">
         <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
         <pskc:KeyDerivationMethod
           Algorithm=
      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
           <pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
             <Salt>
               <Specified>Df3dRAhjGh8=</Specified>
             </Salt>
             <IterationCount>2000</IterationCount>
             <KeyLength>16</KeyLength>
             <PRF/>
           </pkcs-5:Parameters>
         </pskc:KeyDerivationMethod>
         <xenc:ReferenceList>
           <xenc:DataReference URI="#ED"/>
         </xenc:ReferenceList>
       </pskc:DerivedKey>
     </pskc:EncryptionKey>
   <pskc:Device>
     <pskc:DeviceId>
       <pskc:Manufacturer>ACME</pskc:Manufacturer>
       <pskc:SerialNo>0755225266</pskc:SerialNo>
     </pskc:DeviceId>
         <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
           KeyId="0755225266">
             <pskc:Issuer>AnIssuer</pskc:Issuer>
             <pskc:Usage OTP="true">
                 <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
             </pskc:Usage>
             <pskc:Data Name="COUNTER">
                 <pskc:PlainValue>AprkuA==</pskc:PlainValue>
             </pskc:Data>
             <pskc:Data Name="SECRET">
                 <pskc:EncryptedValue Id="ED">
                   <xenc:EncryptionMethod Algorithm=
                   "http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
                   <xenc:CipherData>
                     <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
                     </xenc:CipherValue>
                   </xenc:CipherData>
                 </pskc:EncryptedValue>
             </pskc:Data>
         </pskc:Key>
   </pskc:Device>
   <pskc: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="">
         <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=KeyProvisioning'R'Us.com,C=US
           </ds:X509IssuerName>
           <ds:X509SerialNumber>12345678</ds:X509SerialNumber>
         </ds:X509IssuerSerial>
       </ds:X509Data>
     </ds:KeyInfo>
   </pskc:Signature>
 </pskc:KeyContainer>

11.5.  Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
       Secret Key

<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer Version="1.0"
  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <pskc:EncryptionKey>
        <ds:X509Data>
            <ds:X509Certificate>miib</ds:X509Certificate>
        </ds:X509Data>
    </pskc:EncryptionKey>
    <pskc:Device>
        <pskc:DeviceId>
            <pskc:Manufacturer>ACME</pskc:Manufacturer>
            <pskc:SerialNo>0755225266</pskc:SerialNo>
        </pskc:DeviceId>
        <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
                  KeyId="0755225266">
            <pskc:Issuer>AnIssuer</pskc:Issuer>
            <pskc:Usage OTP="true">
                <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
            </pskc:Usage>
            <pskc:Data Name="COUNTER">
                <pskc:PlainValue>AprkuA==</pskc:PlainValue>
            </pskc:Data>
            <pskc:Data Name="SECRET">
              <pskc:EncryptedValue Id="ED">
                <xenc:EncryptionMethod
                  Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
                <xenc:CipherData>
                  <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
                  </xenc:CipherValue>
                </xenc:CipherData>
              </pskc:EncryptedValue>
            </pskc:Data>
        </pskc:Key>
    </pskc:Device>
</pskc:KeyContainer>

12.  Normative References

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

   [DSKPP]    "Dynamic Symmetric Key Provisioning Protocol", Internet
              Draft Informational, URL: http://tools.ietf.org/wg/
              keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.

   [HOTP]     MRaihi, D., "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226,
              URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
              December 2005.

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

   [OATHRefArch]
              OATH, "Reference Architecture",
              URL: http://www.openauthentication.org, Version 1.0, 2005.

   [OCRA]     MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
              Internet Draft Informational, URL: http://www.ietf.org/
              internet-drafts/
              draft-mraihi-mutual-oath-hotp-variants-01.txt,
              December 2005.

   [PKCS1]    Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
              Specifications Version 2.0.",
              URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
              October 1998.

   [PKCS12]   RSA Laboratories, "PKCS #12: Personal Information Exchange
              Syntax Standard", Version 1.0,
              URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.

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

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997,
              <http://www.ietf.org/rfc/rfc2119.txt>.

   [Schneier]
              Schneier, B., "Secrets and Lies: Digitial Security in a
              Networked World",  Wiley Computer Publishing, ISBN 0-8493-
              8253-7, 2000.

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

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

Authors' Addresses

   Philip Hoyer
   ActivIdenity,
   ActivIdentity, Inc.
   109 Borough High Street
   London, SE1  1NL
   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

   Shuh Chang
   Gemalto Inc.

   Email: shuh.chang@gemalto.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).