draft-ietf-keyprov-portable-symmetric-key-container-05.txt   draft-ietf-keyprov-portable-symmetric-key-container-06.txt 
keyprov P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: January 15, 2009 VeriSign Expires: May 7, 2009 VeriSign
S. Machani S. Machani
Diversinet Diversinet
July 14, 2008 November 03, 2008
Portable Symmetric Key Container Portable Symmetric Key Container
draft-ietf-keyprov-portable-symmetric-key-container-05.txt draft-ietf-keyprov-portable-symmetric-key-container-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on May 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies a symmetric key format for transport and This document specifies a symmetric key format for transport and
provisioning of symmetric keys (for example One Time Password (OTP) provisioning of symmetric keys (for example One Time Password (OTP)
shared secrets or symmetric cryptographic keys) to different types of shared secrets or symmetric cryptographic keys) to different types of
crypto modules such as a strong authentication device. The standard crypto modules such as a strong authentication device. The standard
key transport format enables enterprises to deploy best-of-breed key transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same solutions combining components from different vendors into the same
infrastructure. infrastructure.
This work is a joint effort by the members of OATH (Initiative for This work is based on earlier work by the members of OATH (Initiative
Open AuTHentication) to specify a format that can be freely for Open AuTHentication) to specify a format that can be freely
distributed to the technical community. The authors believe that a distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two- common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations. between commercial and open-source implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8 3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Transport of keys from Server to Cryptomodule . . . . 8 3.1.1. Transport of keys from Server to Cryptographic
3.1.2. Transport of keys from Cryptomodule to Cryptomodule . 8 Module . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Transport of keys from Cryptomodule to Server . . . . 9 3.1.2. Transport of keys from Cryptographic Module to
Cryptographic Module . . . . . . . . . . . . . . . . . 8
3.1.3. Transport of keys from Cryptographic Module to
Server . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Server to server Bulk import/export of keys . . . . . 9 3.1.4. Server to server Bulk import/export of keys . . . . . 9
3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9 3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Server to server Bulk import/export of keys . . . . . 9 3.2.1. Server to server Bulk import/export of keys . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Portable Key container definition . . . . . . . . . . . . . . 13 5. Portable Key container definition . . . . . . . . . . . . . . 13
5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16 5.2. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18 5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. KeyData . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.1. KeyData . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 29 5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 29
5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 29 5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 29
6. Usage and profile of algorithms for the portable symmetric 6. Usage and profile of algorithms for the portable symmetric
key container . . . . . . . . . . . . . . . . . . . . . . . . 33 key container . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Usage of EncryptionKey to protect keys in transit . . . . 33 6.1. Usage of EncryptionKey to protect keys in transit . . . . 33
6.1.1. Protecting keys using a pre-shared key via 6.1.1. Protecting keys using a pre-shared key via
symmetric algorithms . . . . . . . . . . . . . . . . . 33 symmetric algorithms . . . . . . . . . . . . . . . . . 33
6.1.2. Protecting keys using passphrase based encryption 6.1.2. Protecting keys using passphrase based key
keys . . . . . . . . . . . . . . . . . . . . . . . . . 34 encryption keys . . . . . . . . . . . . . . . . . . . 35
6.2. Protecting keys using asymmetric algorithms . . . . . . . 36 6.2. Protecting keys using asymmetric algorithms . . . . . . . 38
6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 37 6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 39
6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 38 6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 40
6.3.2. PIN key value compare algorithm identifier . . . . . . 38 6.3.2. PIN key value compare algorithm identifier . . . . . . 40
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8.1. Content-type registration for 'application/pskc+xml' . . . 46 8.1. Content-type registration for 'application/pskc+xml' . . . 48
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 49
8.3. URN Sub-Namespace Registration for 8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . . . . 47 urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . . . . 49
8.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 48 8.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 50
8.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 48 8.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 50
8.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 49 8.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 51
8.4.3. Registration Procedures . . . . . . . . . . . . . . . 50 8.4.3. Registration Procedures . . . . . . . . . . . . . . . 52
8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 52 8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 76
9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 57 9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 76
9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 58 9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 77
9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 58 9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 77
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
11. Appendix A - Example Symmetric Key Containers . . . . . . . . 60 11. Appendix A - Example Symmetric Key Containers . . . . . . . . 79
11.1. Symmetric Key Container with a single Non-Encrypted 11.1. Symmetric Key Container with a single Non-Encrypted
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 60 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 79
11.2. Symmetric Key Container with a single PIN protected 11.2. Symmetric Key Container with a single PIN protected
Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 60 Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 80
11.3. Symmetric Key Container with a single AES-256-CBC 11.3. Symmetric Key Container with a single AES-128-CBC
Encrypted HOTP Secret Key and non-encrypted counter Encrypted HOTP Secret Key and non-encrypted counter
value . . . . . . . . . . . . . . . . . . . . . . . . . . 62 value . . . . . . . . . . . . . . . . . . . . . . . . . . 82
11.4. Symmetric Key Container with signature and a single 11.4. Symmetric Key Container with signature and a single
Password-based Encrypted HOTP Secret Key . . . . . . . . . 63 Password-based Encrypted HOTP Secret Key . . . . . . . . . 83
11.5. Symmetric Key Container with a single RSA 1.5 11.5. Symmetric Key Container with a single RSA 1.5
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 65 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 85
11.6. Symmetric Key Container with a single AES-256-CBC 11.6. Symmetric Key Container with a single AES-128-CBC
Encrypted OCRA Secret Key and non-encrypted counter Encrypted OCRA Secret Key and non-encrypted counter
value . . . . . . . . . . . . . . . . . . . . . . . . . . 66 value . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.7. Symmetric Key Container with a single AES-256-CBC 11.7. Symmetric Key Container with a single AES-256-CBC
Encrypted TOTP Secret Key and non-encrypted time values . 68 Encrypted TOTP Secret Key and non-encrypted time values . 88
11.8. Symmetric Key Container with two devices containing a 11.8. Symmetric Key Container with two devices containing a
Non-Encrypted HOTP Secret Key each sharing common Non-Encrypted HOTP Secret Key each sharing common
KeyProperties . . . . . . . . . . . . . . . . . . . . . . 69 KeyProperties . . . . . . . . . . . . . . . . . . . . . . 90
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
12.1. Normative References . . . . . . . . . . . . . . . . . . . 71 12.1. Normative References . . . . . . . . . . . . . . . . . . . 92
12.2. Informative References . . . . . . . . . . . . . . . . . . 71 12.2. Informative References . . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
Intellectual Property and Copyright Statements . . . . . . . . . . 74 Intellectual Property and Copyright Statements . . . . . . . . . . 95
1. Introduction 1. Introduction
With increasing use of symmetric key based authentication systems With increasing use of symmetric key based authentication systems
such as systems based one time password (OTP) and challenge response such as systems based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric standard format for importing, exporting or provisioning symmetric
keys from one system to another. Traditionally authentication server keys from one system to another. Traditionally authentication server
vendors and service providers have used proprietary formats for vendors and service providers have used proprietary formats for
importing, exporting and provisioning these keys into their systems importing, exporting and provisioning these keys into their systems
making it hard to use tokens from vendor A with a server from vendor making it hard to use tokens from vendor A with a server from vendor
B. B.
This Internet draft describes a standard format for serializing This document describes a standard format for serializing symmetric
symmetric keys such as OTP shared secrets for system import, export keys such as OTP shared secrets for system import, export or network/
or network/protocol transport. The goal is that the format will protocol transport. The goal is that the format will facilitate
facilitate dynamic provisioning and transfer of symmetric keys such dynamic provisioning and transfer of symmetric keys such as OTP
as OTP shared secrets or encryption keys of different types. In the shared secrets or encryption keys of different types. In the case of
case of OTP shared secrets, the format will facilitate dynamic OTP shared secrets, the format will facilitate dynamic provisioning
provisioning using an online provisioning protocol to different using an online provisioning protocol to different flavors of
flavors of embedded tokens or allow customers to import new or embedded tokens or allow customers to import new or existing tokens
existing tokens in batch or single instances into a compliant system. in batch or single instances into a compliant system.
This draft also specifies the key attributes required for computation This draft also specifies the key attributes required for computation
such as the initial event counter used in the HOTP algorithm [HOTP]. such as the initial event counter used in the HOTP algorithm [HOTP].
It is also applicable for other time-based or proprietary algorithms. It is also applicable for other time-based or proprietary algorithms.
To provide an analogy, in public key environments the PKCS#12 format To provide an analogy, in public key environments the PKCS#12 format
[PKCS12] is commonly used for importing and exporting private keys [PKCS12] is commonly used for importing and exporting private keys
and certificates between systems. In the environments outlined in and certificates between systems. In the environments outlined in
this document where OTP keys may be transported directly down to this document where OTP keys may be transported directly down to
smartcards or devices with limited computing capabilities, a format smartcards or devices with limited computing capabilities and
with small (size in bytes) and explicit shared secret configuration explicit shared secret, configuration attribute information is
attribute information is desirable, avoiding complexity of PKCS#12. desirable. With PKCS#12, one would have to use opaque data to carry
For example, one would have to use opaque data within PKCS#12 to shared secret attributes used for OTP calculations, whereas a more
carry shared secret attributes used for OTP calculations, whereas a explicit attribute schema definition is better for interoperability
more explicit attribute schema definition is better for and efficiency.
interoperability and efficiency.
2. Terminology 2. Terminology
2.1. Key Words 2.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Definitions 2.2. Definitions
skipping to change at page 6, line 41 skipping to change at page 6, line 41
way that an entity with knowledge of the key can reproduce or way that an entity with knowledge of the key can reproduce or
reverse the operation, while an entity without knowledge of the reverse the operation, while an entity without knowledge of the
key cannot (see [NIST-SP800-57]) key cannot (see [NIST-SP800-57])
Cryptographic Token: See Authentication Token Cryptographic Token: See Authentication Token
Device: A physical piece of hardware, or a software framework, that Device: A physical piece of hardware, or a software framework, that
hosts symmetric keys hosts symmetric keys
DeviceInfo: A set of elements whose values combined uniquely DeviceInfo: A set of elements whose values combined uniquely
identify a device e.g. Manufacture 'Manufacturer and Serialnumber identify a device e.g. Manufacturer 'TokenVendorAcme' and
'12345678' Serialnumber '12345678'
Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a
key container available to a recipient key container available to a recipient
Encryption Key: A key used to encrypt key Key Encryption Key: A key used to encrypt key
Key: See Cryptographic Key Key: See Cryptographic Key
Hardware Token: See Authentication Token Hardware Token: See Authentication Token
Key Algorithm: A well-defined computational procedure that takes Key Algorithm: A well-defined computational procedure that takes
variable inputs including a cryptographic key and produces an variable inputs including a cryptographic key and produces an
output. output.
Key Container: An object that encapsulates symmetric keys and their Key Container: An object that encapsulates symmetric keys and their
attributes for set of devices attributes for set of devices
skipping to change at page 8, line 20 skipping to change at page 8, line 20
These requirements are covered in the next section. These requirements are covered in the next section.
These use cases also help in understanding the applicability of this These use cases also help in understanding the applicability of this
specification to real world situations. specification to real world situations.
3.1. Online Use Cases 3.1. Online Use Cases
This section describes the use cases related to provisioning the keys This section describes the use cases related to provisioning the keys
using an online provisioning protocol such as [DSKPP] using an online provisioning protocol such as [DSKPP]
3.1.1. Transport of keys from Server to Cryptomodule 3.1.1. Transport of keys from Server to Cryptographic Module
For example, a mobile device user wants to obtain a symmetric key for For example, a mobile device user wants to obtain a symmetric key for
use with a cryptomodule on the device. The cryptomodule client from use with a Cryptographic Module on the device. The Cryptographic
vendor A initiates the provisioning process against a provisioning Module from vendor A initiates the provisioning process against a
system from vendor B using a standards-based provisioning protocol provisioning system from vendor B using a standards-based
such as [DSKPP]. The provisioning entity delivers one or more keys provisioning protocol such as [DSKPP]. The provisioning entity
in a standard format that can be processed by the mobile device. 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 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 mobile phone, a key is provisioned in the user's soft token
application on a laptop using a network-based online protocol. As application on a laptop using a network-based online protocol. As
before, the provisioning system delivers a key in a standard format before, the provisioning system delivers a key in a standard format
that can be processed by the soft token on the PC. that can be processed by the soft token on the PC.
For example, the end-user or the key issuer wants to update or For example, the end-user or the key issuer wants to update or
configure an existing key in the cryptomodule and requests a configure an existing key in the Cryptographic Module and requests a
replacement key container. The container may or may not include 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 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, counter value in HOTP key case, a modified response format or length,
a new friendly name, etc. a new friendly name, etc.
3.1.2. Transport of keys from Cryptomodule to Cryptomodule 3.1.2. Transport of keys from Cryptographic Module to Cryptographic
Module
For example, a user wants to transport a key from one cryptomodule to For example, a user wants to transport a key from one Cryptographic
another. There may be two cryptographic modules, one on a computer Module to another. There may be two cryptographic modules, one on a
one on a mobile phone, and the user wants to transport a key from the computer one on a mobile phone, and the user wants to transport a key
computer to the mobile phone. The user can export the key and from the computer to the mobile phone. The user can export the key
related data in a standard format for input into the other and related data in a standard format for input into the other
cryptomodule. Cryptographic Module.
3.1.3. Transport of keys from Cryptomodule to Server 3.1.3. Transport of keys from Cryptographic Module to Server
For example, a user wants to activate and use a new key and related 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 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) key may be embedded in the Cryptographic Module (e.g. SD card, USB
that the user has purchased at the local electronics retailer. Along drive) that the user has purchased at the local electronics retailer.
with the cryptomodule, the user may get the key on a CD or a floppy Along with the Cryptographic Module, the user may get the key on a CD
in a standard format. The user can now upload via a secure online or a floppy in a standard format. The user can now upload via a
channel or import this key and related data into the new validation secure online channel or import this key and related data into the
system and start using the key. new validation system and start using the key.
3.1.4. Server to server Bulk import/export of keys 3.1.4. Server to server Bulk import/export of keys
From time to time, a key management system may be required to import From time to time, a key management system may be required to import
or export keys in bulk from one entity to another. or export keys in bulk from one entity to another.
For example, instead of importing keys from a manufacturer using a For example, instead of importing keys from a manufacturer using a
file, a validation server may download the keys using an online file, a validation server may download the keys using an online
protocol. The keys can be downloaded in a standard format that can protocol. The keys can be downloaded in a standard format that can
be processed by a validation system. be processed by a validation system.
For example, in a variation of the above, an OTA key provisioning For example, in a variation of the above, an Over-The-Aire (OTA) key
gateway that provisions keys to mobile phones may obtain key material provisioning gateway that provisions keys to mobile phones may obtain
from a key issuer using an online protocol. The keys are delivered key material from a key issuer using an online protocol. The keys
in a standard format that can be processed by the key provisioning are delivered in a standard format that can be processed by the key
gateway and subsequently sent to the end-user's mobile phone. provisioning gateway and subsequently sent to the end-user's mobile
phone.
3.2. Offline Use Cases 3.2. Offline Use Cases
This section describes the use cases relating to offline transport of This section describes the use cases relating to offline transport of
keys from one system to another, using some form of export and import keys from one system to another, using some form of export and import
model. model.
3.2.1. Server to server Bulk import/export of keys 3.2.1. Server to server Bulk import/export of keys
For example, cryptomodules such as OTP authentication tokens, may For example, Cryptographic Modules such as OTP authentication tokens,
have their symmetric keys initialized during the manufacturing may have their symmetric keys initialized during the manufacturing
process in bulk, requiring copies of the keys and algorithm data to process in bulk, requiring copies of the keys and algorithm data to
be loaded into the authentication system through a file on portable be loaded into the authentication system through a file on portable
media. The manufacturer provides the keys and related data in the media. The manufacturer provides the keys and related data in the
form of a file containing records in standard format, typically on a form of a file containing records in standard format, typically on a
CD. Note that the token manufacturer and the vendor for the CD. Note that the token manufacturer and the vendor for the
validation system may be the same or different. Some crypto modules validation system may be the same or different. Some crypto modules
will allow local PIN management (the device will have a PIN pad) will allow local PIN management (the device will have a PIN pad)
hence random initial PINs set at manufacturing should be transmitted hence random initial PINs set at manufacturing should be transmitted
together with the respective keys they protect. together with the respective keys they protect.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
ensure confidentiality of sensitive data elements. ensure confidentiality of sensitive data elements.
R13: The format MUST support a password-based encryption (PBE) R13: The format MUST support a password-based encryption (PBE)
[PKCS5] scheme to ensure security of sensitive data elements. [PKCS5] scheme to ensure security of sensitive data elements.
This is a widely used method for various provisioning This is a widely used method for various provisioning
scenarios. scenarios.
R14: The format SHOULD support asymmetric encryption algorithms such R14: The format SHOULD support asymmetric encryption algorithms such
as RSA to ensure end-to-end security of sensitive data as RSA to ensure end-to-end security of sensitive data
elements. This is to support scenarios where a pre-set shared elements. This is to support scenarios where a pre-set shared
encryption key is difficult to use. key encryption key is difficult to use.
5. Portable Key container definition 5. Portable Key container definition
The portable key container is based on an XML schema definition and The portable key container is based on an XML schema definition and
contains the following main entities: contains the following main entities:
1. KeyContainer entity as defined in Section 5.1 1. KeyContainer entity as defined in Section 5.1
2. KeyProperties entity as defined in Section 5.2 2. KeyProperties entity as defined in Section 5.2
skipping to change at page 14, line 33 skipping to change at page 14, line 33
type="pskc:DeviceType" minOccurs="1" type="pskc:DeviceType" minOccurs="1"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="Signature" <xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/> type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" type="pskc:VersionType" <xs:attribute name="Version" type="pskc:VersionType"
use="required"/> use="required"/>
<xs:attribute name="ID" type="xs:ID" <xs:attribute ref="xml:id" use="optional"/>
use="optional"/>
</xs:complexType> </xs:complexType>
The attributes of the KeyContainer have the following meanings: The attributes of the KeyContainer have the following meanings:
o Version (MANDATORY), the version number for the portable key o Version (MANDATORY), the version number for the portable key
container format (the XML schema defined in this document). container format (the XML schema defined in this document).
o ID (OPTIONAL), the unique ID for this container in case an XML o ID (OPTIONAL), the unique ID for this container in case an XML
document contains more than one container and wants to refer to document contains more than one container and wants to refer to
them uniquely. them uniquely.
The elements of the KeyContainer have the following meanings: The elements of the KeyContainer have the following meanings:
o <EncryptionKey> (OPTIONAL), Identifies the encryption key, o <EncryptionKey> (OPTIONAL), Identifies the key encryption key,
algorithm and possible parameters used to protect the Secret Key algorithm and possible parameters used to protect the Secret Key
data in the container. Please see Section 6.1 for detailed data in the container. Please see Section 6.1 for detailed
description of how to protect key data in transit and the usage of description of how to protect key data in transit and the usage of
this element. this element.
o <MACAlgorithm> (OPTIONAL), Identifies the algorithm used to o <MACAlgorithm> (OPTIONAL), Identifies the algorithm used to
generate a keyed digest of the Secret Key data values when generate a Message Authentication Code (MAC) of the Secret Key
protection algorithms are used that do not have integrity checks. data values when protection algorithms are used that do not have
The digest guarantees the integrity and the authenticity of the integrity checks. The digest guarantees the integrity and the
key data. for profile and usage please see Section 6.1.1 authenticity of the key data. for profile and usage please see
Section 6.1.1
o <KeyProperties> (OPTIONAL), key property entities containing key o <KeyProperties> (OPTIONAL), key property entities containing key
related properties that are common for keys within this container. related properties that are common for keys within this container.
Please see Section 5.2 for detailed description of this Please see Section 5.2 for detailed description of this
element.The KeyContainer MAY contain multiple KeyProperties element.The KeyContainer MAY contain multiple KeyProperties
elements each containing a set of properties related to one or elements each containing a set of properties related to one or
more keys transported within the container. more keys transported within the container.
o <Device> (MANDATORY), the host Device for one or more Keys as o <Device> (MANDATORY), the host Device for one or more Keys as
defined in Section 5.3 The KeyContainer MAY contain multiple defined in Section 5.3 The KeyContainer MAY contain multiple
skipping to change at page 15, line 37 skipping to change at page 15, line 37
when application layer provisioning or transport layer when application layer provisioning or transport layer
provisioning protocols provide the integrity and authenticity of provisioning protocols provide the integrity and authenticity of
the payload between the sender and the recipient of the container. the payload between the sender and the recipient of the container.
When required, this specification recommends using a symmetric key When required, this specification recommends using a symmetric key
based signature with the same key used in the encryption of the based signature with the same key used in the encryption of the
secret key data. The signature is enveloped. secret key data. The signature is enveloped.
o <Extensions> (OPTIONAL), is the extension point for this entity. o <Extensions> (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'definition' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.2. KeyProperties 5.2. KeyProperties
The KeyProperties represents common properties shared by more than The KeyProperties represents common properties shared by more than
one key held in the container. If a value is set in the properties 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 the Key element can refer to it via ID attribute. Values that are
present in the Key element itself MUST take precedence over values present in the Key element itself MUST take precedence over values
set in KeyProperties. The KeyProperties is defined as follows: set in KeyProperties. The KeyProperties is defined as follows:
skipping to change at page 16, line 35 skipping to change at page 16, line 29
<xs:element name="PINPolicy" <xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/> type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" <xs:element name="StartDate" type="xs:dateTime"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="ExpiryDate" <xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="ID" type="xs:ID" <xs:attribute ref="xml:id" use="required"/>
use="required"/>
<xs:attribute name="KeyAlgorithm" <xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" use="optional"/> type="pskc:KeyAlgorithmType" use="required"/>
</xs:complexType> </xs:complexType>
The attributes of the KeyProperties entity have the following The attributes of the KeyProperties entity have the following
meanings: meanings:
o ID (MANDATORY), a unique and global identifier of set of o ID (MANDATORY), a unique and global identifier of set of
KeyProperties. The identifier is defined as a string of KeyProperties. The identifier is defined as a string of
alphanumeric characters. alphanumeric characters.
o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm o KeyAlgorithm (MANDATORY), the unique URI of the type of algorithm
to use with a secret key for the profiles described in Section 6.3 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 Since KeyProperties are a method to group element values that are
common to multiple keys transported, please refer to Section 5.4 for common to multiple keys transported, please refer to Section 5.4 for
detailed description of all elements. detailed description of all elements.
5.3. Device 5.3. Device
The Device represents an extensible Device entity in the Container. 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 A Device MAY be bound to a user and MAY contain more than one key. A
skipping to change at page 18, line 6 skipping to change at page 18, line 6
'UID=[uniqueId]' SHOULD be used. 'UID=[uniqueId]' SHOULD be used.
o <Extensions> (OPTIONAL), is the extension point for this entity. o <Extensions> (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.3.1. DeviceInfo 5.3.1. DeviceInfo
The DeviceInfo represents an extensible set of elements that form the The DeviceInfo represents an extensible set of elements that form the
identifying criteria to uniquely identify the device that contains identifying criteria to uniquely identify the device that contains
the associated keys. Since devices can come in different form the associated keys. Since devices can come in different form
factors such as hardware tokens, smart-cards, soft tokens in a mobile factors such as hardware tokens, smart-cards, soft tokens in a mobile
phone or PC etc this element allows different criteria to be used. phone or PC etc this element allows different criteria to be used.
Combined though the criteria MUST uniquely identify the device. For Combined though the criteria MUST uniquely identify the device. For
skipping to change at page 19, line 42 skipping to change at page 19, line 42
specify leap seconds. specify leap seconds.
o <Extensions> (OPTIONAL), is the extension point for this entity. o <Extensions> (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.4. Key 5.4. Key
The Key represents the key entity in the KeyContainer. The Key is The Key represents the key entity in the KeyContainer. The Key is
defined as follows: defined as follows:
<xs:complexType name="KeyType"> <xs:complexType name="KeyType">
<xs:sequence> <xs:sequence>
<xs:element name="Issuer" type="xs:string" <xs:element name="Issuer" type="xs:string"
skipping to change at page 20, line 46 skipping to change at page 20, line 46
use="optional"/> use="optional"/>
</xs:complexType> </xs:complexType>
The attributes of the Key entity have the following meanings: The attributes of the Key entity have the following meanings:
o KeyId (MANDATORY), a unique and global identifier of the symmetric o KeyId (MANDATORY), a unique and global identifier of the symmetric
key. The identifier is defined as a string of alphanumeric key. The identifier is defined as a string of alphanumeric
characters. This identifier SHOULD be valid globally and outside characters. This identifier SHOULD be valid globally and outside
of the instance document of the container. of the instance document of the container.
o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm o KeyAlgorithm (MANDATORY), the unique URI of the type of algorithm
to use with the secret key, for profiles are described in to use with the secret key, for profiles are described in
Section 6.3 Section 6.3
o KeyProperties (OPTIONAL), the references to the unique id of the o KeyProperties (OPTIONAL), the references to the unique id of the
KeyProperties whose value the instance of this key inherits. If KeyProperties whose value the instance of this key inherits. If
this value is set implementation MUST lookup the Keyproperties this value is set implementation MUST lookup the Keyproperties
element referred to by this unique Id and this instance of key element referred to by this unique Id and this instance of key
will inherit all values from the KeyProperties. Values held in will inherit all values from the KeyProperties. Values held in
the key instance MUST take precedence over values inherited from the key instance MUST take precedence over values inherited from
KeyProperties."/> KeyProperties."/>
skipping to change at page 21, line 23 skipping to change at page 21, line 23
name of the organization that issues the key to the end user of name of the organization that issues the key to the end user of
the key. For example MyBank issuing hardware tokens to their the key. For example MyBank issuing hardware tokens to their
retail banking users 'MyBank' would be the issuer. The Issuer is retail banking users 'MyBank' would be the issuer. The Issuer is
defined as a String. defined as a String.
o <Usage> (OPTIONAL), defines the intended usage of the key and o <Usage> (OPTIONAL), defines the intended usage of the key and
related metadata as defined in Section 5.4.2 related metadata as defined in Section 5.4.2
o <KeyProfileId> (OPTIONAL), A unique identifier used between the o <KeyProfileId> (OPTIONAL), A unique identifier used between the
sending and receiving party of the container to establish a set of sending and receiving party of the container to establish a set of
constant values related to a key that are not transmitted via the key attribute values, common to one or more keys, that are not
container. For example a smart card application personalisation transmitted witin the container but agreed between sending and
profile id related to attributes present on a smart card receiving party of the container out of band. This Id will then
application that have influence when computing a response. An represent the unique reference to a a set of attribute values.
example could be an EMV MasterCard CAP [CAP] application on a card For example a smart card application personalisation profile id
personalised with data for a specific batch of cards such as: related to attributes present on a smart card application that
have influence when computing a response. An example would be
that a sending and receiving party agree on a set of values
related to the EMV MasterCard CAP [CAP] algorithm that application
on a card personalised with data for a specific batch of cards
such as:
IAF Internet authentication flag IAF Internet authentication flag
CVN Cryptogram version number, for example (MCHIP2, MCHIP4, CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
VISA 13, VISA14) VISA 13, VISA14)
AIP (Application Interchange Profile), 2 bytes AIP (Application Interchange Profile), 2 bytes
TVR Terminal Verification Result, 5 bytes
CVR The card verification result CVR The card verification result
AmountOther
TransactionDate
TerminalCountryCode
TransactionCurrencyCode
AmountAuthorised
IIPB IIPB
These values are not contained within attributes in the container So sending and reciving party would agree thet KeyProfileId '1'
but are shared between the manufacturing and the validation would represent a cetain set of values (e.g. IAF="80"). When
service through this unique KeyProfileId. The KeyProfileId is sending keys these values would not be transmitted as key
defined as a String. attributes but only referred to via the KeyProfileId element set
to the specific agreed profile (in this case '1'). WHen the
receiving party receives the keys it can then associate all
relevant key attributes contained in the out of band agreed
profile with the imported keys. Often this methodology is used
between between the manufacturing and the validation service to
avoid transmission of mainly the same set of values. The
KeyProfileId is defined as a String.
o <MasterKeyId> (OPTIONAL), The unique reference to an external o <MasterKeyId> (OPTIONAL), The unique reference to an external
master key when key derivation schemes are used and no specific master key when key derivation schemes are used and no specific
key is transported but only the reference to the master key used key is transported but only the reference to the master key used
to derive a specific key and some derivation data (e.g. the to derive a specific key and some derivation data (e.g. the
PKCS#11 key label in an HSM). PKCS#11 key label in an HSM).
o <FriendlyName> (OPTIONAL), The user friendly name that is assigned o <FriendlyName> (OPTIONAL), The user friendly name that is assigned
to the secret key for easy reference. The FriendlyName is defined to the secret key for easy reference. The FriendlyName is defined
as a String. as a String.
skipping to change at page 22, line 42 skipping to change at page 22, line 39
rely on time resolution finer than milliseconds and MUST NOT rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds. generate time instants that specify leap seconds.
o <ExpiryDate> (OPTIONAL), the expiry date of the key, it MUST not o <ExpiryDate> (OPTIONAL), the expiry date of the key, it MUST not
be possible to use this key after this date. MUST be expressed in be possible to use this key after this date. MUST be expressed in
UTC form, with no time zone component. Implementations SHOULD NOT UTC form, with no time zone component. Implementations SHOULD NOT
rely on time resolution finer than milliseconds and MUST NOT rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds. generate time instants that specify leap seconds.
o <UserId> (OPTIONAL), identifies the user account (e.g. username or o <UserId> (OPTIONAL), identifies the user account (e.g. username or
user id) to which the key is assigned. The value MAY be a string user id) to which the key is assigned. The value MUST be a string
representation of a Distinguished Name as defined in [RFC4514]. representation of a Distinguished Name as defined in [RFC4514].
For example "UID=jsmith,DC=example,DC=net". In systems where For example "UID=jsmith,DC=example,DC=net". In systems where
unique user Ids are used the string representation unique user Ids are used the string representation
'UID=[uniqueId]' SHOULD be used. 'UID=[uniqueId]' SHOULD be used.
o <Extensions> (OPTIONAL), is the extension point for this entity. o <Extensions> (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.4.1. KeyData 5.4.1. KeyData
Defines an extensible set of data elements relating to a key Defines an extensible set of data elements relating to a key
including the key value itself (secret). After considerable including the key value itself (secret). After considerable
discussions in forums and at IETF the authors needed a mean to convey 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 data related to a key in an extensible form. A name-value pair
that the data elements could be encrypted but not via XML encryption approach would be extensible for future new data fields but it lacks
which was deemed to complex because of canonicalization. Hence support of typing. Hence the current apporach is to have within
earlier drafts made use of a list of name value pairs. This was not KeyData a set of elements that have both typing and can be encrypted.
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 Regarding to the encryption, the requirements were that the data
elements could be simply encrypted. The XML encryption is adopted in
consideration of open standards and broad existing implementations.
In this document, a simplified profile of XML encryption is used that
only encrypts data value rather than XML elements. xenc:
EncryptedDataType is leveraged to carry encrypted data. This
simplified usage doesn't need to involve any XML canonicalization
among others.
All elements within <Data> hence obey a simple structure in that they
MUST have: MUST have:
a choice between: a choice between:
A <PlainValue> element that is typed to the specific type (e.g. A <PlainValue> element that is typed to the specific type (e.g.
xs:integer) xs:integer)
An <EncryptedValue> element that is of type xenc:EncryptedDataType An <EncryptedValue> element that is of type xenc:EncryptedDataType
where the value of the specific element is placed in case it is where the value of the specific element is placed in case it is
encrypted encrypted
an optional <ValueMac> element that is populated with a MAC in case an optional <ValueMac> element that is populated with a MAC generated
the encryption algorithm does not support integrity checks from the unencrypted value in case the encryption algorithm does not
support integrity checks
For example the pskc:intDataType is defined as follows: For example the pskc:intDataType is defined as follows:
<xs:complexType name="intDataType"> <xs:complexType name="intDataType">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:choice>
<xs:element name="PlainValue" <xs:element name="PlainValue"
type="xs:int"/> type="xs:int"/>
<xs:element name="EncryptedValue" <xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/> type="xenc:EncryptedDataType"/>
skipping to change at page 24, line 41 skipping to change at page 24, line 41
network byte order) form network byte order) form
pskc:binaryDataType - to carry data elements of type binary, pskc:binaryDataType - to carry data elements of type binary,
PlainValue sub element is of type xs:Base64Binary PlainValue sub element is of type xs:Base64Binary
pskc:stringDataType - to carry data elements of type string, pskc:stringDataType - to carry data elements of type string,
PlainValue sub element is of type xs:string. When encrypted the PlainValue sub element is of type xs:string. When encrypted the
binary value MUST UTF-8 encoded string in binary form binary value MUST UTF-8 encoded string in binary form
Therefore the KeyData element is defined as follows and contains sub Therefore the KeyData element is defined as follows and contains sub
ements to convey the values required by algorithms considered during elements to convey the values required by algorithms considered
the definition of this specification: during the definition of this specification:
<xs:complexType name="KeyDataType"> <xs:complexType name="KeyDataType">
<xs:sequence> <xs:sequence>
<xs:element name="Secret" type="pskc:binaryDataType" <xs:element name="Secret" type="pskc:binaryDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="Counter" type="pskc:longDataType" <xs:element name="Counter" type="pskc:longDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="Time" type="pskc:intDataType" <xs:element name="Time" type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="TimeInterval" type="pskc:intDataType" <xs:element name="TimeInterval" type="pskc:intDataType"
skipping to change at page 27, line 26 skipping to change at page 27, line 26
many times (for devices with PIN-input capability) many times (for devices with PIN-input capability)
The <Extensions> (OPTIONAL) element, is the extension point for the The <Extensions> (OPTIONAL) element, is the extension point for the
Usage entity. All extensions are grouped under this element and will Usage entity. All extensions are grouped under this element and will
be of type pskc:ExtensionType, which contains an optional attribute be of type pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.4.2.1. OTP and CR specific Usage elements 5.4.2.1. OTP and CR specific Usage elements
When the intended usage of a key usage is OTP and/or CR, the When the intended usage of a key usage is OTP and/or CR, the
following additional elements MUST be provided within the Usage following additional elements MUST be provided within the Usage
element to support the OTP and/or the response computation as element to support the OTP and/or the response computation as
required by the underlying algorithm. These elements also allow required by the underlying algorithm. These elements also allow
customizing or configuring the result of the computation (e.g. customizing or configuring the result of the computation (e.g.
format, length). format, length).
skipping to change at page 27, line 51 skipping to change at page 27, line 51
The ChallengeFormat element defines the characteristics of the The ChallengeFormat element defines the characteristics of the
challenge in a CR usage scenario. The Challenge element is defined challenge in a CR usage scenario. The Challenge element is defined
by the following attributes: by the following attributes:
o Format (MANDATORY), defines the format of the challenge accepted o Format (MANDATORY), defines the format of the challenge accepted
by the device and MUST be one of the values defined in by the device and MUST be one of the values defined in
Section 5.4.3 Section 5.4.3
o CheckDigit (OPTIONAL), defines if the device needs to check the o CheckDigit (OPTIONAL), defines if the device needs to check the
appended Luhn check digit contained in a provided challenge. This appended Luhn check digit, as defined in [LUHN], contained in a
is only valid if the Format attribute is 'DECIMAL'. Value MUST provided challenge. This is only valid if the Format attribute is
be: 'DECIMAL'. Value MUST be:
TRUE device will check the appended Luhn check digit in a TRUE device will check the appended Luhn check digit in a
provided challenge provided challenge
FALSE device will not check appended Luhn check digit in FALSE device will not check appended Luhn check digit in
challenge challenge
o Min (MANDATORY), defines the minimum size of the challenge o Min (MANDATORY), defines the minimum size of the challenge
accepted by the device for CR mode. If the Format attribute is accepted by the device for CR mode. If the Format attribute is
'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
skipping to change at page 28, line 41 skipping to change at page 28, line 41
response to a challenge. For cases where the key is a PIN value, response to a challenge. For cases where the key is a PIN value,
this element contains the format of the PIN itself (e.g. DECIMAL, this element contains the format of the PIN itself (e.g. DECIMAL,
length 4 for a 4 digit PIN). The Response attribute is defined by length 4 for a 4 digit PIN). The Response attribute is defined by
the following attributes: the following attributes:
o Format (MANDATORY), defines the format of the response generated o Format (MANDATORY), defines the format of the response generated
by the device and MUST be one of the values defined in by the device and MUST be one of the values defined in
Section 5.4.3 Section 5.4.3
o CheckDigit (OPTIONAL), defines if the device needs to append a o CheckDigit (OPTIONAL), defines if the device needs to append a
Luhn check digit to the response. This is only valid if the Luhn check digit,as defined in [LUHN], to the response. This is
Format attribute is 'DECIMAL'. Value MUST be: only valid if the Format attribute is 'DECIMAL'. Value MUST be:
TRUE device will append a Luhn check digit to the response. TRUE device will append a Luhn check digit to the response.
FALSE device will not append a Luhn check digit to the FALSE device will not append a Luhn check digit to the
response. response.
o Length (MANDATORY), defines the length of the response generated o Length (MANDATORY), defines the length of the response generated
by the device. If the Format attribute is 'DECIMAL', by the device. If the Format attribute is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or digits/characters. If the Format attribute is 'BASE64' or
skipping to change at page 30, line 35 skipping to change at page 30, line 35
o PINKeyId (OPTIONAL), the unique key Id of the key held within this o PINKeyId (OPTIONAL), the unique key Id of the key held within this
container that contains the value of the PIN that protects the key container that contains the value of the PIN that protects the key
The elements of PINPolicy have the following meaning The elements of PINPolicy have the following meaning
o <PINUsageMode> (MANDATORY) , the way the PIN is used during the o <PINUsageMode> (MANDATORY) , the way the PIN is used during the
usage of the key as defined in Section 5.4.4.1 usage of the key as defined in Section 5.4.4.1
o <MaxFailedAttempts> (OPTIONAL), the maximum number of times the o <MaxFailedAttempts> (OPTIONAL), the maximum number of times the
PIN can be entered wrongly before it MUST not be possible to use PIN can be entered wrongly before it MUST not be possible to use
the key anymore the key anymore. If PinUsageMode is 'Local' the device MUST
enforce this value, otherwise it MUST be enforced by the
validation server.
o <MinLength> (OPTIONAL), the minimum lenght of a PIN that can be o <MinLength> (OPTIONAL), the minimum lenght of a PIN that can be
set to protect this key. It MUST not be possible to set a PIN set to protect this key. It MUST not be possible to set a PIN
shorter than this value. If the Format element is 'DECIMAL', shorter than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or digits/characters. If the Format attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the 'BINARY', this value indicates the number of bytes of the
unencoded value. unencoded value. If PinUsageMode is 'Local' the device MUST
enforce this value, otherwise it MUST be enforced by the
validation server.
o <MaxLength> (OPTIONAL), the maximum lenght of a PIN that can be o <MaxLength> (OPTIONAL), the maximum lenght of a PIN that can be
set to protect this key. It MUST not be possible to set a PIN set to protect this key. It MUST not be possible to set a PIN
longer than this value. If the Format element is 'DECIMAL', longer than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or digits/characters. If the Format attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the 'BINARY', this value indicates the number of bytes of the
unencoded value. unencoded value. If PinUsageMode is 'Local' the device MUST
enforce this value, otherwise it MUST be enforced by the
validation server.
o <Format> (OPTIONAL), defines the format of the PIN and MUST be one o <Format> (OPTIONAL), defines the format of the PIN and MUST be one
of the values defined in Section 5.4.3 of the values defined in Section 5.4.3. If PinUsageMode is
'Local' the device MUST enforce that the entered value is of this
format, otherwise it MUST be enforced by the validation server.
o <Extensions> (OPTIONAL) element, is the extension point for the o <Extensions> (OPTIONAL) element, is the extension point for the
entity. All extensions are grouped under this element and will be entity. All extensions are grouped under this element and will be
of type pskc:ExtensionType, which contains an optional attribute of type pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a extension. In this way groups of extension can be bundled under a
subelement. For example: subelement. For example:
<Extensions> <Extensions>
<MyExtension1 <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
<YourExtension99>blahblah</YourExtension99> </YourExtension99>
</Extensions> </Extensions>
5.4.4.1. PINUsageMode 5.4.4.1. PINUsageMode
The PINUsageMode element defines how the PIN is used with a specific The PINUsageMode element defines how the PIN is used with a specific
key. The PINUsageMode element also has an extension point defined as key. The PINUsageMode element also has an extension point defined as
xs:any to allow future extensibility xs:any to allow future extensibility
PINUsageMode is defined as follows: PINUsageMode is defined as follows:
skipping to change at page 33, line 50 skipping to change at page 33, line 50
<EncryptionKey> <EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey> </EncryptionKey>
.... ....
The following is the list of symmetric key encryption algorithm and The following is the list of symmetric key encryption algorithm and
possible parameters used to protect the Secret Key data in the possible parameters used to protect the Secret Key data in the
container. Systems implementing PSKC MUST support the MANDATORY container. Systems implementing PSKC MUST support the MANDATORY
algorithms detailed below. algorithms detailed below.
The encryption algorithm URI can be one of the following. The encryption algorithm URI can be one of the following. This isn't
an exhausted list. The other future OPTIONAL encryption algorithms
o http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY MAY be used.
o http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY o http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY
o http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL o http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY o http://www.w3.org/2001/04/xmlenc#aes256-cbc - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY o http://www.w3.org/2001/04/xmlenc#tripledes-cbc - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY o http://www.w3.org/2001/04/xmldsig-more#camellia128 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY o http://www.w3.org/2001/04/xmldsig-more#camellia192 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL o http://www.w3.org/2001/04/xmldsig-more#camellia256 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes128 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes192 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-aes256 - OPTIONAL
o http://www.w3.org/2001/04/xmlenc#kw-tripledes - OPTIONAL
o http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 - OPTIONAL
o http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 - OPTIONAL
o http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 - OPTIONAL
When algorithms without integrity checks are used (e.g. When algorithms without integrity checks are used (e.g.
http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value using http://www.w3.org/2001/04/xmlenc#aes128-cbc) a keyed MAC value using
the same key as the encryption key SHOULD be placed in the ValueMAC the same key as the key encryption key SHOULD be placed in the
element of the Data element. In this case the MAC algorithm type ValueMAC element of the Data element. In this case the MAC algorithm
MUST be set in the MACAlgorithm element in the key container entity type MUST be set in the MACAlgorithm element in the key container
as defined in Section 5.1. Implementations of PSKC MUST support the entity as defined in Section 5.1. Implementations of PSKC MUST
MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be support the MANDATORY MAC algorithms detailed below. The
one of the following: MACAlgorithm URI can be one of the following:
o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY
o http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 - OPTIONAL
o http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 - OPTIONAL
o http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 - OPTIONAL
For example: For example:
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1 <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm> </MACAlgorithm>
..... .....
6.1.2. Protecting keys using passphrase based encryption keys 6.1.2. Protecting keys using passphrase based key encryption keys
To be able to support passphrase based encryption keys as defined in To be able to support passphrase based key encryption keys as defined
PKCS#5 the following XML representation of the PBE relates parameters in PKCS#5 the following XML representation of the PBE relates
have been introduced in the schema. Although the approach is parameters have been introduced in the schema. Although the approach
extensible implementations of PSKC MUST support the is extensible implementations of PSKC MUST support the PKCS#5
KeyDerivationMethod algorithm URI of recommended PBKDF2 and PBES2. Differing from the PKCS#5 XML schema
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2. definition, the PBKDF2 and PBES2 are specified in two separate
elements in a <KeyContainer>. Considering that the same key
encryption key is used to encrypt all <Key> data in a container, the
PBKDF2 is specified in a newly defined subelement <DerivedKey> of the
<EncryptionKey>. The PBES2 is specified by the algorithm attribute
of EncryptionMethod in the encrypted data elements with the URI
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2.
In the following, we introduce a newly defined type <DerivedKeyType>.
It is used to carry passphrase based key derivation information. An
instance of the type MUST be included in the EncryptionKey to
indicate the passphrase identifier and key derivation. This type is
defined as follows.
<xs:complexType name="DerivedKeyType"> <xs:complexType name="DerivedKeyType">
<xs:sequence> <xs:sequence>
<xs:element name="CarriedKeyName" type="xs:string"
minOccurs="0"/>
<xs:element name="KeyDerivationMethod" <xs:element name="KeyDerivationMethod"
type="pskc:KeyDerivationMethodType" minOccurs="0"/> type="pskc:KeyDerivationMethodType" minOccurs="0"/>
<xs:element ref="xenc:ReferenceList" minOccurs="0"/> <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
<xs:element name="CarriedKeyName" type="xs:string"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Id" type="xs:ID" use="optional"/> <xs:attribute ref="xml:id" use="optional"/>
<xs:attribute name="Type" type="xs:anyURI" use="optional"/> <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyDerivationMethodType"> <xs:complexType name="KeyDerivationMethodType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" minOccurs="0" <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" <xs:attribute name="Algorithm" type="xs:anyURI"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:element name="DerivedKey" type="pskc:DerivedKeyType"/>
The attributes of the DerivedKey have the following meanings: The attributes of the DerivedKey have the following meanings:
o ID (OPTIONAL), the unique ID for this key o xml:id (OPTIONAL), the unique ID for this key
o Type (OPTIONAL), This attribute was included for conformance with o Type (OPTIONAL), This attribute was included for conformance with
xml encryption, it is an optional attribute identifying type xml encryption, it is an optional attribute identifying type
information about the plaintext form of the encrypted content. information about the plaintext form of the encrypted content.
Please see [XMLENC] section 3.1 Type for more details. Please see [XMLENC] section 3.1 Type for more details.
The elements of the DerivedKey have the following meanings: The elements of the DerivedKey have the following meanings:
o <KeyDerivationMethod>: URI of the algorithms used to derive the o <CarriedKeyName> (OPTIONAL): friendly name of the key
key e.g.
(http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2) o <KeyDerivationMethod>: define how key encryption key is derived.
Its algorithm attribute is used to indicate the key derivation
method. When PBKDF2 is used, the URI
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 MUST
be used. The extensible content <xs:any> of the element can
include any other informations associated with the given
algorithm. When PBKDF2 is used, it MUST include a subelement
<pkcs-5:PBKDF2-params> to indicate the PBKDF2 parameters such as
salt and iteration count values..
o <ReferenceList> (OPTIONAL): a list of IDs of the elements that o <ReferenceList> (OPTIONAL): a list of IDs of the elements that
have been encrypted by this key have been encrypted by this key
When PBES2 is used for encryption, its URL
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 MUST be
specified as the algorithm attribute of <xenc:EncryptionMethod>, and
its related parameters such as underlying encryption scheme and
associated parameters such as initialization vector MUST be included
set in a subelement <pskc:EncryptionScheme> included in <xenc:
EncryptionMethod>. The EncryptionScheme is defined as follows.
o <CarriedKeyName> (OPTIONAL): friendly name of the key <xs:element name="EncryptionScheme" type="xenc:EncryptionMethodType"/>
When using the PKCS5 PBE algorithm When PKCS#5 password based encryption is used, the EncryptionKey and
(URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2) EncryptionMethod MUST be used in exactly the form as shown below.
and related parameters, the DerivedKey element MUST be used within
the EncryptionKey element of the KeyContainer in exactly the form as
shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer <KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:pkcs-5= xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0"> Version="1.0">
<EncryptionKey> <pskc:EncryptionKey>
<DerivedKey Id="#Passphrase1"> <pskc:DerivedKey>
<CarriedKeyName>Passphrase1</CarriedKeyName> <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
<KeyDerivationMethod <pskc:KeyDerivationMethod
Algorithm= Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
<Parameters xsi:type="pkcs-5:PBKDF2ParameterType"> <pkcs-5:PBKDF2-params>
<Salt> <Salt>
<Specified>Df3dRAhjGh8=</Specified> <Specified>Df3dRAhjGh8=</Specified>
</Salt> </Salt>
<IterationCount>2000</IterationCount> <IterationCount>2000</IterationCount>
<KeyLength>16</KeyLength> <KeyLength>16</KeyLength>
<PRF/> <PRF/>
</Parameters> </pkcs-5:PBKDF2-params>
</KeyDerivationMethod> </pskc:KeyDerivationMethod>
</DerivedKey> <xenc:ReferenceList>
</EncryptionKey> <xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
</pskc:DerivedKey>
</pskc:EncryptionKey>
.... ....
<pskc:Device>
...
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
<pskc:Secret>
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/
pkcs-5#pbes2">
<pskc:EncryptionScheme Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc">
</pskc:EncryptionScheme>
</xenc:EncryptionMethod>
<xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
</pskc:Secret>
</pskc:Key>
</pskc:Device>
6.2. Protecting keys using asymmetric algorithms 6.2. Protecting keys using asymmetric algorithms
The following is the list of asymmetric key encryption algorithm and The following is the list of asymmetric key encryption algorithm and
possible parameters used to protect the Secret Key data in the possible parameters used to protect the Secret Key data in the
container. Systems implementing PSKC MUST support the MANDATORY container. Systems implementing PSKC MUST support the MANDATORY
algorithms detailed below. The encryption algorithm URI can be one algorithms detailed below. The encryption algorithm URI can be one
of the following. of the following.
o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY
skipping to change at page 39, line 28 skipping to change at page 41, line 28
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc:1.0" targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified" elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"> version="1.0">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation= schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/> xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#" <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation="http://www.w3.org/TR/ schemaLocation="http://www.w3.org/TR/2002/
xmlenc-core/xenc-schema.xsd"/> REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType"> <xs:complexType name="KeyContainerType">
<xs:sequence> <xs:sequence>
<xs:element name="EncryptionKey" type="ds:KeyInfoType" <xs:element name="EncryptionKey" type="ds:KeyInfoType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType" <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="KeyProperties" <xs:element name="KeyProperties"
type="pskc:KeyPropertiesType" minOccurs="0" type="pskc:KeyPropertiesType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="Device" type="pskc:DeviceType" <xs:element name="Device" type="pskc:DeviceType"
minOccurs="1" maxOccurs="unbounded"/> minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="Signature" type="ds:SignatureType" <xs:element name="Signature" type="ds:SignatureType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" type="pskc:VersionType" <xs:attribute name="Version" type="pskc:VersionType"
use="required"/> use="required"/>
<xs:attribute name="ID" <xs:attribute ref="xml:id" use="optional"/>
type="xs:ID" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="VersionType" final="restriction"> <xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/> <xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="KeyPropertiesType"> <xs:complexType name="KeyPropertiesType">
<xs:sequence> <xs:sequence>
<xs:element name="Issuer" <xs:element name="Issuer"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
skipping to change at page 40, line 32 skipping to change at page 42, line 32
<xs:element name="PINPolicy" <xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/> type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="StartDate" <xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate" <xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="ID" <xs:attribute ref="xml:id" use="required"/>
type="xs:ID" use="required"/>
<xs:attribute name="KeyAlgorithm" <xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" type="pskc:KeyAlgorithmType"
use="optional"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyType"> <xs:complexType name="KeyType">
<xs:sequence> <xs:sequence>
<xs:element name="Issuer" <xs:element name="Issuer"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="Usage" <xs:element name="Usage"
type="pskc:UsageType"/> type="pskc:UsageType"/>
<xs:element name="KeyProfileId" <xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="MasterKeyId" <xs:element name="MasterKeyId"
skipping to change at page 41, line 20 skipping to change at page 43, line 19
<xs:element name="UserId" type="xs:string" <xs:element name="UserId" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="KeyId" <xs:attribute name="KeyId"
type="xs:string" use="required"/> type="xs:string" use="required"/>
<xs:attribute name="KeyAlgorithm" <xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" type="pskc:KeyAlgorithmType"
use="required"/> use="optional"/>
<xs:attribute name="KeyProperties" <xs:attribute name="KeyProperties"
type="xs:IDREF" use="optional"/> type="xs:IDREF" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyDataType"> <xs:complexType name="KeyDataType">
<xs:sequence> <xs:sequence>
<xs:element name="Secret" <xs:element name="Secret"
type="pskc:binaryDataType" type="pskc:binaryDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="Counter" <xs:element name="Counter"
type="pskc:longDataType" type="pskc:longDataType"
skipping to change at page 43, line 5 skipping to change at page 45, line 4
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="DerivedKeyType"> <xs:complexType name="DerivedKeyType">
<xs:sequence> <xs:sequence>
<xs:element name="KeyDerivationMethod" <xs:element name="KeyDerivationMethod"
type="pskc:KeyDerivationMethodType" minOccurs="0"/> type="pskc:KeyDerivationMethodType" minOccurs="0"/>
<xs:element ref="xenc:ReferenceList" minOccurs="0"/> <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
<xs:element name="CarriedKeyName" type="xs:string" <xs:element name="CarriedKeyName" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Id" type="xs:ID" use="optional"/> <xs:attribute ref="xml:id" use="optional"/>
<xs:attribute name="Type" type="xs:anyURI" use="optional"/> <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyDerivationMethodType"> <xs:complexType name="KeyDerivationMethodType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" minOccurs="0" <xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" <xs:attribute name="Algorithm" type="xs:anyURI"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
skipping to change at page 45, line 40 skipping to change at page 47, line 39
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="ValueFormatType"> <xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/> <xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/> <xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/> <xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/> <xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/> <xs:enumeration value="BINARY"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="DerivedKey" type="pskc:DerivedKeyType"/>
<xs:element name="EncryptionScheme"
type="xenc:EncryptionMethodType"/>
<xs:element name="KeyContainer" type="pskc:KeyContainerType"/> <xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
</xs:schema> </xs:schema>
8. IANA Considerations 8. IANA Considerations
8.1. Content-type registration for 'application/pskc+xml' 8.1. Content-type registration for 'application/pskc+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
skipping to change at page 48, line 30 skipping to change at page 50, line 30
Please replace XXXX with the RFC number of this Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
8.4. Symmetric Key Algorithm Identifier Registry 8.4. Symmetric Key Algorithm Identifier Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
symmetric key cryptographic algorithm identifiers in accordance with symmetric key cryptographic algorithm identifiers in accordance with
the principles set out in RFC 2434 [RFC2434]as follows: the principles set out in RFC 5226 [RFC5226]as follows:
8.4.1. Applicability 8.4.1. Applicability
The use of URIs as algorithm identifiers provides an effectively The use of URIs as algorithm identifiers provides an effectively
unlimited namespace. While this eliminates the possibility of unlimited namespace. While this eliminates the possibility of
namespace exhaustion it creates a new concern, that divergent namespace exhaustion it creates a new concern, that divergent
identifiers will be employed for the same purpose in different identifiers will be employed for the same purpose in different
contexts. contexts.
The key algorithm registry is intended to provide a means of The key algorithm registry is intended to provide a means of
skipping to change at page 50, line 30 skipping to change at page 52, line 30
Symmetric A symmetric encryption algorithm. Symmetric A symmetric encryption algorithm.
OTP A one time password (OTP) algorithm. OTP A one time password (OTP) algorithm.
8.4.3. Registration Procedures 8.4.3. Registration Procedures
8.4.3.1. Review 8.4.3.1. Review
Algorithm identifier registrations are to be subject to Expert Review Algorithm identifier registrations are to be subject to Expert Review
as per RFC 2434 [RFC2434]. as per RFC 5226 [RFC5226].
The need for supporting documentation for the registration depends on The need for supporting documentation for the registration depends on
the nature of the request. In the case of a cryptographic algorithm the nature of the request. In the case of a cryptographic algorithm
that is being described for publication as an RFC, the request for a that is being described for publication as an RFC, the request for a
URI allocation would normally appear within the RFC itself. In the URI allocation would normally appear within the RFC itself. In the
case of a cryptographic algorithm that is fully and comprehensively case of a cryptographic algorithm that is fully and comprehensively
defined in another form, it would not be necessary to duplicate the defined in another form, it would not be necessary to duplicate the
information for the sake of issuing the information in the RFC information for the sake of issuing the information in the RFC
series. In other cases an RFC may be required in order to ensure series. In other cases an RFC may be required in order to ensure
that certain algorithm parameters are sufficiently and unambiguously that certain algorithm parameters are sufficiently and unambiguously
skipping to change at page 52, line 27 skipping to change at page 54, line 27
8.4.4.1. HOTP 8.4.4.1. HOTP
Common Name: HOTP Common Name: HOTP
Class: OTP Class: OTP
URI: http://www.ietf.org/keyprov/pskc#hotp URI: http://www.ietf.org/keyprov/pskc#hotp
Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt
Identifier Definition (this RFC) Identifier Definition: (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. The "OTP" attribute of the <Usage> MUST be set "true"
and it MUST be the only attribute set. The element
<ResponseFormat> of the <Usage> MUST be used to indicate the OTP
length and the value format.
For the <Data> elements of a <Key> of this algorithm, the
following subelements MUST be present in either the <Key> element
itself or an commonly shared <KeyProperties> element.
* Counter
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be between 6
and 9.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="987654321">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.2. OCRA (OATH Chellenge Response Algorithm) 8.4.4.2. OCRA (OATH Chellenge Response Algorithm)
Common Name: OCRA Common Name: OCRA
Class: OTP Class: OTP
URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters) URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)
- e.g. - e.g.
http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08 http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08
Algorithm Definition: http://www.ietf.org/internet-drafts/ Algorithm Definition: http://www.ietf.org/internet-drafts/
draft-mraihi-mutual-oath-hotp-variants-07.txt draft-mraihi-mutual-oath-hotp-variants-07.txt
Identifier Definition (this RFC) Identifier Definition (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. The "CR" attribute of the <Usage> MUST be set "true" and
it MUST be the only attribute set. The element <ChallengeFormat>
and <ResponseFormat> of the <Usage> MUST be present.
For the <Data> elements of a <Key> of this algorithm, the
following subelements MUST be present in either the <Key> element
itself or an commonly shared <KeyProperties> element.
* Counter
* Time
If the element <Time> is present, the following elements MUST be
also present.
* TimeInterval
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be between 6
and 9.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654322</SerialNo>
</DeviceInfo>
<Key KeyId="12345678"
KeyAlgorithm="http://www.ietf.org/keyprov/
pskc#OCRA-1:HOTP-SHA512-8:C-QN08">
<Issuer>Issuer</Issuer>
<Usage CR="true">
<ChallengeFormat Min="8" Max="8" Format="DECIMAL"/>
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.3. TOTP (OATH Time based OTP) 8.4.4.3. TOTP (OATH Time based OTP)
Common Name: TOTP Common Name: TOTP
Class: OTP Class: OTP
URI: http://www.ietf.org/keyprov/pskc#totp URI: http://www.ietf.org/keyprov/pskc#totp
Algorithm Definition: http://www.ietf.org/internet-drafts/ Algorithm Definition: http://www.ietf.org/internet-drafts/
draft-mraihi-totp-timebased-00.txt draft-mraihi-totp-timebased-00.txt
Identifier Definition (this RFC) Identifier Definition (this RFC)
skipping to change at page 53, line 17 skipping to change at page 57, line 48
URI: http://www.ietf.org/keyprov/pskc#totp URI: http://www.ietf.org/keyprov/pskc#totp
Algorithm Definition: http://www.ietf.org/internet-drafts/ Algorithm Definition: http://www.ietf.org/internet-drafts/
draft-mraihi-totp-timebased-00.txt draft-mraihi-totp-timebased-00.txt
Identifier Definition (this RFC) Identifier Definition (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. The "OTP" attribute of the <Usage> MUST be set "true"
and it MUST be the only attribute set. The element
<ResponseFormat> of the <Usage> MUST be used to indicate the OTP
length and the value format.
For the <Data> elements of a <Key> of this algorithm, the
following subelements MUST be present in either the <Key> element
itself or an commonly shared <KeyProperties> element.
* Time
* TimeInterval
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be between 6
and 9.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654323</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#totp"
KeyId="987654323">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Time>
<PlainValue>0</PlainValue>
</Time>
<TimeInterval>
<PlainValue>30</PlainValue>
</TimeInterval>
<TimeDrift>
<PlainValue>4</PlainValue>
</TimeDrift>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.4. KEYPROV-PIN 8.4.4.4. KEYPROV-PIN
Common Name: KEYPROV-PIN Common Name: KEYPROV-PIN
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
URI: http://www.ietf.org/keyprov/pskc#pin URI: http://www.ietf.org/keyprov/pskc#pin
Algorithm Definition: (this document) Algorithm Definition: (this document)
skipping to change at page 53, line 28 skipping to change at page 60, line 4
Common Name: KEYPROV-PIN Common Name: KEYPROV-PIN
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
URI: http://www.ietf.org/keyprov/pskc#pin URI: http://www.ietf.org/keyprov/pskc#pin
Algorithm Definition: (this document) Algorithm Definition: (this document)
Identifier Definition (this document) Identifier Definition (this document)
Registrant Contact: IESG Registrant Contact: IESG
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MAY be
present. No attribute of the <Usage> is required. The element
<ResponseFormat> MAY be used to indicate the PIN value format.
The <Data> elements of a <Key> of this algorithm MUST include
<Secret>. A key of this type is usually paired with another key
where the PIN may be used together, for example, a HOTP key.
See the example in section Section 11.2
8.4.4.5. SecurID-AES 8.4.4.5. SecurID-AES
Common Name: SecurID-AES Common Name: SecurID-AES
Class: OTP Class: OTP
URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES otps-wst#SecurID-AES
Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821 Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821 Identifier Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Registrant Contact: Andrea Doherty, RSA the Security Division of Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC, <andrea.doherty@rsa.com> EMC, <andrea.doherty@rsa.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
<Usage> sub-elements MUST be present. The "OTP" attribute of
<Usage> MUST be set to "true" and it MUST be the only attribute
set. The <ResponseFormat> sub-element of <Usage> MUST be used to
indicate the OTP length and the value format.
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be set to a
minimum value of 6.
- The <StartDate> and <ExpiryDate> elements MUST be of type
<xs:dateTime>.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
<Device>
<DeviceInfo>
<Manufacturer>RSA, The Security Division of EMC</Manufacturer>
<SerialNo>123456798</SerialNo>
</DeviceInfo>
<Key
KeyAlgorithm=http://www.rsasecurity.com/rsalabs/otps/schemas/2005
/09/otps-wst#SecurID-AES
KeyId="23456789">
<Issuer>Issuer</Issuer>
<Usage OTP="true>
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<StartDate>2006-04-14T00:00:00Z</StartDate>
<ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
</Key>
</Device>
</KeyContainer>
8.4.4.6. SecurID-AES-Counter 8.4.4.6. SecurID-AES-Counter
Common Name: SecurID-AES-Counter Common Name: SecurID-AES-Counter
Class: OTP Class: OTP
URI: http://www.rsa.com/names/2008/04/algorithms/ URI: http://www.rsa.com/names/2008/04/algorithms/SecurID/
SecurID#SecurID-AES128-Counter SecurID-AES128-Counter
Algorithm Definition: http://www.rsa.com/names/2008/04/algorithms/ Algorithm Definition: http://www.rsa.com/names/2008/04/algorithms/
SecurID#SecurID-AES128-Counter SecurID/SecurID-AES128-Counter
Identifier Definition http://www.rsa.com/names/2008/04/algorithms/ Identifier Definition http://www.rsa.com/names/2008/04/algorithms/
SecurID#SecurID-AES128-Counter SecurID/SecurID-AES128-Counter
Registrant Contact: Andrea Doherty, RSA the Security Division of Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC, <andrea.doherty@rsa.com> EMC, <andrea.doherty@rsa.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
<Usage> sub-elements MUST be present. The "OTP" attribute of
<Usage> MUST be set to "true" and it MUST be the only attribute
set. The <ResponseFormat> sub-element of <Usage> MUST be used to
indicate the OTP length and the value format.
For the Data elements of a <Key> of this algorithm, the following
subelements MUST be present in either the <Key> element itself or
an commonly shared <KeyProperties> element.
* Counter
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be set to a
minimum value of 6.
- The <StartDate> and <ExpiryDate> elements MUST be of type
<xs:dateTime>.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
<Device>
<DeviceInfo>
<Manufacturer>RSA, The Security Division of EMC</Manufacturer>
<SerialNo>123456798</SerialNo>
</DeviceInfo>
<Key
KeyAlgorithm=http://www.rsa.com/names/2008/04/algorithms/
SecurID/SecurID-AES128-Counter
KeyId="23456789">
<Issuer>Issuer</Issuer>
<Usage OTP="true>
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<StartDate>2006-04-14T00:00:00Z</StartDate>
<ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.7. SecurID-ALGOR 8.4.4.7. SecurID-ALGOR
Common Name: SecurID-ALGOR Common Name: SecurID-ALGOR
Class: OTP Class: OTP
URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-ALGOR otps-wst#SecurID-ALGOR
Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821 Algorithm Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Identifier Definition http://www.rsa.com/rsalabs/node.asp?id=2821 Identifier Definition: http://www.rsa.com/rsalabs/node.asp?id=2821
Registrant Contact: Andrea Doherty, RSA the Security Division of Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC, <andrea.doherty@rsa.com> EMC, <andrea.doherty@rsa.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
<Usage> sub-elements MUST be present. The "OTP" attribute of
<Usage> MUST be set to "true" and it MUST be the only attribute
set. The <ResponseFormat> sub-element of <Usage> MUST be used to
indicate the OTP length and the value format.
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a lengthy of at least 8 octets (64 bits) if it is present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL", and the 'Length' attribute MUST be set to a
value of 6 through 8.
- The <StartDate> and <ExpiryDate> elements MUST be of type
<xs:dateTime>.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
<Device>
<DeviceInfo>
<Manufacturer>RSA, The Security Division of EMC</Manufacturer>
<SerialNo>123456798</SerialNo>
</DeviceInfo>
<Key
KeyAlgorithm=http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/09/otps-wst#SecurID-ALGOR KeyId="23456789">
<Issuer>Issuer</Issuer>
<Usage OTP="true>
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<StartDate>2006-04-14T00:00:00Z</StartDate>
<ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
</Key>
</Device>
</KeyContainer>
8.4.4.8. ActivIdentity-3DES 8.4.4.8. ActivIdentity-3DES
Common Name: ActivIdentity-3DES Common Name: ActivIdentity-3DES
Class: OTP Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/ URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-3DES algorithms#ActivIdentity-3DES
skipping to change at page 55, line 4 skipping to change at page 65, line 40
Class: OTP Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/ URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-3DES algorithms#ActivIdentity-3DES
Algorithm Definition: http://www.actividentity.com/2008/04/ Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-3DES algorithms/algorithms#ActivIdentity-3DES
Identifier Definition http://www.actividentity.com/2008/04/ Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-3DES algorithms/algorithms#ActivIdentity-3DES
Registrant Contact: Philip Hoyer, ActivIdentity Inc, Registrant Contact: Philip Hoyer, ActivIdentity Inc,
<philip.hoyer@actividentity.com> <philip.hoyer@actividentity.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. This algorithm can be used for otp, challenge response,
parameter based MACing (integrity) and to generate a device unlock
code (n case of devices where there is local PIN management and
the devce has been locked after a specific amount of wrong PIN
entry attempts). Hence the "OTP", "CR","Integrity" and "Unlock"
attribute of the <Usage> can be set to "true", but at least one of
the above MUST be set to true. The element <ResponseFormat> of
the <Usage> MUST be used to indicate the OTP length, the value
format and optionally if a check digit is being used. If the use
is challenge-response then the <ChallengeFormat> of the <Usage>
MUST be used to indicate the challenge minimum and maximum length,
its format and optionally if a check digit is being used.
For the <Data> elements of a <Key> of this algorithm, the
following subelements MUST be present in either the <Key> element
itself or an commonly shared <KeyProperties> element.
* Secret
* Counter
* Time
* TimeInterval
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a length of at least 16 octets (Double DES keys 128 bits
including parity) if it is present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
MUST be between 6 and 16.
- The <ChallengeFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
be between 4 and 16 (The Min attribute MUST be equal or less
than the Max).
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a Key of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>ActivIdentity</Manufacturer>
<SerialNo>34567890</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.actividentity.com/
2008/04/algorithms/algorithms#ActivIdentity-3DES"
KeyId="12345677">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
<Time>
<PlainValue>0</PlainValue>
</Time>
<TimeInterval>
<PlainValue>32</PlainValue>
</TimeInterval>
<TimeDrift>
<PlainValue>0</PlainValue>
</TimeDrift>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.9. ActivIdentity-AES 8.4.4.9. ActivIdentity-AES
Common Name: ActivIdentity-AES Common Name: ActivIdentity-AES
Class: OTP Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/ URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-AES algorithms#ActivIdentity-AES
Algorithm Definition: http://www.actividentity.com/2008/04/ Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-AES algorithms/algorithms#ActivIdentity-AES
Identifier Definition http://www.actividentity.com/2008/04/ Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-AES algorithms/algorithms#ActivIdentity-AES
Registrant Contact: Philip Hoyer, ActivIdentity Inc, Registrant Contact: Philip Hoyer, ActivIdentity Inc,
<philip.hoyer@actividentity.com> <philip.hoyer@actividentity.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. This algorithm can be used for otp, challenge response,
parameter based MACing (integrity) and to generate a device unlock
code (n case of devices where there is local PIN management and
the devce has been locked after a specific amount of wrong PIN
entry attempts). Hence the "OTP", "CR","Integrity" and "Unlock"
attribute of the <Usage> can be set to "true", but at least one of
the above MUST be set to true. The element <ResponseFormat> of
the <Usage> MUST be used to indicate the OTP length, the value
format and optionally if a check digit is being used. If the use
is challenge-response then the <ChallengeFormat> of the <Usage>
MUST be used to indicate the challenge minimum and maximum length,
its format and optionally if a check digit is being used.
For the <Data> elements of a key of this algorithm, the following
subelements MUST be present in either the <Key> element itself or
an commonly shared <KeyProperties> element.
* Secret
* Counter
* Time
* TimeInterval
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a length of at least 16 octets (128 bits) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
MUST be between 6 and 16.
- The <ChallengeFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
be between 4 and 16 (The Min attribute MUST be equal or less
than the Max).
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>ActivIdentity</Manufacturer>
<SerialNo>34567890</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.actividentity.com/
2008/04/algorithms/algorithms#ActivIdentity-AES"
KeyId="12345677">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
<Time>
<PlainValue>0</PlainValue>
</Time>
<TimeInterval>
<PlainValue>32</PlainValue>
</TimeInterval>
<TimeDrift>
<PlainValue>0</PlainValue>
</TimeDrift>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.10. ActivIdentity-DES 8.4.4.10. ActivIdentity-DES
Common Name: ActivIdentity-DES Common Name: ActivIdentity-DES
Class: OTP Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/ URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-DES algorithms#ActivIdentity-DES
Algorithm Definition: http://www.actividentity.com/2008/04/ Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-DES algorithms/algorithms#ActivIdentity-DES
Identifier Definition http://www.actividentity.com/2008/04/ Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-DES algorithms/algorithms#ActivIdentity-DES
Registrant Contact: Philip Hoyer, ActivIdentity Inc, Registrant Contact: Philip Hoyer, ActivIdentity Inc,
<philip.hoyer@actividentity.com> <philip.hoyer@actividentity.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. This algorithm can be used for otp, challenge response,
parameter based MACing (integrity) and to generate a device unlock
code (n case of devices where there is local PIN management and
the devce has been locked after a specific amount of wrong PIN
entry attempts). Hence the "OTP", "CR","Integrity" and "Unlock"
attribute of the <Usage> can be set to "true", but at least one of
the above MUST be set to true. The element <ResponseFormat> of
the <Usage> MUST be used to indicate the OTP length, the value
format and optionally if a check digit is being used. If the use
is challenge-response then the <ChallengeFormat> of the <Usage>
MUST be used to indicate the challenge minimum and maximum length,
its format and optionally if a check digit is being used.
For the <Data> elements of a key of this algorithm, the following
subelements MUST be present in either the <Key> element itself or
an commonly shared <KeyProperties> element.
* Counter
* Time
* TimeInterval
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a length of at least 8 octets (56 bits + parity) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
MUST be between 6 and 16.
- The <ChallengeFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
be between 4 and 16 (The Min attribute MUST be equal or less
than the Max).
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>ActivIdentity</Manufacturer>
<SerialNo>34567890</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.actividentity.com/
2008/04/algorithms/algorithms#ActivIdentity-DES"
KeyId="12345677">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
<Time>
<PlainValue>0</PlainValue>
</Time>
<TimeInterval>
<PlainValue>32</PlainValue>
</TimeInterval>
<TimeDrift>
<PlainValue>0</PlainValue>
</TimeDrift>
</Data>
</Key>
</Device>
</KeyContainer>
8.4.4.11. ActivIdentity-EVENT 8.4.4.11. ActivIdentity-EVENT
Common Name: ActivIdentity-EVENT Common Name: ActivIdentity-EVENT
Class: OTP Class: OTP
URI: http://www.actividentity.com/2008/04/algorithms/ URI: http://www.actividentity.com/2008/04/algorithms/
algorithms#ActivIdentity-EVENT algorithms#ActivIdentity-EVENT
Algorithm Definition: http://www.actividentity.com/2008/04/ Algorithm Definition: http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-EVENT algorithms/algorithms#ActivIdentity-EVENT
Identifier Definition http://www.actividentity.com/2008/04/ Identifier Definition http://www.actividentity.com/2008/04/
algorithms/algorithms#ActivIdentity-EVENT algorithms/algorithms#ActivIdentity-EVENT
Registrant Contact: Philip Hoyer, ActivIdentity Inc, Registrant Contact: Philip Hoyer, ActivIdentity Inc,
<philip.hoyer@actividentity.com> <philip.hoyer@actividentity.com>
Profile of XML attributes and subelements of the <Key> entity:
For a <Key> of this algorithm, the <Usage> subelements MUST be
present. This algorithm can be used for otp, challenge response,
parameter based MACing (integrity) and to generate a device unlock
code (n case of devices where there is local PIN management and
the device has been locked after a specific amount of wrong PIN
entry attempts). Hence the "OTP", "CR","Integrity" and "Unlock"
attribute of the <Usage> can be set to "true", but at least one of
the above MUST be set to true. The element <ResponseFormat> of
the <Usage> MUST be used to indicate the OTP length, the value
format and optionally if a check digit is being used. If the use
is challenge-response then the <ChallengeFormat> of the <Usage>
MUST be used to indicate the challenge minimum and maximum length,
its format and optionally if a check digit is being used.
For the <Data> elements of a key of this algorithm, the following
subelements MUST be present in either the <Key> element itself or
an commonly shared <KeyProperties> element.
* Counter
The following additional constraints apply:
- The value of the <Secret> element MUST contain key material
with a length of at least 8 octets (56 bits + parity) if it is
present.
- The <ResponseFormat> element MUST have the 'Format' attribute
set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
MUST be between 6 and 16.
- The <PINPolicy> element MAY be present but the <Format> child
element of the <PINPolicy> element cannot be set to
"Algorithmic".
An example of a <Key> of this algorithm is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device>
<DeviceInfo>
<Manufacturer>ActivIdentity</Manufacturer>
<SerialNo>34567890</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm="http://www.actividentity.com/
2008/04/algorithms/algorithms#ActivIdentity-EVENT"
KeyId="12345677">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</Device>
</KeyContainer>
9. Security Considerations 9. Security Considerations
The portable key container carries sensitive information (e.g., The portable key container carries sensitive information (e.g.,
cryptographic keys) and may be transported across the boundaries of cryptographic keys) and may be transported across the boundaries of
one secure perimeter to another. For example, a container residing one secure perimeter to another. For example, a container residing
within the secure perimeter of a back-end provisioning server in a within the secure perimeter of a back-end provisioning server in a
secure room may be transported across the internet to an end-user secure room may be transported across the internet to an end-user
device attached to a personal computer. This means that special care device attached to a personal computer. This means that special care
must be taken to ensure the confidentiality, integrity, and must be taken to ensure the confidentiality, integrity, and
authenticity of the information contained within. authenticity of the information contained within.
skipping to change at page 57, line 31 skipping to change at page 76, line 31
First, the container key data payload may be encrypted. First, the container key data payload may be encrypted.
In this case no transport layer security is required. However, In this case no transport layer security is required. However,
standard security best practices apply when selecting the strength of standard security best practices apply when selecting the strength of
the cryptographic algorithm for payload encryption. Symmetric the cryptographic algorithm for payload encryption. Symmetric
cryptographic cipher should be used - the longer the cryptographic cryptographic cipher should be used - the longer the cryptographic
key, the stronger the protection. At the time of this writing both key, the stronger the protection. At the time of this writing both
3DES and AES are mandatory algorithms but 3DES may be dropped in the 3DES and AES are mandatory algorithms but 3DES may be dropped in the
relatively near future. Applications concerned with algorithm relatively near future. Applications concerned with algorithm
longevity are advised to use AES-256-CBC. In cases where the longevity are advised to use AES-256-CBC. In cases where the
exchange of encryption keys between the sender and the receiver is exchange of key encryption keys between the sender and the receiver
not possible, asymmetric encryption of the secret key payload may be is not possible, asymmetric encryption of the secret key payload may
employed. Similarly to symmetric key cryptography, the stronger the be employed. Similarly to symmetric key cryptography, the stronger
asymmetric key, the more secure the protection is. the asymmetric key, the more secure the protection is.
If the payload is encrypted with a method that uses one of the If the payload is encrypted with a method that uses one of the
password-based encryption methods provided above, the payload may be password-based encryption methods provided above, the payload may be
subjected to password dictionary attacks to break the encryption subjected to password dictionary attacks to break the encryption
password and recover the information. Standard security best password and recover the information. Standard security best
practices for selection of strong encryption passwords apply practices for selection of strong encryption passwords apply
[Schneier]. [Schneier].
Practical implementations should use PBESalt and PBEIterationCount Practical implementations should use PBESalt and PBEIterationCount
when PBE encryption is used. Different PBESalt value per key when PBE encryption is used. Different PBESalt value per key
skipping to change at page 60, line 8 skipping to change at page 79, line 8
The authors of this draft would like to thank the following people The authors of this draft would like to thank the following people
for their contributions and support to make this a better for their contributions and support to make this a better
specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders
Rundgren, Sean Turner and especially Robert Philpott. Rundgren, Sean Turner and especially Robert Philpott.
11. Appendix A - Example Symmetric Key Containers 11. Appendix A - Example Symmetric Key Containers
All examples are syntactically correct and compatible with the XML All examples are syntactically correct and compatible with the XML
schema in section 7. schema in section 7. The examples will be revised as the test
vectors for implementation interoperability verification. Two of the
examples below carry some sample test inputs.
11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
Key Key
Assume the following test data:
OTP Secret Key Hex Value (20 bytes):
0x3132333435363738393031323334353637383930
Sample KeyContainer:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="987654321"> KeyId="987654321">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="8" <ResponseFormat Length="8" Format="DECIMAL"/>
Format="DECIMAL"/>
</Usage> </Usage>
<StartDate>2006-04-14T00:00:00Z</StartDate>
<ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
<Data> <Data>
<Secret> <Secret>
<PlainValue> <PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue> </PlainValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
skipping to change at page 61, line 9 skipping to change at page 81, line 9
</Device> </Device>
</KeyContainer> </KeyContainer>
11.2. Symmetric Key Container with a single PIN protected Non-Encrypted 11.2. Symmetric Key Container with a single PIN protected Non-Encrypted
HOTP Secret Key HOTP Secret Key
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>0755225266</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266"> KeyId="0755225266">
<Issuer>AnIssuer</Issuer> <Issuer>AnIssuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/> <ResponseFormat Length="6" Format="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
<Secret> <Secret>
skipping to change at page 62, line 5 skipping to change at page 82, line 5
<Secret> <Secret>
<PlainValue> <PlainValue>
MTIzNA== MTIzNA==
</PlainValue> </PlainValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP 11.3. Symmetric Key Container with a single AES-128-CBC Encrypted HOTP
Secret Key and non-encrypted counter value Secret Key and non-encrypted counter value
Assume the following test data:
OTP Secret Key Hex Value (20 bytes):
0x3132333435363738393031323334353637383930
AES Key Hex Value (16 bytes): 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
The MAC key is the same as the AES encryption key.
The sample KeyContainer:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1 <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm> </MACAlgorithm>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>0755225266</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266"> KeyId="0755225266">
<Issuer>AnIssuer</Issuer> <Issuer>AnIssuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="8" Format="DECIMAL"/> <ResponseFormat Length="8" Format="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
<Secret> <Secret>
<EncryptedValue> <EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>xxxxxxxxxxxxxxxxxxxxxx
gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC> <ValueMAC>xxxxxxxxxxxxxxxxxxxxxx</ValueMAC>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
11.4. Symmetric Key Container with signature and a single Password- 11.4. Symmetric Key Container with signature and a single Password-
based Encrypted HOTP Secret Key based Encrypted HOTP Secret Key
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer <pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:pkcs-5= xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
Version="1.0">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<pskc:DerivedKey Id="#Passphrase1"> <pskc:DerivedKey>
<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName> <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
<pskc:KeyDerivationMethod <pskc:KeyDerivationMethod
Algorithm= Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
<pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType"> <pkcs-5:PBKDF2-params>
<Salt> <Salt>
<Specified>Df3dRAhjGh8=</Specified> <Specified>P1ciQdGbrI0=</Specified>
</Salt> </Salt>
<IterationCount>2000</IterationCount> <IterationCount>2000</IterationCount>
<KeyLength>16</KeyLength> <KeyLength>16</KeyLength>
<PRF/> <PRF/>
</pkcs-5:Parameters> </pkcs-5:PBKDF2-params>
</pskc:KeyDerivationMethod> </pskc:KeyDerivationMethod>
<xenc:ReferenceList> <xenc:ReferenceList>
<xenc:DataReference URI="#ED"/> <xenc:DataReference URI="#ED"/>
</xenc:ReferenceList> </xenc:ReferenceList>
</pskc:DerivedKey> </pskc:DerivedKey>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:Device> <pskc:Device>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266"> KeyId="0755225266">
<pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Issuer>AnIssuer</pskc:Issuer>
<pskc:Usage OTP="true"> <pskc:Usage OTP="true">
<pskc:ResponseFormat Length="6" Format="DECIMAL"/> <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
</pskc:Usage> </pskc:Usage>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
<pskc:EncryptedValue Id="ED"> <pskc:EncryptedValue>
<xenc:EncryptionMethod Algorithm= <xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#kw-aes128"/> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
pkcs-5#pbes2">
<pskc:EncryptionScheme Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc">
</pskc:EncryptionScheme>
</xenc:EncryptionMethod>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:EncryptedValue> </pskc:EncryptedValue>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
<pskc:Signature> <pskc:Signature>
<ds:SignedInfo> <ds:SignedInfo>
<ds:CanonicalizationMethod <ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod <ds:SignatureMethod Algorithm=
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI=""> <ds:Reference URI="">
<ds:DigestMethod Algorithm= <ds:DigestMethod Algorithm=
"http://www.w3.org/2000/09/xmldsig#sha1"/> "http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:DigestValue>
</ds:Reference> </ds:Reference>
</ds:SignedInfo> </ds:SignedInfo>
<ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue> <ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:SignatureValue>
<ds:KeyInfo> <ds:KeyInfo>
<ds:X509Data> <ds:X509Data>
<ds:X509IssuerSerial> <ds:X509IssuerSerial>
<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US <ds:X509IssuerName>CN=KeyProvisioningUs.com,C=US
</ds:X509IssuerName> </ds:X509IssuerName>
<ds:X509SerialNumber>12345678</ds:X509SerialNumber> <ds:X509SerialNumber>12345678
</ds:X509SerialNumber>
</ds:X509IssuerSerial> </ds:X509IssuerSerial>
</ds:X509Data> </ds:X509Data>
</ds:KeyInfo> </ds:KeyInfo>
</pskc:Signature> </pskc:Signature>
</pskc:KeyContainer> </pskc:KeyContainer>
11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP 11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
Secret Key Secret Key
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer Version="1.0" <pskc:KeyContainer Version="1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<ds:X509Data> <ds:X509Data>
<ds:X509Certificate>miib</ds:X509Certificate> <ds:X509Certificate>miib</ds:X509Certificate>
</ds:X509Data> </ds:X509Data>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:Device> <pskc:Device>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266"> KeyId="0755225266">
<pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Issuer>AnIssuer</pskc:Issuer>
<pskc:Usage OTP="true"> <pskc:Usage OTP="true">
<pskc:ResponseFormat Length="8" Format="DECIMAL"/> <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
</pskc:Usage> </pskc:Usage>
<pskc:Data> <pskc:Data>
<pskc:Secret> <pskc:Secret>
skipping to change at page 66, line 44 skipping to change at page 86, line 44
</pskc:EncryptedValue> </pskc:EncryptedValue>
</pskc:Secret> </pskc:Secret>
<pskc:Counter> <pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue> <pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter> </pskc:Counter>
</pskc:Data> </pskc:Data>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</pskc:KeyContainer> </pskc:KeyContainer>
11.6. Symmetric Key Container with a single AES-256-CBC Encrypted OCRA 11.6. Symmetric Key Container with a single AES-128-CBC Encrypted OCRA
Secret Key and non-encrypted counter value Secret Key and non-encrypted counter value
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName> <ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm> <MACAlgorithm>
http://www.w3.org/2000/09/xmldsig#hmac-sha1 http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm> </MACAlgorithm>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyId="12345678" <Key KeyId="12345678"
KeyAlgorithm="http://www.ietf.org/keyprov/ KeyAlgorithm="http://www.ietf.org/keyprov/
pskc#OCRA-1:HOTP-SHA512-8:C-QN08"> pskc#OCRA-1:HOTP-SHA512-8:C-QN08">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage CR="true"> <Usage CR="true">
<ChallengeFormat Min="8" <ChallengeFormat Min="8"
Max="8" Format="DECIMAL"/> Max="8" Format="DECIMAL"/>
<ResponseFormat <ResponseFormat
Length="8" Format="DECIMAL"/> Length="8" Format="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
<Secret> <Secret>
<EncryptedValue> <EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok= gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC> <ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
skipping to change at page 68, line 20 skipping to change at page 89, line 16
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1 <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm> </MACAlgorithm>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>0755225266</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm= <Key KeyAlgorithm=
"http://www.ietf.org/keyprov/pskc#totp" "http://www.ietf.org/keyprov/pskc#totp"
KeyId="0755225266"> KeyId="0755225266">
<Issuer>AnIssuer</Issuer> <Issuer>AnIssuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/> <ResponseFormat Length="6" Format="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
skipping to change at page 68, line 49 skipping to change at page 89, line 45
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC> <ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
</Secret> </Secret>
<Time> <Time>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Time> </Time>
<TimeInterval> <TimeInterval>
<PlainValue>30</PlainValue> <PlainValue>30</PlainValue>
</TimeInterval> </TimeInterval>
<TimeDrift>
<PlainValue>4</PlainValue>
</TimeDrift>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
11.8. Symmetric Key Container with two devices containing a Non- 11.8. Symmetric Key Container with two devices containing a Non-
Encrypted HOTP Secret Key each sharing common KeyProperties Encrypted HOTP Secret Key each sharing common KeyProperties
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<KeyProperties ID="KPID1" <KeyProperties xml:id="KPID1"
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"> KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="8" <ResponseFormat Length="8"
Format="DECIMAL"/> Format="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</KeyProperties> </KeyProperties>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyProperties="KPID1" <Key KeyProperties="KPID1"
KeyId="987654321"> KeyId="987654321">
<Data> <Data>
<Secret> <Secret>
<PlainValue> <PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue> </PlainValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654322</SerialNo> <SerialNo>987654322</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyProperties="KPID1" <Key KeyProperties="KPID1"
KeyId="987654322"> KeyId="987654322">
<Data> <Data>
<Secret> <Secret>
<PlainValue> <PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue> </PlainValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
12. References 12. References
12.1. Normative References 12.1. Normative References
[PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
Specifications Version 2.0.", August 1960, <http://patft.uspto.gov/netacgi/
URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, nph-Parser?patentnumber=2950048>.
October 1998.
[PKCS1] Kaliski, B., "PKCS #1: RSA Cryptography Specifications
Version 2.0.", RFC 2437, October 1998.
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
Standard", Version 2.0, Standard", Version 2.0,
URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999. URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997, Levels", BCP 14, RFC 2119, March 1997.
<http://www.ietf.org/rfc/rfc2119.txt>.
[RFC2434] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, October 1998.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3553] Mealling, M., "An IETF URN Sub-namespace for Registered [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
Protocol Parameters", RFC 3553, June 2003. IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", [XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002. W3C Recommendation, February 2002.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, December 2002. URL: http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002.
12.2. Informative References 12.2. Informative References
[AlgorithmURIs]
Eastlake, D., "Additional XML Security Uniform Resource
Identifiers", RFC 4051, April 2005.
[CAP] MasterCard International, "Chip Authentication Program [CAP] MasterCard International, "Chip Authentication Program
Functional Architecture", September 2004. Functional Architecture", September 2004.
[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol", Internet "Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/ Draft Informational, URL: http://www.ietf.org/
internet-drafts/draft-ietf-keyprov-dskpp-03.txt, internet-drafts/draft-ietf-keyprov-dskpp-05.txt,
February 2008. February 2008.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, Algorithm", RFC 4226, December 2005.
URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
December 2005.
[NIST-SP800-57] [NIST-SP800-57]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Key Management - Part I: General "Recommendation for Key Management - Part I: General
(Revised)", NIST 800-57, URL: http://csrc.nist.gov/ (Revised)", NIST 800-57, URL: http://csrc.nist.gov/
publications/nistpubs/800-57/ publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007. sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007.
[OATH] "Initiative for Open AuTHentication", [OATH] "Initiative for Open AuTHentication",
URL: http://www.openauthentication.org. URL: http://www.openauthentication.org.
skipping to change at page 74, line 44 skipping to change at line 3820
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 164 change blocks. 
297 lines changed or deleted 1103 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/