tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6030

 Errata 
Proposed STD
Pages: 58
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: KEYPROV

Portable Symmetric Key Container (PSKC)

Part 1 of 3, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          P. Hoyer
Request for Comments: 6030                                 ActivIdentity
Category: Standards Track                                         M. Pei
ISSN: 2070-1721                                                 VeriSign
                                                              S. Machani
                                                              Diversinet
                                                            October 2010


                Portable Symmetric Key Container (PSKC)

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6030.

Page 2 
Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................4
      1.1. Key Words ..................................................4
      1.2. Version Support ............................................4
      1.3. Namespace Identifiers ......................................5
           1.3.1. Defined Identifiers .................................5
           1.3.2. Referenced Identifiers ..............................5
   2. Terminology .....................................................6
   3. Portable Key Container Entities Overview and Relationships ......6
   4. <KeyContainer> Element: The Basics ..............................8
      4.1. <Key>: Embedding Keying Material and Key-Related
           Information ................................................8
      4.2. Key Value Encoding ........................................10
           4.2.1. AES Key Value Encoding .............................11
           4.2.2. Triple-DES Key Value Encoding ......................11
      4.3. Transmission of Supplementary Information .................12
           4.3.1. <DeviceInfo> Element: Unique Device
                  Identification .....................................13
           4.3.2. <CryptoModuleInfo> Element: CryptoModule
                  Identification .....................................15
           4.3.3. <UserId> Element: User Identification ..............15
           4.3.4. <AlgorithmParameters> Element:
                  Supplementary Information for OTP and CR Algorithms 15
      4.4. Transmission of Key Derivation Values .....................17
   5. Key Policy .....................................................19
      5.1. PIN Algorithm Definition ..................................23
   6. Key Protection Methods .........................................23
      6.1. Encryption Based on Pre-Shared Keys .......................24
           6.1.1. MAC Method .........................................26
      6.2. Encryption Based on Passphrase-Based Keys .................27
      6.3. Encryption Based on Asymmetric Keys .......................29

Top      ToC       Page 3 
      6.4. Padding of Encrypted Values for Non-Padded
           Encryption Algorithms .....................................31
   7. Digital Signature ..............................................31
   8. Bulk Provisioning ..............................................33
   9. Extensibility ..................................................35
   10. PSKC Algorithm Profile ........................................36
      10.1. HOTP .....................................................36
      10.2. PIN ......................................................37
   11. XML Schema ....................................................38
   12. IANA Considerations ...........................................44
      12.1. Content-Type Registration for 'application/pskc+xml' .....44
      12.2. XML Schema Registration ..................................45
      12.3. URN Sub-Namespace Registration ...........................46
      12.4. PSKC Algorithm Profile Registry ..........................46
      12.5. PSKC Version Registry ....................................47
      12.6. Key Usage Registry .......................................47
   13. Security Considerations .......................................48
      13.1. PSKC Confidentiality .....................................49
      13.2. PSKC Integrity ...........................................50
      13.3. PSKC Authenticity ........................................50
   14. Contributors ..................................................50
   15. Acknowledgements ..............................................50
   16. References ....................................................51
      16.1. Normative References .....................................51
      16.2. Informative References ...................................52
   Appendix A.  Use Cases ............................................54
     A.1.  Online Use Cases ..........................................54
       A.1.1.  Transport of Keys from Server to Cryptographic
               Module ................................................54
       A.1.2.  Transport of Keys from Cryptographic Module to
               Cryptographic Module ..................................54
       A.1.3.  Transport of Keys from Cryptographic Module to
               Server ................................................55
       A.1.4.  Server-to-Server Bulk Import/Export of Keys ...........55
     A.2.  Offline Use Cases .........................................55
       A.2.1.  Server-to-Server Bulk Import/Export of Keys ...........55
   Appendix B.  Requirements .........................................56

Top      ToC       Page 4 
1.  Introduction

   With the increasing use of symmetric-key-based systems, such as
   encryption of data at rest or systems used for strong authentication,
   such as those based on One-Time Password (OTP) and Challenge/Response
   (CR) mechanisms, there is a need for vendor interoperability and a
   standard format for importing and exporting (provisioning) symmetric
   keys.  For instance, traditionally, vendors of authentication servers
   and service providers have used proprietary formats for importing and
   exporting these keys into their systems, thus making it hard to use
   tokens from two different vendors.

   This document defines a standardized XML-based key container, called
   Portable Symmetric Key Container (PSKC), for transporting symmetric
   keys and key-related metadata.  The document also specifies the
   information elements that are required when the symmetric key is
   utilized for specific purposes, such as the initial counter in the
   HMAC-Based One-Time Password (HOTP) [HOTP] algorithm.  It also
   creates an IANA registry for algorithm profiles where algorithms,
   their metadata and PSKC transmission profile can be recorded for a
   centralized, standardized reference.

1.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Version Support

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

   The numbering scheme for PSKC versions is "<major>.<minor>".  The
   major and minor numbers MUST be treated as separate integers and each
   number MAY be incremented higher than a single digit.  Thus, "PSKC
   2.4" would be a lower version than "PSKC 2.13", which in turn would
   be lower than "PSKC 12.3".  Leading zeros (e.g., "PSKC 6.01") MUST be
   ignored by recipients and MUST NOT be sent.

   The major version number should be incremented only if the message
   format (e.g., element structure) has changed so dramatically that an
   older version implementation would not be able to interoperate with a
   newer version.  The minor version number indicates new capabilities,
   and it MUST be ignored by an entity with a smaller minor version
   number but used for informational purposes by the entity with the
   larger minor version number.

Top      ToC       Page 5 
1.3.  Namespace Identifiers

   This document uses Uniform Resource Identifiers (URIs) [RFC3986] to
   identify resources, algorithms, and semantics.

1.3.1.  Defined Identifiers

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

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

   References to qualified elements in the PSKC schema defined in this
   specification and used in the example use the prefix "pskc" (defined
   as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc").  It is
   RECOMMENDED to use this namespace in implementations.

1.3.2.  Referenced Identifiers

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

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

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

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

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

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

   When protecting keys in transport with passphrase-based keys, PSKC
   also relies on the derived key element defined in the XML Encryption
   Version 1.1 [XMLENC11] namespace:

   xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"

   References to the XML Encryption Version 1.1 namespace are
   represented by the prefix "xenc11".

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

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

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

2.  Terminology

   NOTE: In subsequent sections of the document, we highlight
   **mandatory** XML elements and attributes.  Optional elements and
   attributes are not explicitly indicated, i.e., if it does not say
   mandatory, it is optional.

3.  Portable Key Container Entities Overview and Relationships

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

   1.  KeyContainer entity - representing the container that carries a
       number of KeyPackage entities.  A valid container MUST carry at
       least one KeyPackage entity.

   2.  KeyPackage entity - representing the package of at most one key
       and its related provisioning endpoint or current usage endpoint,
       such as a physical or virtual device and a specific CryptoModule.

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

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

   5.  Key entity - representing the key transported or provisioned.

   6.  Data entity - representing a list of metadata related to the key,
       where the element name is the name of the metadata and its
       associated value is either in encrypted (for example, for <Data>
       element <Secret>) or plaintext (for example, the <Data> element
       <Counter>) form.

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

Top      ToC       Page 7 
      -----------------
      | KeyContainer  |
      |---------------|
      | EncryptionKey |
      | Signature     |
      | ...           |
      -----------------
              |
              |
             /|\ 1..n
      ----------------        ----------------
      | KeyPackage   |    0..1| DeviceInfo   |
      |--------------|--------|--------------|
      |              |--      | SerialNumber |
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |         |     ----------------
             /|\ 0..1   |
      ----------------  |     --------------------
      | Key          |  | 0..1| CryptoModuleInfo |
      |--------------|   -----|------------------|
      | Id           |        | Id               |
      | Algorithm    |        |....              |
      | UserId       |        --------------------
      | Policy       |
      | ....         |
      ----------------
              |
              |
             /|\ 0..n
          --------------------------------------- -  -
          |                     |              |
      ------------------  ----------------  -------- - -
      | Data:Secret    |  | Data:Counter |  | Data:other
      |----------------|  |--------------|  |-- - -
      | EncryptedValue |  | PlainValue   |
      | ValueMAC       |  ----------------
      ------------------

             Figure 1: PSKC Data Elements Relationship Diagram

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

Top      ToC       Page 8 
4.  <KeyContainer> Element: The Basics

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

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

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0"
       Id="exampleID1"
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <KeyPackage>
           <Key Id="12345678"
               Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
               <Issuer>Issuer-A</Issuer>
               <Data>
                   <Secret>
                       <PlainValue>MTIzNA==
                       </PlainValue>
                   </Secret>
               </Data>
           </Key>
       </KeyPackage>
   </KeyContainer>

                Figure 2: Basic PSKC Key Container Example

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

   'Version':  The 'Version' attribute is used to identify the version
      of the PSKC schema version.  This specification defines the
      initial version ("1.0") of the PSKC schema.  This attribute MUST
      be included.

   'Id':  The 'Id' attribute carries a unique identifier for the
      container.  As such, it helps to identify a specific key container
      in cases in which multiple containers are embedded in larger XML
      documents.

4.1.  <Key>: Embedding Keying Material and Key-Related Information

   The following attributes of the <Key> element MUST be included at a
   minimum:

Top      ToC       Page 9 
   'Id':  This attribute carries a unique identifier for the symmetric
      key in the context of key provisioning exchanges between two
      parties.  This means that if PSKC is used in multiple interactions
      between a sending and receiving party, using different containers
      referencing the same keys, the 'Id' attribute of <Key> MUST use
      the same value (e.g., after initial provisioning, if a system
      wants to update key metadata values in the other system, the value
      of the 'Id' attribute of the <Key> where the metadata is to be
      updated MUST be the same of the original 'Id' attribute value
      provisioned).  The identifier is defined as a string of
      alphanumeric characters.

   'Algorithm':  This attribute contains a unique identifier for the
      PSKC algorithm profile.  This profile associates specific
      semantics to the elements and attributes contained in the <Key>
      element.  This document describes profiles for open standards
      algorithms in Section 10.  Additional profiles are defined in the
      following informative document: [PSKC-ALGORITHM-PROFILES].

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

   <Issuer>:  This element represents the name of the party that issued
      the key.  For example, a bank "Foobar Bank, Inc." issuing hardware
      tokens to their retail banking users may set this element to
      'Foobar Bank, Inc.'.

   <FriendlyName>:  A human-readable name for the secret key for easier
      reference.  This element serves informational purposes only.  This
      element is a language-dependent string; hence, it SHOULD have an
      attribute xml:lang="xx" where xx is the language identifier as
      specified in [RFC5646].  If no xml:lang attribute is present,
      implementations MUST assume the language to be English as defined
      by setting the attribute value to 'en' (e.g., xml:lang="en").

   <AlgorithmParameters>:  This element carries parameters that
      influence the result of the algorithmic computation, for example,
      response truncation and format in OTP and CR algorithms.  A more
      detailed discussion of the element can be found in Section 4.3.4.

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

      <Secret>:  This element carries the value of the key itself in a
         binary representation.  Please see Section 4.2 for more details
         on Key Value Encoding.

Top      ToC       Page 10 
      <Counter>:  This element contains the event counter for event-
         based OTP algorithms.

      <Time>:  This element contains the time for time-based OTP
         algorithms.  (If time intervals are used, this element carries
         the number of time intervals passed from a specific start
         point, normally it is algorithm dependent).

      <TimeInterval>:  This element carries the time interval value for
         time-based OTP algorithms in seconds (a typical value for this
         would be 30, indicating a time interval of 30 seconds).

      <TimeDrift>:  This element contains the device clock drift value
         for time-based OTP algorithms.  The integer value (positive or
         negative drift) that indicates the number of time intervals
         that a validation server has established the device clock
         drifted after the last successful authentication.  So, for
         example, if the last successful authentication established a
         device time value of 8 intervals from a specific start date but
         the validation server determines the time value at 9 intervals,
         the server SHOULD record the drift as -1.

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

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

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

      ValueMAC:  The <ValueMAC> element is populated with a Message
         Authentication Code (MAC) generated from the encrypted value in
         case the encryption algorithm does not support integrity
         checks.  The example shown in Figure 2 illustrates the usage of
         the <Data> element with two child elements, namely <Secret> and
         <Counter>.  Both elements carry a plaintext value within the
         <PlainValue> child element.

4.2.  Key Value Encoding

   Two parties receiving the same key value OCTET STRING, resulting in
   decoding the xs:base64Binary, inside the <PlainValue> or
   <EncryptedValue> elements, must make use of the key in exactly the
   same way in order to interoperate.  To ensure that, it is necessary
   to define a correspondence between the OCTET STRING and the notation
   in the standard algorithm description that defines how the key is

Top      ToC       Page 11 
   used.  The next sections establish that correspondence for the AES
   algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or
   Triple DES) [SP800-67].  Unless otherwise specified for a specific
   algorithm, the OCTET STRING encoding MUST follow the AES Key Value
   Encoding.

4.2.1.  AES Key Value Encoding

   [FIPS197], Section 5.2, titled "Key Expansion", uses the input key as
   an array of bytes indexed starting at 0.  The first octet of the
   OCTET STRING SHALL become the key byte in the AES, labeled index 0 in
   [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key
   bytes in AES, in increasing index order.

   Proper parsing and key load of the contents of the OCTET STRING for
   AES SHALL be determined by using the following value for the
   <PlainValue> element (binaryBase64-encoded) to generate and match the
   key expansion test vectors in [FIPS197], Appendix A, for AES

   Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c

   ...
    <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue>
   ...

4.2.2.  Triple-DES Key Value Encoding

   A Triple-DES key consists of three keys for the cryptographic engine
   (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8
   parity bits); the three keys are also collectively referred to as a
   key bundle [SP800-67].  A key bundle may employ either two or three
   independent keys.  When only two independent keys are employed
   (called two-key Triple DES), the same value is used for Key1 and
   Key3.

   Each key in a Triple-DES key bundle is expanded into a key schedule
   according to a procedure defined in [SP800-67], Appendix A.  That
   procedure numbers the bits in the key from 1 to 64, with number 1
   being the leftmost, or most significant bit (MSB).  The first octet
   of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1
   being the MSB.  The second octet of the OCTET STRING SHALL be bits 9
   through 16 of Key1, and so forth, so that the trailing octet of the
   OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key
   Triple DES).

Top      ToC       Page 12 
   Proper parsing and key load of the contents of the OCTET STRING for
   Triple DES SHALL be determined by using the following <PlainValue>
   element (binaryBase64-encoded) to generate and match the key
   expansion test vectors in [SP800-67], Appendix B, for the key bundle:

   Key1 = 0123456789ABCDEF

   Key2 = 23456789ABCDEF01

   Key3 = 456789ABCDEF0123

   ...
    <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue>
   ...

4.3.  Transmission of Supplementary Information

   A PSKC document can contain a number of additional information
   regarding device identification, cryptographic module identification,
   user identification, and parameters for usage with OTP and CR
   algorithms.  The following example, see Figure 3, is used as a
   reference for the subsequent sub-sections.

Top      ToC       Page 13 
   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0"
       Id="exampleID1"
       xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>Manufacturer</Manufacturer>
               <SerialNo>987654321</SerialNo>
               <UserId>DC=example-bank,DC=net</UserId>
           </DeviceInfo>
           <CryptoModuleInfo>
               <Id>CM_ID_001</Id>
           </CryptoModuleInfo>
           <Key Id="12345678"
               Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
               <Issuer>Issuer</Issuer>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </AlgorithmParameters>
               <Data>
                   <Secret>
                       <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
                       </PlainValue>
                   </Secret>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
               <UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
           </Key>
       </KeyPackage>
   </KeyContainer>

       Figure 3: PSKC Key Container Example with Supplementary Data

4.3.1.  <DeviceInfo> Element: Unique Device Identification

   The <DeviceInfo> element uniquely identifies the device to which the
   <KeyPackage> is provisioned.  Since devices can come in different
   form factors, such as hardware tokens, smart-cards, soft tokens in a
   mobile phone, or as a PC, this element allows different child element
   combinations to be used.  When combined, the values of the child
   elements MUST uniquely identify the device.  For example, for
   hardware tokens, the combination of <SerialNo> and <Manufacturer>
   elements uniquely identifies a device, but the <SerialNo> element
   alone is insufficient since two different token manufacturers might
   issue devices with the same serial number (similar to the Issuer
   Distinguished Name and serial number of a certificate).

Top      ToC       Page 14 
   The <DeviceInfo> element has the following child elements:

   <Manufacturer>:  This element indicates the manufacturer of the
      device.  Values for the <Manufacturer> element MUST be taken from
      either [OATHMAN] prefixes (i.e., the left column) or from the IANA
      Private Enterprise Number Registry [IANAPENREG], using the
      Organization value.  When the value is taken from [OATHMAN],
      "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
      from [OATHMAN]>").  When the value is taken from [IANAPENREG],
      "iana."  MUST be prepended to the value (e.g., "iana.<Organization
      value from [IANAPENREG]>").

   <SerialNo>:  This element contains the serial number of the device.

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

   <IssueNo>:  This element contains the issue number in case there are
      devices with the same serial number so that they can be
      distinguished by different issue numbers.

   <DeviceBinding>:  This element allows a provisioning server to ensure
      that the key is going to be loaded into the device for which the
      key provisioning request was approved.  The device is bound to the
      request using a device identifier, e.g., an International Mobile
      Equipment Identity (IMEI) for the phone, or an identifier for a
      class of identifiers, e.g., those for which the keys are protected
      by a Trusted Platform Module (TPM).

   <StartDate> and <ExpiryDate>:  These two elements indicate the start
      and end date of a device (such as the one on a payment card, used
      when issue numbers are not printed on cards).  The date MUST be
      expressed as a dateTime value in "canonical representation"
      [W3C.REC-xmlschema-2-20041028].  Implementations SHOULD NOT rely
      on time resolution finer than milliseconds and MUST NOT generate
      time instants that specify leap seconds.  Keys that reside on the
      device SHOULD only be used when the current date is after the
      <StartDate> and before the <ExpiryDate>.  Note that usage
      enforcement of the keys with respect to the dates MAY only happen
      on the validation server, as some devices such as smart cards do
      not have an internal clock.  Systems thus SHOULD NOT rely upon the
      device to enforce key usage date restrictions.

   Depending on the device type, certain child elements of the
   <DeviceInfo> element MUST be included in order to uniquely identify a
   device.  This document does not enumerate the different device types
   and therefore does not list the elements that are mandatory for each
   type of device.

Top      ToC       Page 15 
4.3.2.  <CryptoModuleInfo> Element: CryptoModule Identification

   The <CryptoModuleInfo> element identifies the cryptographic module to
   which the symmetric keys are or have been provisioned.  This allows
   the identification of the specific cases where a device MAY contain
   more than one crypto module (e.g., a PC hosting a TPM and a connected
   token).

   The <CryptoModuleInfo> element has a single child element that MUST
   be included:

   <Id>:  This element carries a unique identifier for the CryptoModule
      and is implementation specific.  As such, it helps to identify a
      specific CryptoModule to which the key is being or was
      provisioned.

4.3.3.  <UserId> Element: User Identification

   The <UserId> element identifies the user of a distinguished name, as
   defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.

   Although the syntax of the user identifier is defined, there are no
   semantics associated with this element, i.e., there are no checks
   enforcing that only a specific user can use this key.  As such, this
   element is for informational purposes only.

   This element may appear in two places, namely as a child element of
   the <Key> element, where it indicates the user with whom the key is
   associated, and as a child element of the <DeviceInfo> element, where
   it indicates the user with whom the device is associated.

4.3.4.  <AlgorithmParameters> Element: Supplementary Information for OTP
        and CR Algorithms

   The <AlgorithmParameters> element is a child element of the <Key>
   element, and this document defines three child elements: <Suite>,
   <ChallengeFormat>, and <ResponseFormat>.

   <Suite>:

      The optional <Suite> element defines additional characteristics of
      the algorithm used, which are algorithm specific.  For example, in
      an HMAC-based (Hashed MAC) OTP algorithm, it could designate the
      strength of the hash algorithm used (SHA1, SHA256, etc.).  Please
      refer to the algorithm profile section, Section 10, for the exact
      semantics of the value for each algorithm profile.

Top      ToC       Page 16 
   <ChallengeFormat>:

      The <ChallengeFormat> element defines the characteristics of the
      challenge in a CR usage scenario whereby the following attributes
      are defined:

      'Encoding':  This attribute, which MUST be included, defines the
         encoding of the challenge accepted by the device and MUST be
         one of the following values:

         DECIMAL:  Only numerical digits

         HEXADECIMAL:  Hexadecimal response

         ALPHANUMERIC:  All letters and numbers (case sensitive)

         BASE64:  Base-64 encoded, as defined in Section 4 of [RFC4648]

         BINARY:  Binary data

      'CheckDigit':  This attribute indicates whether a device needs to
         check the appended Luhn check digit, as defined in
         [ISOIEC7812], contained in a challenge.  This is only valid if
         the 'Encoding' attribute is set to 'DECIMAL'.  A value of TRUE
         indicates that the device will check the appended Luhn check
         digit in a provided challenge.  A value of FALSE indicates that
         the device will not check the appended Luhn check digit in the
         challenge.

      'Min':  This attribute defines the minimum size of the challenge
         accepted by the device for CR mode and MUST be included.  If
         the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
         'ALPHANUMERIC', this value indicates the minimum number of
         digits/characters.  If the 'Encoding' attribute is set to
         'BASE64' or 'BINARY', this value indicates the minimum number
         of bytes of the unencoded value.

      'Max':  This attribute defines the maximum size of the challenge
         accepted by the device for CR mode and MUST be included.  If
         the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
         'ALPHANUMERIC', this value indicates the maximum number of
         digits/characters.  If the 'Encoding' attribute is set to
         'BASE64' or 'BINARY', this value indicates the maximum number
         of bytes of the unencoded value.

Top      ToC       Page 17 
   <ResponseFormat>:

      The <ResponseFormat> element defines the characteristics of the
      result of a computation and defines the format of the OTP or the
      response to a challenge.  For cases in which the key is a PIN
      value, this element contains the format of the PIN itself (e.g.,
      DECIMAL, length 4 for a 4-digit PIN).  The following attributes
      are defined:

      'Encoding':  This attribute defines the encoding of the response
         generated by the device, it MUST be included and MUST be one of
         the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,
         BASE64, or BINARY.

      'CheckDigit':  This attribute indicates whether the device needs
         to append a Luhn check digit, as defined in [ISOIEC7812], to
         the response.  This is only valid if the 'Encoding' attribute
         is set to 'DECIMAL'.  If the value is TRUE, then the device
         will append a Luhn check digit to the response.  If the value
         is FALSE, then the device will not append a Luhn check digit to
         the response.

      'Length':  This attribute defines the length of the response
         generated by the device and MUST be included.  If the
         'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
         ALPHANUMERIC, this value indicates the number of digits/
         characters.  If the 'Encoding' attribute is set to 'BASE64' or
         'BINARY', this value indicates the number of bytes of the
         unencoded value.

4.4.  Transmission of Key Derivation Values

   <KeyProfileId> element, which is a child element of the <Key>
   element, carries a unique identifier used between the sending and
   receiving parties to establish a set of key attribute values that are
   not transmitted within the container but are agreed upon between the
   two parties out of band.  This element will then represent the unique
   reference to a set of key attribute values.  (For example, a smart
   card application personalization profile id related to specific
   attribute values present on a smart card application that have
   influence when computing a response).

   For example, in the case of MasterCard's Chip Authentication Program
   [CAP], the sending and the receiving party would agree that
   KeyProfileId='1' represents a certain set of values (e.g., Internet
   Authentication Flag (IAF) set to a specific value).  During
   transmission of the <KeyContainer>, these values would not be
   transmitted as key attributes but would only be referred to via the

Top      ToC       Page 18 
   <KeyProfileId> element set to the specific agreed-upon profile (in
   this case '1').  The receiving party can then associate all relevant
   key attributes contained in the profile that was agreed upon out of
   band with the imported keys.  Often, this methodology is used between
   a manufacturing service, run by company A, and the validation
   service, run by company B, to avoid repeated transmission of the same
   set of key attribute values.

   The <KeyReference> element contains a reference to an external key to
   be used with a key derivation scheme.  In this case, the parent <Key>
   element will not contain the <Secret> subelement of <Data>, in which
   the key value (secret) is transported; only the reference to the
   external master key is transported (e.g., a PKCS #11 key label).

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer Version="1.0" Id="exampleID1"
        xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
       <KeyPackage>
           <DeviceInfo>
               <Manufacturer>Manufacturer</Manufacturer>
               <SerialNo>987654321</SerialNo>
           </DeviceInfo>
           <CryptoModuleInfo>
               <Id>CM_ID_001</Id>
           </CryptoModuleInfo>
           <Key Id="12345678"
            Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
               <Issuer>Issuer</Issuer>
               <AlgorithmParameters>
                   <ResponseFormat Length="8" Encoding="DECIMAL"/>
               </AlgorithmParameters>
               <KeyProfileId>keyProfile1</KeyProfileId>
               <KeyReference>MasterKeyLabel
               </KeyReference>
               <Data>
                   <Counter>
                       <PlainValue>0</PlainValue>
                   </Counter>
               </Data>
               <Policy>
                   <KeyUsage>OTP</KeyUsage>
               </Policy>
           </Key>
       </KeyPackage>
   </KeyContainer>

   Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key
                             Derivation Values

Top      ToC       Page 19 
   The key value will be derived using the value of the <SerialNo>
   element, values agreed upon between the sending and the receiving
   parties and identified by the <KeyProfile> 'keyProfile1', and an
   externally agreed-upon key referenced by the label 'MasterKeyLabel'.



(page 19 continued on part 2)

Next RFC Part