Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6030

Portable Symmetric Key Container (PSKC)

Pages: 58
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC6030 - 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.
Top   ToC   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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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   RFC6030 - 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 Section