RFC 6030
Portable Symmetric Key Container (PSKC)
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.
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
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
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.
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:
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.
----------------- | 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.
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:
'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.
<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
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).
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.
<?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 Data4.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).
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.
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.
<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.
<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
<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
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)
