keyprov P. Hoyer
Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei
Expires: January 15, 2009 VeriSign
S. Machani
Diversinet
July 14, 2008
Portable Symmetric Key Container
draft-ietf-keyprov-portable-symmetric-key-container-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Hoyer, et al. Expires January 15, 2009 [Page 1]
Internet-Draft Portable Symmetric Key Container July 2008
Abstract
This document specifies a symmetric key format for transport and
provisioning of symmetric keys (for example One Time Password (OTP)
shared secrets or symmetric cryptographic keys) to different types of
crypto modules such as a strong authentication device. The standard
key transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.
This work is a joint effort by the members of OATH (Initiative for
Open AuTHentication) to specify a format that can be freely
distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations.
Hoyer, et al. Expires January 15, 2009 [Page 2]
Internet-Draft Portable Symmetric Key Container July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Transport of keys from Server to Cryptomodule . . . . 8
3.1.2. Transport of keys from Cryptomodule to Cryptomodule . 8
3.1.3. Transport of keys from Cryptomodule to Server . . . . 9
3.1.4. Server to server Bulk import/export of keys . . . . . 9
3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Server to server Bulk import/export of keys . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Portable Key container definition . . . . . . . . . . . . . . 13
5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. KeyData . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 29
5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 29
6. Usage and profile of algorithms for the portable symmetric
key container . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Usage of EncryptionKey to protect keys in transit . . . . 33
6.1.1. Protecting keys using a pre-shared key via
symmetric algorithms . . . . . . . . . . . . . . . . . 33
6.1.2. Protecting keys using passphrase based encryption
keys . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Protecting keys using asymmetric algorithms . . . . . . . 36
6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 37
6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 38
6.3.2. PIN key value compare algorithm identifier . . . . . . 38
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
8.1. Content-type registration for 'application/pskc+xml' . . . 46
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . . . . 47
8.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 48
8.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 48
8.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 49
8.4.3. Registration Procedures . . . . . . . . . . . . . . . 50
8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
Hoyer, et al. Expires January 15, 2009 [Page 3]
Internet-Draft Portable Symmetric Key Container July 2008
9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 57
9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 58
9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 58
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
11. Appendix A - Example Symmetric Key Containers . . . . . . . . 60
11.1. Symmetric Key Container with a single Non-Encrypted
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 60
11.2. Symmetric Key Container with a single PIN protected
Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 60
11.3. Symmetric Key Container with a single AES-256-CBC
Encrypted HOTP Secret Key and non-encrypted counter
value . . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.4. Symmetric Key Container with signature and a single
Password-based Encrypted HOTP Secret Key . . . . . . . . . 63
11.5. Symmetric Key Container with a single RSA 1.5
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 65
11.6. Symmetric Key Container with a single AES-256-CBC
Encrypted OCRA Secret Key and non-encrypted counter
value . . . . . . . . . . . . . . . . . . . . . . . . . . 66
11.7. Symmetric Key Container with a single AES-256-CBC
Encrypted TOTP Secret Key and non-encrypted time values . 68
11.8. Symmetric Key Container with two devices containing a
Non-Encrypted HOTP Secret Key each sharing common
KeyProperties . . . . . . . . . . . . . . . . . . . . . . 69
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
12.1. Normative References . . . . . . . . . . . . . . . . . . . 71
12.2. Informative References . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
Intellectual Property and Copyright Statements . . . . . . . . . . 74
Hoyer, et al. Expires January 15, 2009 [Page 4]
Internet-Draft Portable Symmetric Key Container July 2008
1. Introduction
With increasing use of symmetric key based authentication systems
such as systems based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric
keys from one system to another. Traditionally authentication server
vendors and service providers have used proprietary formats for
importing, exporting and provisioning these keys into their systems
making it hard to use tokens from vendor A with a server from vendor
B.
This Internet draft describes a standard format for serializing
symmetric keys such as OTP shared secrets for system import, export
or network/protocol transport. The goal is that the format will
facilitate dynamic provisioning and transfer of symmetric keys such
as OTP shared secrets or encryption keys of different types. In the
case of OTP shared secrets, the format will facilitate dynamic
provisioning using an online provisioning protocol to different
flavors of embedded tokens or allow customers to import new or
existing tokens in batch or single instances into a compliant system.
This draft also specifies the key attributes required for computation
such as the initial event counter used in the HOTP algorithm [HOTP].
It is also applicable for other time-based or proprietary algorithms.
To provide an analogy, in public key environments the PKCS#12 format
[PKCS12] is commonly used for importing and exporting private keys
and certificates between systems. In the environments outlined in
this document where OTP keys may be transported directly down to
smartcards or devices with limited computing capabilities, a format
with small (size in bytes) and explicit shared secret configuration
attribute information is desirable, avoiding complexity of PKCS#12.
For example, one would have to use opaque data within PKCS#12 to
carry shared secret attributes used for OTP calculations, whereas a
more explicit attribute schema definition is better for
interoperability and efficiency.
Hoyer, et al. Expires January 15, 2009 [Page 5]
Internet-Draft Portable Symmetric Key Container July 2008
2. Terminology
2.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].
2.2. Definitions
This section defines terms used in this document. The same terms may
be defined differently in other documents.
Authentication Token: A physical device that an authorized user of
computer services is given to aid in authentication. The term may
also refer to software tokens.
Bulk Provisioning: Transferring multiple keys linked to multiple
devices in a single execution step within one single PSKC
KeyContainer
Cryptographic Module: A component of an application, which enables
symmetric key cryptographic functionality
Cryptographic Key: A parameter used in conjunction with a
cryptographic algorithm that determines its operation in such a
way that an entity with knowledge of the key can reproduce or
reverse the operation, while an entity without knowledge of the
key cannot (see [NIST-SP800-57])
Cryptographic Token: See Authentication Token
Device: A physical piece of hardware, or a software framework, that
hosts symmetric keys
DeviceInfo: A set of elements whose values combined uniquely
identify a device e.g. Manufacture 'Manufacturer and Serialnumber
'12345678'
Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a
key container available to a recipient
Encryption Key: A key used to encrypt key
Key: See Cryptographic Key
Hoyer, et al. Expires January 15, 2009 [Page 6]
Internet-Draft Portable Symmetric Key Container July 2008
Hardware Token: See Authentication Token
Key Algorithm: A well-defined computational procedure that takes
variable inputs including a cryptographic key and produces an
output.
Key Container: An object that encapsulates symmetric keys and their
attributes for set of devices
Key ID (KeyID): A unique identifier for the symmetric key
Key Issuer: An organization that issues symmetric keys to end-users
Key Type: The type of symmetric key cryptographic methods for which
the key will be used (e.g., OATH HOTP or RSA SecurID
authentication, AES encryption, etc.)
Secret Key: The symmetric key data
Software Token: A type of authentication token that is stored on a
general-purpose electronic device such as a desktop computer,
laptop, PDA, or mobile phone
Token: See Authentication Token
User: The person or client to whom devices are issued
User ID: A unique identifier for the user or client
Hoyer, et al. Expires January 15, 2009 [Page 7]
Internet-Draft Portable Symmetric Key Container July 2008
3. Use Cases
This section describes a comprehensive list of use cases that
inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design.
These requirements are covered in the next section.
These use cases also help in understanding the applicability of this
specification to real world situations.
3.1. Online Use Cases
This section describes the use cases related to provisioning the keys
using an online provisioning protocol such as [DSKPP]
3.1.1. Transport of keys from Server to Cryptomodule
For example, a mobile device user wants to obtain a symmetric key for
use with a cryptomodule on the device. The cryptomodule client from
vendor A initiates the provisioning process against a provisioning
system from vendor B using a standards-based provisioning protocol
such as [DSKPP]. The provisioning entity delivers one or more keys
in a standard format that can be processed by the mobile device.
For example, in a variation of the above, instead of the user's
mobile phone, a key is provisioned in the user's soft token
application on a laptop using a network-based online protocol. As
before, the provisioning system delivers a key in a standard format
that can be processed by the soft token on the PC.
For example, the end-user or the key issuer wants to update or
configure an existing key in the cryptomodule and requests a
replacement key container. The container may or may not include a
new key and may include new or updated key attributes such as a new
counter value in HOTP key case, a modified response format or length,
a new friendly name, etc.
3.1.2. Transport of keys from Cryptomodule to Cryptomodule
For example, a user wants to transport a key from one cryptomodule to
another. There may be two cryptographic modules, one on a computer
one on a mobile phone, and the user wants to transport a key from the
computer to the mobile phone. The user can export the key and
related data in a standard format for input into the other
cryptomodule.
Hoyer, et al. Expires January 15, 2009 [Page 8]
Internet-Draft Portable Symmetric Key Container July 2008
3.1.3. Transport of keys from Cryptomodule to Server
For example, a user wants to activate and use a new key and related
data against a validation system that is not aware of this key. This
key may be embedded in the cryptomodule (e.g. SD card, USB drive)
that the user has purchased at the local electronics retailer. Along
with the cryptomodule, the user may get the key on a CD or a floppy
in a standard format. The user can now upload via a secure online
channel or import this key and related data into the new validation
system and start using the key.
3.1.4. Server to server Bulk import/export of keys
From time to time, a key management system may be required to import
or export keys in bulk from one entity to another.
For example, instead of importing keys from a manufacturer using a
file, a validation server may download the keys using an online
protocol. The keys can be downloaded in a standard format that can
be processed by a validation system.
For example, in a variation of the above, an OTA key provisioning
gateway that provisions keys to mobile phones may obtain key material
from a key issuer using an online protocol. The keys are delivered
in a standard format that can be processed by the key provisioning
gateway and subsequently sent to the end-user's mobile phone.
3.2. Offline Use Cases
This section describes the use cases relating to offline transport of
keys from one system to another, using some form of export and import
model.
3.2.1. Server to server Bulk import/export of keys
For example, cryptomodules such as OTP authentication tokens, may
have their symmetric keys initialized during the manufacturing
process in bulk, requiring copies of the keys and algorithm data to
be loaded into the authentication system through a file on portable
media. The manufacturer provides the keys and related data in the
form of a file containing records in standard format, typically on a
CD. Note that the token manufacturer and the vendor for the
validation system may be the same or different. Some crypto modules
will allow local PIN management (the device will have a PIN pad)
hence random initial PINs set at manufacturing should be transmitted
together with the respective keys they protect.
For example, an enterprise wants to port keys and related data from
Hoyer, et al. Expires January 15, 2009 [Page 9]
Internet-Draft Portable Symmetric Key Container July 2008
an existing validation system A into a different validation system B.
The existing validation system provides the enterprise with a
functionality that enables export of keys and related data (e.g. for
OTP authentication tokens) in a standard format. Since the OTP
tokens are in the standard format, the enterprise can import the
token records into the new validation system B and start using the
existing tokens. Note that the vendors for the two validation
systems may be the same or different.
Hoyer, et al. Expires January 15, 2009 [Page 10]
Internet-Draft Portable Symmetric Key Container July 2008
4. Requirements
This section outlines the most relevant requirements that are the
basis of this work. Several of the requirements were derived from
use cases described above.
R1: The format MUST support transport of multiple types of
symmetric keys and related attributes for algorithms including
HOTP, other OTP, challenge-response, etc.
R2: The format MUST handle the symmetric key itself as well of
attributes that are typically associated with symmetric keys.
Some of these attributes may be
* Unique Key Identifier
* Issuer information
* Algorithm ID
* Algorithm mode
* Issuer Name
* Key friendly name
* Event counter value (moving factor for OTP algorithms)
* Time value
R3: The format SHOULD support both offline and online scenarios.
That is it should be serializable to a file as well as it
should be possible to use this format in online provisioning
protocols such as [DSKPP]
R4: The format SHOULD allow bulk representation of symmetric keys
R5: The format SHOULD allow bulk representation of PINs related to
specific keys
R6: The format SHOULD be portable to various platforms.
Furthermore, it SHOULD be computationally efficient to process.
R7: The format MUST provide appropriate level of security in terms
of data encryption and data integrity.
Hoyer, et al. Expires January 15, 2009 [Page 11]
Internet-Draft Portable Symmetric Key Container July 2008
R8: For online scenarios the format SHOULD NOT rely on transport
level security (e.g., SSL/TLS) for core security requirements.
R9: The format SHOULD be extensible. It SHOULD enable extension
points allowing vendors to specify additional attributes in the
future.
R10: The format SHOULD allow for distribution of key derivation data
without the actual symmetric key itself. This is to support
symmetric key management schemes that rely on key derivation
algorithms based on a pre-placed master key. The key
derivation data typically consists of a reference to the key,
rather than the key value itself.
R11: The format SHOULD allow for additional lifecycle management
operations such as counter resynchronization. Such processes
require confidentiality between client and server, thus could
use a common secure container format, without the transfer of
key material.
R12: The format MUST support the use of pre-shared symmetric keys to
ensure confidentiality of sensitive data elements.
R13: The format MUST support a password-based encryption (PBE)
[PKCS5] scheme to ensure security of sensitive data elements.
This is a widely used method for various provisioning
scenarios.
R14: The format SHOULD support asymmetric encryption algorithms such
as RSA to ensure end-to-end security of sensitive data
elements. This is to support scenarios where a pre-set shared
encryption key is difficult to use.
Hoyer, et al. Expires January 15, 2009 [Page 12]
Internet-Draft Portable Symmetric Key Container July 2008
5. Portable Key container definition
The portable key container is based on an XML schema definition and
contains the following main entities:
1. KeyContainer entity as defined in Section 5.1
2. KeyProperties entity as defined in Section 5.2
3. Device entity as defined in Section 5.3
4. Key entity as defined in Section 5.4
Additionally other XML schema types have been defined and are
detailed in the relevant subsections of this document
A KeyContainer MAY contain one or more Device entities. A Device MAY
contain one or more Key entities
The figure below indicates a possible relationship diagram of a
container.
--------------------------------------------
| KeyContainer |
| |
| -------------------- |
| | Keyproperties 1 | |
| | | |
| -------------------- |
| ------------------ ----------------- |
| | Device 1 | | Device n | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key 1 | | | | Key n | | |
| | ------------ | | ------------ | |
| | | | | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key m | | | | Key p | | |
| | ------------ | | ------------ | |
| ------------------ ----------------- |
| |
--------------------------------------------
The following sections describe in detail all the entities and
related XML schema elements and attributes:
Hoyer, et al. Expires January 15, 2009 [Page 13]
Internet-Draft Portable Symmetric Key Container July 2008
5.1. KeyContainer
The KeyContainer represents the key container entity. A Container
MAY contain more than one Device entity; each Device entity MAY
contain more than one Key entity.
The KeyContainer is defined as follows:
The attributes of the KeyContainer have the following meanings:
o Version (MANDATORY), the version number for the portable key
container format (the XML schema defined in this document).
o ID (OPTIONAL), the unique ID for this container in case an XML
document contains more than one container and wants to refer to
them uniquely.
The elements of the KeyContainer have the following meanings:
o (OPTIONAL), Identifies the encryption key,
algorithm and possible parameters used to protect the Secret Key
data in the container. Please see Section 6.1 for detailed
description of how to protect key data in transit and the usage of
Hoyer, et al. Expires January 15, 2009 [Page 14]
Internet-Draft Portable Symmetric Key Container July 2008
this element.
o (OPTIONAL), Identifies the algorithm used to
generate a keyed digest of the Secret Key data values when
protection algorithms are used that do not have integrity checks.
The digest guarantees the integrity and the authenticity of the
key data. for profile and usage please see Section 6.1.1
o (OPTIONAL), key property entities containing key
related properties that are common for keys within this container.
Please see Section 5.2 for detailed description of this
element.The KeyContainer MAY contain multiple KeyProperties
elements each containing a set of properties related to one or
more keys transported within the container.
o (MANDATORY), the host Device for one or more Keys as
defined in Section 5.3 The KeyContainer MAY contain multiple
Device data elements, allowing for bulk provisioning of multiple
devices each containing multiple keys.
o (OPTIONAL), the signature value of the Container.
When the signature is applied to the entire container, it MUST use
XML Signature methods as defined in [XMLDSIG]. It MAY be omitted
when application layer provisioning or transport layer
provisioning protocols provide the integrity and authenticity of
the payload between the sender and the recipient of the container.
When required, this specification recommends using a symmetric key
based signature with the same key used in the encryption of the
secret key data. The signature is enveloped.
o (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
blahblahblah
Hoyer, et al. Expires January 15, 2009 [Page 15]
Internet-Draft Portable Symmetric Key Container July 2008
5.2. KeyProperties
The KeyProperties represents common properties shared by more than
one key held in the container. If a value is set in the properties
the Key element can refer to it via ID attribute. Values that are
present in the Key element itself MUST take precedence over values
set in KeyProperties. The KeyProperties is defined as follows:
The attributes of the KeyProperties entity have the following
meanings:
o ID (MANDATORY), a unique and global identifier of set of
KeyProperties. The identifier is defined as a string of
alphanumeric characters.
o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
to use with a secret key for the profiles described in Section 6.3
Since KeyProperties are a method to group element values that are
Hoyer, et al. Expires January 15, 2009 [Page 16]
Internet-Draft Portable Symmetric Key Container July 2008
common to multiple keys transported, please refer to Section 5.4 for
detailed description of all elements.
5.3. Device
The Device represents an extensible Device entity in the Container.
A Device MAY be bound to a user and MAY contain more than one key. A
key SHOULD be bound to only one Device.
The Device is defined as follows:
The elements of the Device have the following meanings:
o (OPTIONAL), a set of elements containing information
about the device, whose values uniquely identify the device,
defined in Section 5.3.1
o (MANDATORY), represents the key entity as defined in
Section 5.4
o (OPTIONAL), identifies the owner or the user of the Device,
a string representation of a Distinguished Name as defined in
[RFC4514]. For example UID=jsmith,DC=example,DC=net. In systems
where unique user Ids are used the string representation
'UID=[uniqueId]' SHOULD be used.
o (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
Hoyer, et al. Expires January 15, 2009 [Page 17]
Internet-Draft Portable Symmetric Key Container July 2008
blahblahblah
5.3.1. DeviceInfo
The DeviceInfo represents an extensible set of elements that form the
identifying criteria to uniquely identify the device that contains
the associated keys. Since devices can come in different form
factors such as hardware tokens, smart-cards, soft tokens in a mobile
phone or PC etc this element allows different criteria to be used.
Combined though the criteria MUST uniquely identify the device. For
example for hardware tokens the combination of SerialNo and
Manufacturer will uniquely identify a device but not SerialNo alone
since two different token manufacturers might issue devices with the
same serial number (similar to the IssuerDN and serial number of a
certificate). Symmetric Keys used in the payment industry are
usually stored on Integrated Circuit Smart Cards. These cards are
uniquely identified via the Primary Account Number (PAN, the long
number printed on the front of the card) and an expiry date of the
card. DeviceInfo is an extensible type that allows all these
different ways to uniquely identify a specific key containing device.
The DeviceInfo is defined as follows:
The elements of DeviceInfo have the following meanings:
o (MANDATORY), the manufacturer of the device.
Hoyer, et al. Expires January 15, 2009 [Page 18]
Internet-Draft Portable Symmetric Key Container July 2008
o (MANDATORY), the serial number of the device or the PAN
(primary account number) in case of payment smart cards.
o (OPTIONAL), the model of the device (e.g. one-button-HOTP-
token-V1)
o (OPTIONAL), the issue number in case of smart cards with
the same PAN, equivalent to a PSN (PAN Sequence Number).
o (OPTIONAL), the identifier that can be used to
bind keys to the device or class of device. When loading keys
into a device, this identifier can be checked against information
obtained from the device to ensure that the correct device or
class of device is being used.
o (OPTIONAL), the start date of a device (such as the
one on a payment card, used when issue numbers are not printed on
cards). MUST be expressed in UTC form, with no time zone
component. Implementations SHOULD NOT rely on time resolution
finer than milliseconds and MUST NOT generate time instants that
specify leap seconds.
o (OPTIONAL), the expiry date of a device (such as the
one on a payment card, used when issue numbers are not printed on
cards). MUST be expressed in UTC form, with no time zone
component. Implementations SHOULD NOT rely on time resolution
finer than milliseconds and MUST NOT generate time instants that
specify leap seconds.
o (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
blahblahblah
5.4. Key
The Key represents the key entity in the KeyContainer. The Key is
defined as follows:
Hoyer, et al. Expires January 15, 2009 [Page 19]
Internet-Draft Portable Symmetric Key Container July 2008
The attributes of the Key entity have the following meanings:
o KeyId (MANDATORY), a unique and global identifier of the symmetric
key. The identifier is defined as a string of alphanumeric
characters. This identifier SHOULD be valid globally and outside
of the instance document of the container.
o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
to use with the secret key, for profiles are described in
Section 6.3
o KeyProperties (OPTIONAL), the references to the unique id of the
KeyProperties whose value the instance of this key inherits. If
Hoyer, et al. Expires January 15, 2009 [Page 20]
Internet-Draft Portable Symmetric Key Container July 2008
this value is set implementation MUST lookup the Keyproperties
element referred to by this unique Id and this instance of key
will inherit all values from the KeyProperties. Values held in
the key instance MUST take precedence over values inherited from
KeyProperties."/>
The elements of the Key entity have the following meanings:
o (OPTIONAL), The key issuer name, this is normally the
name of the organization that issues the key to the end user of
the key. For example MyBank issuing hardware tokens to their
retail banking users 'MyBank' would be the issuer. The Issuer is
defined as a String.
o (OPTIONAL), defines the intended usage of the key and
related metadata as defined in Section 5.4.2
o (OPTIONAL), A unique identifier used between the
sending and receiving party of the container to establish a set of
constant values related to a key that are not transmitted via the
container. For example a smart card application personalisation
profile id related to attributes present on a smart card
application that have influence when computing a response. An
example could be an EMV MasterCard CAP [CAP] application on a card
personalised with data for a specific batch of cards such as:
IAF Internet authentication flag
CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
VISA 13, VISA14)
AIP (Application Interchange Profile), 2 bytes
TVR Terminal Verification Result, 5 bytes
CVR The card verification result
AmountOther
TransactionDate
TerminalCountryCode
TransactionCurrencyCode
Hoyer, et al. Expires January 15, 2009 [Page 21]
Internet-Draft Portable Symmetric Key Container July 2008
AmountAuthorised
IIPB
These values are not contained within attributes in the container
but are shared between the manufacturing and the validation
service through this unique KeyProfileId. The KeyProfileId is
defined as a String.
o (OPTIONAL), The unique reference to an external
master key when key derivation schemes are used and no specific
key is transported but only the reference to the master key used
to derive a specific key and some derivation data (e.g. the
PKCS#11 key label in an HSM).
o (OPTIONAL), The user friendly name that is assigned
to the secret key for easy reference. The FriendlyName is defined
as a String.
o (OPTIONAL), the element carrying the data related to the
key as defined in Section 5.4.1
o (OPTIONAL), the policy of the PIN relating to the
usage of this key as defined in Section 5.4.4
o (OPTIONAL), the start date of the key, it MUST not be
possible to use this key before this date. MUST be expressed in
UTC form, with no time zone component. Implementations SHOULD NOT
rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds.
o (OPTIONAL), the expiry date of the key, it MUST not
be possible to use this key after this date. MUST be expressed in
UTC form, with no time zone component. Implementations SHOULD NOT
rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds.
o (OPTIONAL), identifies the user account (e.g. username or
user id) to which the key is assigned. The value MAY be a string
representation of a Distinguished Name as defined in [RFC4514].
For example "UID=jsmith,DC=example,DC=net". In systems where
unique user Ids are used the string representation
'UID=[uniqueId]' SHOULD be used.
o (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
Hoyer, et al. Expires January 15, 2009 [Page 22]
Internet-Draft Portable Symmetric Key Container July 2008
extension. In this way groups of extension can be bundled under a
subelement. For example:
blahblahblah
5.4.1. KeyData
Defines an extensible set of data elements relating to a key
including the key value itself (secret). After considerable
discussions in forums and at IETF the authors needed a mean to convey
data related to a key in an extensible form. The requirements were
that the data elements could be encrypted but not via XML encryption
which was deemed to complex because of canonicalization. Hence
earlier drafts made use of a list of name value pairs. This was not
considered to be very XML like and also lacked inbuilt support for
typing. Hence the current apporach is to have within KeyData a set
of elements that have both typing and can be encrypted.
All elements within Data hence obey a simple structure in that they
MUST have:
a choice between:
A element that is typed to the specific type (e.g.
xs:integer)
An element that is of type xenc:EncryptedDataType
where the value of the specific element is placed in case it is
encrypted
an optional element that is populated with a MAC in case
the encryption algorithm does not support integrity checks
For example the pskc:intDataType is defined as follows:
Hoyer, et al. Expires January 15, 2009 [Page 23]
Internet-Draft Portable Symmetric Key Container July 2008
The following typed base types have been defined within the current
schema of the PSKC spec with the naming convention DataType
(e.g. intDataType) to be able to cater transmission of key data
elements:
pskc:intDataType - to carry data elements of type integer,
PlainValue sub element is of type xs:integer. When encrypted the
binary value MUST be 4 bytes unsigned integer in big endian (i.e.
network byte order) form
pskc:longDataType - to carry data elements of type long,
PlainValue sub element is of type xs:long. When encrypted the
binary value MUST be 8 bytes unsigned integer in big endian (i.e.
network byte order) form
pskc:binaryDataType - to carry data elements of type binary,
PlainValue sub element is of type xs:Base64Binary
pskc:stringDataType - to carry data elements of type string,
PlainValue sub element is of type xs:string. When encrypted the
binary value MUST UTF-8 encoded string in binary form
Therefore the KeyData element is defined as follows and contains sub
ements to convey the values required by algorithms considered during
the definition of this specification:
Hoyer, et al. Expires January 15, 2009 [Page 24]
Internet-Draft Portable Symmetric Key Container July 2008
The elements of the Data element have the following meanings:
o (OPTIONAL), the value of the key itself in binary.
o (OPTIONAL), the event counter for event based OTP
algorithms.
o