draft-ietf-keyprov-portable-symmetric-key-container-04.txt   draft-ietf-keyprov-portable-symmetric-key-container-05.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: October 23, 2008 VeriSign Expires: January 15, 2009 VeriSign
S. Machani S. Machani
Diversinet Diversinet
April 21, 2008 July 14, 2008
Portable Symmetric Key Container Portable Symmetric Key Container
draft-ietf-keyprov-portable-symmetric-key-container-04.txt draft-ietf-keyprov-portable-symmetric-key-container-05.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 October 23, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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 Crypto Module . . . . 8 3.1.1. Transport of keys from Server to Cryptomodule . . . . 8
3.1.2. Transport of keys from Crypto Module to Crypto 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.3. Transport of keys from Crypto 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 . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. DeviceId . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 20 5.4.1. KeyData . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.2. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 21 5.4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 25 5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 29
5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . . 28 key container . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Usage of EncryptionKey to protect keys in transit . . . . 28 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 . . . . . . . . . . . . . . . . . 28 symmetric algorithms . . . . . . . . . . . . . . . . . 33
6.1.2. Protecting keys using passphrase based encryption 6.1.2. Protecting keys using passphrase based encryption
keys . . . . . . . . . . . . . . . . . . . . . . . . . 29 keys . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Protecting keys using asymmetric algorithms . . . . . . . 31 6.2. Protecting keys using asymmetric algorithms . . . . . . . 36
6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 32 6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 37
6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 33 6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 38
6.3.2. PIN key value compare algorithm identifier . . . . . . 33 6.3.2. PIN key value compare algorithm identifier . . . . . . 38
7. Reserved data attribute names . . . . . . . . . . . . . . . . 34 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8.1. Content-type registration for 'application/pskc+xml' . . . 46
9.1. Content-type registration for 'application/pskc+xml' . . . 40 8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 41 8.3. URN Sub-Namespace Registration for
9.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . . . . 47
urn:ietf:params:xml:ns:keyprov:container:1.0 . . . . . . . 41 8.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 48
9.4. Symmetric Key Algorithm Identifier Registry . . . . . . . 42 8.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 48
9.4.1. Applicability . . . . . . . . . . . . . . . . . . . . 42 8.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 49
9.4.2. Registerable Algorithms . . . . . . . . . . . . . . . 43 8.4.3. Registration Procedures . . . . . . . . . . . . . . . 50
9.4.3. Registration Procedures . . . . . . . . . . . . . . . 44 8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 52
9.4.4. Initial Values . . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
9.5. XML Data Tag Identifier Registry . . . . . . . . . . . . . 49 9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 57
9.5.1. Applicability . . . . . . . . . . . . . . . . . . . . 49 9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 58
9.5.2. Registerable Data Tags . . . . . . . . . . . . . . . . 50 9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 58
9.5.3. Registration Procedures . . . . . . . . . . . . . . . 50 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
9.5.4. Initial Values . . . . . . . . . . . . . . . . . . . . 51 11. Appendix A - Example Symmetric Key Containers . . . . . . . . 60
10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 11.1. Symmetric Key Container with a single Non-Encrypted
10.1. Payload confidentiality . . . . . . . . . . . . . . . . . 53 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 60
10.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 54 11.2. Symmetric Key Container with a single PIN protected
10.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 54 Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 60
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 11.3. Symmetric Key Container with a single AES-256-CBC
12. Appendix A - Example Symmetric Key Containers . . . . . . . . 56 Encrypted HOTP Secret Key and non-encrypted counter
12.1. Symmetric Key Container with a single Non-Encrypted value . . . . . . . . . . . . . . . . . . . . . . . . . . 62
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 56 11.4. Symmetric Key Container with signature and a single
12.2. Symmetric Key Container with a single PIN protected Password-based Encrypted HOTP Secret Key . . . . . . . . . 63
Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 56 11.5. Symmetric Key Container with a single RSA 1.5
12.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 65
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 57 11.6. Symmetric Key Container with a single AES-256-CBC
12.4. Symmetric Key Container with signature and a single Encrypted OCRA Secret Key and non-encrypted counter
Password-based Encrypted HOTP Secret Key . . . . . . . . . 58 value . . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.5. Symmetric Key Container with a single RSA 1.5 11.7. Symmetric Key Container with a single AES-256-CBC
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 60 Encrypted TOTP Secret Key and non-encrypted time values . 68
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 11.8. Symmetric Key Container with two devices containing a
13.1. Normative References . . . . . . . . . . . . . . . . . . . 62 Non-Encrypted HOTP Secret Key each sharing common
13.2. Informative References . . . . . . . . . . . . . . . . . . 62 KeyProperties . . . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . . 65 12.1. Normative References . . . . . . . . . . . . . . . . . . . 71
12.2. Informative References . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
Intellectual Property and Copyright Statements . . . . . . . . . . 74
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 Internet draft describes a standard format for serializing
symmetric keys such as OTP shared secrets for system import, export symmetric keys such as OTP shared secrets for system import, export
or network/protocol transport. The goal is that the format will or network/protocol transport. The goal is that the format will
facilitate dynamic provisioning and transfer of a symmetric keys such facilitate dynamic provisioning and transfer of symmetric keys such
as an OTP shared secret or an encryption key of different types. In as OTP shared secrets or encryption keys of different types. In the
the case of OTP shared secrets, the format will facilitate dynamic case of OTP shared secrets, the format will facilitate dynamic
provisioning using an online provisioning protocol to different provisioning using an online provisioning protocol to different
flavors of embedded tokens or allow customers to import new or flavors of embedded tokens or allow customers to import new or
existing tokens in batch or single instances into a compliant system. existing tokens 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
skipping to change at page 6, line 40 skipping to change at page 6, line 40
cryptographic algorithm that determines its operation in such a cryptographic algorithm that determines its operation in such a
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
Device ID (DeviceId): A unique identifier for the device, DeviceInfo: A set of elements whose values combined uniquely
representing the identifying criteria to uniquely identify a identify a device e.g. Manufacture 'Manufacturer and Serialnumber
device '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 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
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 Crypto Module 3.1.1. Transport of keys from Server to Cryptomodule
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 cryptomodule on the device. The cryptomodule client from
vendor A initiates the provisioning process against a provisioning vendor A initiates the provisioning process against a provisioning
system from vendor B using a standards-based provisioning protocol system from vendor B using a standards-based provisioning protocol
such as [DSKPP]. The provisioning entity delivers one or more keys such as [DSKPP]. The provisioning entity delivers one or more keys
in a standard format that can be processed by the mobile device. 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
skipping to change at page 8, line 42 skipping to change at page 8, line 42
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 cryptomodule 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 Crypto Module to Crypto Module 3.1.2. Transport of keys from Cryptomodule to Cryptomodule
For example, a user wants to transport a key from one cryptomodule to For example, a user wants to transport a key from one cryptomodule to
another. There may be two cryptographic modules, one on a computer another. There may be two cryptographic modules, one on a computer
one on a mobile phone, and the user wants to transport a key from the one on a mobile phone, and the user wants to transport a key from the
computer to the mobile phone. The user can export the key and computer to the mobile phone. The user can export the key and
related data in a standard format for input into the other related data in a standard format for input into the other
cryptomodule. cryptomodule.
3.1.3. Transport of keys from Crypto Module to Server 3.1.3. Transport of keys from Cryptomodule 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 cryptomodule (e.g. SD card, USB drive)
that the user has purchased at the local electronics retailer. Along that the user has purchased at the local electronics retailer. Along
with the cryptomodule, the user may get the key on a CD or a floppy with the cryptomodule, the user may get the key on a CD or a floppy
in a standard format. The user can now upload via a secure online in a standard format. The user can now upload via a secure online
channel or import this key and related data into the new validation channel or import this key and related data into the new validation
system and start using the key. system and start using the key.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
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. 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. Device entity as defined in Section 5.2 2. KeyProperties entity as defined in Section 5.2
3. Key entity as defined in Section 5.4 3. Device entity as defined in Section 5.3
4. Key entity as defined in Section 5.4
Additionally other XML schema types have been defined and are Additionally other XML schema types have been defined and are
detailed in the relevant subsections of this document detailed in the relevant subsections of this document
A KeyContainer MAY contain one or more Device entities. A Device MAY A KeyContainer MAY contain one or more Device entities. A Device MAY
contain one or more Key entities contain one or more Key entities
The figure below indicates a possible relationship diagram of a The figure below indicates a possible relationship diagram of a
container. container.
-------------------------------------------- --------------------------------------------
| KeyContainer | | KeyContainer |
| | | |
| -------------------- |
| | Keyproperties 1 | |
| | | |
| -------------------- |
| ------------------ ----------------- | | ------------------ ----------------- |
| | Device 1 | | Device n | | | | Device 1 | | Device n | |
| | | | | | | | | | | |
| | ------------ | | ------------ | | | | ------------ | | ------------ | |
| | | Key 1 | | | | Key n | | | | | | Key 1 | | | | Key n | | |
| | ------------ | | ------------ | | | | ------------ | | ------------ | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | ------------ | | ------------ | | | | ------------ | | ------------ | |
| | | Key m | | | | Key p | | | | | | Key m | | | | Key p | | |
| | ------------ | | ------------ | | | | ------------ | | ------------ | |
| ------------------ ----------------- | | ------------------ ----------------- |
| | | |
-------------------------------------------- --------------------------------------------
The following section describe in detail all the entities and related The following sections describe in detail all the entities and
XML schema elements and attributes: related XML schema elements and attributes:
5.1. KeyContainer 5.1. KeyContainer
The KeyContainer represents the key container entity. A Container The KeyContainer represents the key container entity. A Container
MAY contain more than one Device entity; each Device entity MAY MAY contain more than one Device entity; each Device entity MAY
contain more than one Key entity. contain more than one Key entity.
The KeyContainer is defined as follows: The KeyContainer is defined as follows:
<xs:complexType name="KeyContainerType"> <xs:complexType name="KeyContainerType">
<xs:sequence> <xs:sequence>
<xs:element name="EncryptionKey" <xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/> type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACAlgorithm" <xs:element name="MACAlgorithm"
type="pskc:KeyAlgorithmType" minOccurs="0"/> type="pskc:KeyAlgorithmType" minOccurs="0"/>
<xs:element name="KeyProperties"
type="pskc:KeyPropertiesType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Device" <xs:element name="Device"
type="pskc:DeviceType" maxOccurs="unbounded"/> type="pskc:DeviceType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="Signature" <xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/> type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" type="pskc:VersionType" use="required"/> <xs:attribute name="Version" type="pskc:VersionType"
use="required"/>
<xs:attribute name="ID" type="xs:ID"
use="optional"/>
</xs:complexType> </xs:complexType>
The attributes of the KeyContainer have the following meanings:
o Version (MANDATORY), the version number for the portable key
container format (the XML schema defined in this document).
o ID (OPTIONAL), the unique ID for this container in case an XML
document contains more than one container and wants to refer to
them uniquely.
The elements of the KeyContainer have the following meanings: The elements of the KeyContainer have the following meanings:
o <EncryptionKey (OPTIONAL)>, Identifies the encryption key, o <EncryptionKey> (OPTIONAL), Identifies the 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 the Secret Key data values when generate a keyed digest of the Secret Key data values when
protection algorithms are used that do not have integrity checks. protection algorithms are used that do not have integrity checks.
The digest guarantees the integrity and the authenticity of the The digest guarantees the integrity and the authenticity of the
key data. for profile and usage please see Section 6.1.1 key data. for profile and usage please see Section 6.1.1
o <Device>, the host Device for one or more Keys as defined in o <KeyProperties> (OPTIONAL), key property entities containing key
Section 5.2 The KeyContainer MAY contain multiple Device data related properties that are common for keys within this container.
elements, allowing for bulk provisioning of multiple devices each Please see Section 5.2 for detailed description of this
containing multiple keys. element.The KeyContainer MAY contain multiple KeyProperties
elements each containing a set of properties related to one or
more keys transported within the container.
o <Signature (OPTIONAL)>, the signature value of the Container. o <Device> (MANDATORY), the host Device for one or more Keys as
defined in Section 5.3 The KeyContainer MAY contain multiple
Device data elements, allowing for bulk provisioning of multiple
devices each containing multiple keys.
o <Signature> (OPTIONAL), the signature value of the Container.
When the signature is applied to the entire container, it MUST use When the signature is applied to the entire container, it MUST use
XML Signature methods as defined in [XMLDSIG]. It MAY be omitted XML Signature methods as defined in [XMLDSIG]. It MAY be omitted
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 <Version (MANDATORY)>, the version number for the portable key o <Extensions> (OPTIONAL), is the extension point for this entity.
container format (the XML schema defined in this document). All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
5.2. Device <Extensions>
<MyExtension1
definition="http://ACME/MyExtension1.html">blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</Extensions>
The Device represents the Device entity in the Container. A Device 5.2. KeyProperties
MAY be bound to a user and MAY contain more than one keys. A key
SHOULD be bound to only one Device. The KeyProperties represents common properties shared by more than
one key held in the container. If a value is set in the properties
the Key element can refer to it via ID attribute. Values that are
present in the Key element itself MUST take precedence over values
set in KeyProperties. The KeyProperties is defined as follows:
<xs:complexType name="KeyPropertiesType">
<xs:sequence>
<xs:element name="Issuer" type="xs:string"
minOccurs="0"/>
<xs:element name="Usage" type="pskc:UsageType"
minOccurs="0"/>
<xs:element name="KeyProfileId" type="xs:string"
minOccurs="0"/>
<xs:element name="MasterKeyId" type="xs:string"
minOccurs="0"/>
<xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID"
use="required"/>
<xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
The attributes of the KeyProperties entity have the following
meanings:
o ID (MANDATORY), a unique and global identifier of set of
KeyProperties. The identifier is defined as a string of
alphanumeric characters.
o KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm
to use with a secret key for the profiles described in Section 6.3
Since KeyProperties are a method to group element values that are
common to multiple keys transported, please refer to Section 5.4 for
detailed description of all elements.
5.3. Device
The Device represents an extensible Device entity in the Container.
A Device MAY be bound to a user and MAY contain more than one key. A
key SHOULD be bound to only one Device.
The Device is defined as follows: The Device is defined as follows:
<xs:complexType name="DeviceType"> <xs:complexType name="DeviceType">
<xs:sequence> <xs:sequence>
<xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/> <xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
<xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/> minOccurs="0"/>
<xs:element name="UserId" type="xs:string" minOccurs="0"/> <xs:element name="Key" type="pskc:KeyType"
maxOccurs="unbounded"/>
<xs:element name="User" type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
The elements of the Device have the following meanings: The elements of the Device have the following meanings:
o <DeviceId>, a unique identifier for the device, defined in o <DeviceInfo> (OPTIONAL), a set of elements containing information
Section 5.2.1 about the device, whose values uniquely identify the device,
defined in Section 5.3.1
o <Key>, represents the key entity as defined in Section 5.4 o <Key> (MANDATORY), represents the key entity as defined in
Section 5.4
o <UserId>, optionally identifies the owner or the user of the o <User> (OPTIONAL), identifies the owner or the user of the Device,
Device, a string representation of a Distinguished Name as defined a string representation of a Distinguished Name as defined in
in [RFC4514]. For example UID=jsmith,DC=example,DC=net. In [RFC4514]. For example UID=jsmith,DC=example,DC=net. In systems
systems where unique user Ids are used the string representation where unique user Ids are used the string representation
'UID=[uniqueId]' MUST be used. 'UID=[uniqueId]' SHOULD be used.
5.2.1. DeviceId o <Extensions> (OPTIONAL), is the extension point for this entity.
All extensions are grouped under this element and will be of type
pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
The DeviceId represents the identifying criteria to uniquely identify <Extensions>
the device that contains the associated keys. Since devices can come <MyExtension1
in different form factors such as hardware tokens, smart-cards, soft definition="http://ACME/MyExtension1.html">blah</Myextension1>
tokens in a mobile phone or PC etc this element allows different <YourExtension99>blahblah</YourExtension99>
criteria to be used. Combined though the criteria MUST uniquely </Extensions>
identify the device. For example for hardware tokens the combination
of SerialNo and Manufacturer will uniquely identify a device but not 5.3.1. DeviceInfo
SerialNo alone since two different token manufacturers might issue
devices with the same serial number (similar to the IssuerDN and The DeviceInfo represents an extensible set of elements that form the
serial number of a certificate). Symmetric Keys used in the payment identifying criteria to uniquely identify the device that contains
industry are usually stored on Integrated Circuit Smart Cards. These the associated keys. Since devices can come in different form
cards are uniquely identified via the Primary Account Number (PAN, factors such as hardware tokens, smart-cards, soft tokens in a mobile
the long number printed on the front of the card) and an expiry date phone or PC etc this element allows different criteria to be used.
of the card. DeviceId is an extensible type that allows all these Combined though the criteria MUST uniquely identify the device. For
example for hardware tokens the combination of SerialNo and
Manufacturer will uniquely identify a device but not SerialNo alone
since two different token manufacturers might issue devices with the
same serial number (similar to the IssuerDN and serial number of a
certificate). Symmetric Keys used in the payment industry are
usually stored on Integrated Circuit Smart Cards. These cards are
uniquely identified via the Primary Account Number (PAN, the long
number printed on the front of the card) and an expiry date of the
card. DeviceInfo is an extensible type that allows all these
different ways to uniquely identify a specific key containing device. different ways to uniquely identify a specific key containing device.
The DeviceId is defined as follows: The DeviceInfo is defined as follows:
<xs:complexType name="DeviceIdType"> <xs:complexType name="DeviceInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="Manufacturer" type="xs:string"/> <xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="SerialNo" type="xs:string"/> <xs:element name="SerialNo" type="xs:string"/>
<xs:element name="Model" type="xs:string" minOccurs="0"/> <xs:element name="Model" type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo" type="xs:string" minOccurs="0"/> <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/> <xs:element name="DeviceBinding" type="xs:string" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/> <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
The elements of DeviceId have the following meanings: The elements of DeviceInfo have the following meanings:
o <Manufacturer>, the manufacturer of the device.
o <SerialNo>, the serial number of the device or the PAN (primary
account number) in case of payment smart cards.
o <Model>, the model of the device (e.g one-button-HOTP-token-V1)
o <IssueNo>, the issue number in case of smart cards with the same
PAN, equivalent to a PSN (PAN Sequence Number).
o <ExpiryDate>, the expiry date of a device (such as the one on a o <Manufacturer> (MANDATORY), the manufacturer of the device.
payment card,used when issue numbers are not printed on cards).
o <StartDate>, the start date of a device (such as the one on a o <SerialNo> (MANDATORY), the serial number of the device or the PAN
payment card,used when issue numbers are not printed on cards). (primary account number) in case of payment smart cards.
5.3. KeyProperties o <Model> (OPTIONAL), the model of the device (e.g. one-button-HOTP-
token-V1)
The KeyProperties represents common properties shared by more than o <IssueNo> (OPTIONAL), the issue number in case of smart cards with
one key held in the container. If a value is set in the properties the same PAN, equivalent to a PSN (PAN Sequence Number).
the Key element can refer to it via KeyPropertiesId attribute.
Values that are present in the Key element itself MUST take
precendence over values set in KeyProperties. The KeyProperties is
defined as follows:
<xs:complexType name="KeyPropertiesType"> o <DeviceBinding> (OPTIONAL), the identifier that can be used to
<xs:sequence> bind keys to the device or class of device. When loading keys
<xs:element name="Issuer" type="xs:string" into a device, this identifier can be checked against information
minOccurs="0"/> obtained from the device to ensure that the correct device or
<xs:element name="Usage" type="pskc:UsageType" class of device is being used.
minOccurs="0"/>
<xs:element name="KeyProfileId" type="xs:string"
minOccurs="0"/>
<xs:element name="MasterKeyId" type="xs:string"
minOccurs="0"/>
<xs:element name="Data" type="pskc:DataType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="KeyPropertiesId" type="xs:string"
use="required"/>
<xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
The attributes of the KeyProperties entity have the following o <StartDate> (OPTIONAL), the start date of a device (such as the
meanings: one on a payment card, used when issue numbers are not printed on
cards). MUST be expressed in UTC form, with no time zone
component. Implementations SHOULD NOT rely on time resolution
finer than milliseconds and MUST NOT generate time instants that
specify leap seconds.
o KeyPropertiesId (MANDATORY), a unique and global identifier of set o <ExpiryDate> (OPTIONAL), the expiry date of a device (such as the
of KeyProperties. The identifier is defined as a string of one on a payment card, used when issue numbers are not printed on
alphanumeric characters. cards). MUST be expressed in UTC form, with no time zone
component. Implementations SHOULD NOT rely on time resolution
finer than milliseconds and MUST NOT generate time instants that
specify leap seconds.
o <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm o <Extensions> (OPTIONAL), is the extension point for this entity.
to use with the secret key, for profiles are described in All extensions are grouped under this element and will be of type
Section 6.3 pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
Since KeyProperties are a method to commonalise the elements in Key <Extensions>
please refer to section Section 5.4 for detailed description of all <MyExtension1
elements. definition="http://ACME/MyExtension1.html">blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</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"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Usage" type="pskc:UsageType" <xs:element name="Usage" type="pskc:UsageType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="KeyProfileId" type="xs:string" <xs:element name="KeyProfileId" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="MasterKeyId" type="xs:string" <xs:element name="MasterKeyId" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="FriendlyName" type="xs:string" <xs:element name="FriendlyName" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Data" type="pskc:DataType" <xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="1"/>
<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"
minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" <xs:element name="ExpiryDate" type="xs:dateTime"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" <xs:element name="UserId" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="KeyId" type="xs:string" <xs:attribute name="KeyId" type="xs:string"
use="required"/> use="required"/>
<xs:attribute name="KeyAlgorithm" <xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" use="optional"/> type="pskc:KeyAlgorithmType" use="optional"/>
<xs:attribute name="KeyPropertiesId" type="xs:string" <xs:attribute name="KeyProperties" type="xs:IDREF"
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. characters. This identifier SHOULD be valid globally and outside
of the instance document of the container.
o <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm o KeyAlgorithm (OPTIONAL), 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 <KeyPropertiesId (OPTIONAL)>, the unique id of the KeyProperties o KeyProperties (OPTIONAL), the references to the unique id of the
whose value the instance of this key inherits. If this value is KeyProperties whose value the instance of this key inherits. If
set implementation MUST lookup the Keyproperties element referred this value is set implementation MUST lookup the Keyproperties
to by this unique Id and this instance of key will inherit all element referred to by this unique Id and this instance of key
values from the KeyProperties. Values held in the key instance it will inherit all values from the KeyProperties. Values held in
MUST take precedence over values inherited from KeyProperties."/> the key instance MUST take precedence over values inherited from
KeyProperties."/>
The elements of the Key entity have the following meanings: The elements of the Key entity have the following meanings:
o <Issuer (OPTIONAL)>, The key issuer name, this is normally the o <Issuer> (OPTIONAL), The key issuer name, this is normally the
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 (MANDATORY)>, 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 constant values related to a key that are not transmitted via the
container. For example a smart card application personalisation container. For example a smart card application personalisation
profile id related to attributes present on a smart card profile id related to attributes present on a smart card
application that have influence when computing a response. An application that have influence when computing a response. An
example could be an EMV MasterCard CAP [CAP] application on a card example could be an EMV MasterCard CAP [CAP] application on a card
personalised with data for a specific batch of cards such as: personalised with data for a specific batch of cards such as:
IAF Internet authentication flag IAF Internet authentication flag
skipping to change at page 19, line 41 skipping to change at page 22, line 4
CVR The card verification result CVR The card verification result
AmountOther AmountOther
TransactionDate TransactionDate
TerminalCountryCode TerminalCountryCode
TransactionCurrencyCode TransactionCurrencyCode
AmountAuthorised AmountAuthorised
IIPB IIPB
These values are not contained within attributes in the container These values are not contained within attributes in the container
but are shared between the manufacturing and the validation but are shared between the manufacturing and the validation
service through this unique KeyProfileId. The KeyProfileId is service through this unique KeyProfileId. The KeyProfileId is
defined as a String. defined as a String.
o <MasterKeyId (OPTIONAL)>, The unique reference to a master key o <MasterKeyId> (OPTIONAL), The unique reference to an external
when key derivation schemes are used and no specific key is master key when key derivation schemes are used and no specific
transported but only the reference to the master key used to key is transported but only the reference to the master key used
derive a specific key and some derivation data. to derive a specific key and some derivation data (e.g. the
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.
o <Data (OPTIONAL)>, the element carrying the data related to the o <Data> (OPTIONAL), the element carrying the data related to the
key as defined in Section 5.4.1 key as defined in Section 5.4.1
o <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the o <PINPolicy> (OPTIONAL), the policy of the PIN relating to the
usage of this key as defined in Section 5.4.4 usage of this key as defined in Section 5.4.4
o <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not o <StartDate> (OPTIONAL), the start date of the key, it MUST not be
be possible to use this key after this date possible to use this key before this date. MUST be expressed in
UTC form, with no time zone component. Implementations SHOULD NOT
rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds.
o <StartDate (OPTIONAL)>, the start date of the key, it MUST not be o <ExpiryDate> (OPTIONAL), the expiry date of the key, it MUST not
possible to use this key before this date be possible to use this key after this date. MUST be expressed in
UTC form, with no time zone component. Implementations SHOULD NOT
rely on time resolution finer than milliseconds and MUST NOT
generate time instants that specify leap seconds.
5.4.1. Data (OPTIONAL) 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
representation of a Distinguished Name as defined in [RFC4514].
For example "UID=jsmith,DC=example,DC=net". In systems where
unique user Ids are used the string representation
'UID=[uniqueId]' SHOULD be used.
Defines the data attributes of the symmetric key. Each is a name o <Extensions> (OPTIONAL), is the extension point for this entity.
value pair which has either a plain value (in case of no encryption) All extensions are grouped under this element and will be of type
or a encrypted value as defined in EncryptedDataType in XML pskc:ExtensionType, which contains an optional attribute
Encryption. 'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
This is also where the key value is transported, Section 7 defines a <Extensions>
list of reserved attribute names. <MyExtension1
definition="http://ACME/MyExtension1.html">blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</Extensions>
Data element is defined as follows: 5.4.1. KeyData
<xs:complexType name="DataType"> Defines an extensible set of data elements relating to a key
including the key value itself (secret). After considerable
discussions in forums and at IETF the authors needed a mean to convey
data related to a key in an extensible form. The requirements were
that the data elements could be encrypted but not via XML encryption
which was deemed to complex because of canonicalization. Hence
earlier drafts made use of a list of name value pairs. This was not
considered to be very XML like and also lacked inbuilt support for
typing. Hence the current apporach is to have within KeyData a set
of elements that have both typing and can be encrypted.
All elements within Data hence obey a simple structure in that they
MUST have:
a choice between:
A <PlainValue> element that is typed to the specific type (e.g.
xs:integer)
An <EncryptedValue> element that is of type xenc:EncryptedDataType
where the value of the specific element is placed in case it is
encrypted
an optional <ValueMac> element that is populated with a MAC in case
the encryption algorithm does not support integrity checks
For example the pskc:intDataType is defined as follows:
<xs:complexType name="intDataType">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:choice>
<xs:element name="PlainValue" type="xs:base64Binary"/> <xs:element name="PlainValue"
<xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/> type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice> </xs:choice>
<xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/> <xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Name" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
The attributes of the Data element have the following meanings: The following typed base types have been defined within the current
schema of the PSKC spec with the naming convention <type>DataType
(e.g. intDataType) to be able to cater transmission of key data
elements:
pskc:intDataType - to carry data elements of type integer,
PlainValue sub element is of type xs:integer. When encrypted the
binary value MUST be 4 bytes unsigned integer in big endian (i.e.
network byte order) form
pskc:longDataType - to carry data elements of type long,
PlainValue sub element is of type xs:long. When encrypted the
binary value MUST be 8 bytes unsigned integer in big endian (i.e.
network byte order) form
pskc:binaryDataType - to carry data elements of type binary,
PlainValue sub element is of type xs:Base64Binary
pskc:stringDataType - to carry data elements of type string,
PlainValue sub element is of type xs:string. When encrypted the
binary value MUST UTF-8 encoded string in binary form
Therefore the KeyData element is defined as follows and contains sub
ements to convey the values required by algorithms considered during
the definition of this specification:
<xs:complexType name="KeyDataType">
<xs:sequence>
<xs:element name="Secret" type="pskc:binaryDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Counter" type="pskc:longDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Time" type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="TimeInterval" type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="TimeDrift" type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
o Name, defines the name of the name-value pair, Section 7 defines a
list of reserved attribute names
The elements of the Data element have the following meanings: The elements of the Data element have the following meanings:
o The <PlainValue> conveys an unencrypted value of the name-value o <Secret> (OPTIONAL), the value of the key itself in binary.
pair in base 64 encoding.
o The <EncryptedValue> element in the DataType conveys an encrypted o <Counter> (OPTIONAL), the event counter for event based OTP
value of the name-value pair inside an EncryptedDataType as algorithms.
defined in XML Encryption.
o The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed o <Time> (OPTIONAL), the time for time based OTP algorithms. (If
MAC value of the unencrypted data for the cases where the time interval is used, this element carries the number of time
algorithm to protect key data in transit, as described in section intervals passed from a specific start point, normally algorithm
Section 6.1.1 ,does not support integrity checks. dependent)
5.4.2. Usage (MANDATORY) o <TimeInterval> (OPTIONAL), the time interval value for time based
OTP algorithms.
o <TimeDrift> (OPTIONAL), the device clock drift value for time
based OTP algorithms. The value indicates number of seconds that
the device clock may drift each day.
o <xs:any ..> the extension point for carrying future elements.
Please note that all elements added MUST carry PlainValue and
EncryptedValue sub eleemnts as described above.
5.4.2. Usage
The Usage element defines the usage attribute(s) of the key entity. The Usage element defines the usage attribute(s) of the key entity.
Usage is defined as follows: Usage is defined as follows:
<xs:complexType name="UsageType"> <xs:complexType name="UsageType">
<xs:sequence> <xs:sequence>
<xs:element name="ChallengeFormat" minOccurs="0"> <xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" <xs:attribute name="Format"
type="pskc:ValueFormatType" type="pskc:ValueFormatType"
skipping to change at page 22, line 31 skipping to change at page 26, line 31
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" <xs:attribute name="Format"
type="pskc:ValueFormatType" type="pskc:ValueFormatType"
use="required"/> use="required"/>
<xs:attribute name="Length" <xs:attribute name="Length"
type="xs:unsignedInt" use="required"/> type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits" <xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/> type="xs:boolean" default="false"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="OTP" type="xs:boolean" <xs:attribute name="OTP" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="CR" type="xs:boolean" <xs:attribute name="CR" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Integrity" type="xs:boolean" <xs:attribute name="Integrity" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Encrypt" type="xs:boolean" <xs:attribute name="Encrypt" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Unlock" type="xs:boolean" <xs:attribute name="Unlock" type="xs:boolean"
default="false"/> default="false"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
The attributes of the Usage element define the intended usage of the The attributes of the Usage element define the intended usage of the
key and are a combination of one or more of the following (set to key. This list of attributes is extensible for future needs. They
true): are a combination of one or more of the following (set to true):
o OTP, the key will be used for OTP generation o OTP, the key will be used for OTP generation
o CR, the key will be used for Challenge/Response purposes o CR, the key will be used for Challenge/Response purposes
o Encrypt, the key will be used for data encryption purposes o Encrypt, the key will be used for data encryption purposes
o Integrity, the key will be used to generate a keyed message digest o Integrity, the key will be used to generate a keyed message digest
for data integrity or authentication purposes. for data integrity or authentication purposes.
o Unlock, the key will be used for an inverse challenge response in o Unlock, the key will be used for an inverse challenge response in
the case a user has locked the device by entering a wrong PIN too the case a user has locked the device by entering a wrong PIN too
many times (for devices with PIN-input capability) many times (for devices with PIN-input capability)
5.4.2.1. OTP and CR specific Usage elements (OPTIONAL) The <Extensions> (OPTIONAL) element, is the extension point for the
Usage entity. All extensions are grouped under this element and will
be of type pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
<Extensions>
<MyExtension1
definition="http://ACME/MyExtension1.html">blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</Extensions>
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 to required by the underlying algorithm. These elements also allow
customize or configure the result of the computation (e.g. format, customizing or configuring the result of the computation (e.g.
length). format, length).
5.4.2.1.1. ChallengeFormat element (MANDATORY) 5.4.2.1.1. ChallengeFormat element (OPTIONAL)
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) o Format (MANDATORY), defines the format of the challenge accepted
by the device and MUST be one of the values defined in
Defines the format of the challenge accepted by the device and Section 5.4.3
MUST be one of the values defined in Section 5.4.3
o CheckDigit (OPTIONAL)
Defines if the device needs to check the appended Luhn check o CheckDigit (OPTIONAL), defines if the device needs to check the
digit contained in a provided challenge. This is only valid if appended Luhn check digit contained in a provided challenge. This
the Format attribute is 'DECIMAL'. Value MUST be: is only valid if the Format attribute is '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) o Min (MANDATORY), defines the minimum size of the challenge
accepted by the device for CR mode. If the Format attribute is
Defines the minimum size of the challenge accepted by the 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
device for CR mode. the minimum number of digits/characters. If the Format attribute
is 'BASE64' or 'BINARY', this value indicates the minimum number
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or of bytes of the unencoded value. Value MUST be Unsigned integer.
'ALPHANUMERIC' this value indicates the minimum number of
digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the minimum number of bytes of the unencoded value.
Value MUST be:
Unsigned integer.
o Max (MANDATORY)
Defines the maximum size of the challenge accepted by the
device for CR mode.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the maximum number of
digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the maximum number of bytes of the unencoded value.
Value MUST be:
Unsigned integer. o Max (MANDATORY), defines the maximum size of the challenge
accepted by the device for CR mode. If the Format attribute is
'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
the maximum number of digits/characters. If the Format attribute
is 'BASE64' or 'BINARY', this value indicates the maximum number
of bytes of the unencoded value. Value MUST be Unsigned integer.
5.4.2.1.2. ResponseFormat element (MANDATORY) 5.4.2.1.2. ResponseFormat element (MANDATORY)
The ResponseFormat element defines the characteristics of the result The ResponseFormat element defines the characteristics of the result
of a computation. This defines the format of the OTP or of the of a computation. This defines the format of the OTP or of the
response to a challenge. The Response attribute is defined by the response to a challenge. For cases where the key is a PIN value,
following attributes: 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
o Format (MANDATORY) the following attributes:
Defines the format of the response generated by the device and o Format (MANDATORY), defines the format of the response generated
MUST be one of the values defined in Section 5.4.3 by the device and MUST be one of the values defined in
Section 5.4.3
o CheckDigit (OPTIONAL) o CheckDigit (OPTIONAL), defines if the device needs to append a
Defines if the device needs to append a Luhn check digit to the Luhn check digit to the response. This is only valid if the
response. This is only valid if the Format attribute is Format attribute is 'DECIMAL'. Value MUST be:
'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) o Length (MANDATORY), defines the length of the response generated
by the device. If the Format attribute is 'DECIMAL',
Defines the length of the response generated by the device. 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or 'BINARY', this value indicates the number of bytes of the
'ALPHANUMERIC' this value indicates the number of digits/ unencoded value. Value MUST be Unsigned integer.
characters.
If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value.
Value MUST be:
Unsigned integer.
5.4.3. ValueFormat 5.4.3. ValueFormat
The ValueFormat element defines allowed formats for challenges or The ValueFormat element defines allowed formats for challenges or
responses in OTP algorithms. responses in OTP algorithms.
ValueFormat is defined as follows: ValueFormat is defined as follows:
<simpleType name="ValueFormat"> <simpleType name="ValueFormat">
<restriction base="string"> <restriction base="string">
<enumeration value="DECIMAL"/> <enumeration value="DECIMAL"/>
<enumeration value="HEXADECIMAL"/> <enumeration value="HEXADECIMAL"/>
<enumeration value="ALPHANUMERIC"/> <enumeration value="ALPHANUMERIC"/>
<enumeration value="BASE64"/> <enumeration value="BASE64"/>
<enumeration value="BINARY"/> <enumeration value="BINARY"/>
</restriction> </restriction>
</simpleType> </simpleType>
DECIMAL Only numerical digits
HEXADECIMAL Hexadecimal response DECIMAL, Only numerical digits
ALPHANUMERIC All letters and numbers (case sensitive) HEXADECIMAL, Hexadecimal response
BASE64 Base 64 encoded ALPHANUMERIC, All letters and numbers (case sensitive)
BINARY Binary data, this is mainly used in case of connected BASE64, Base 64 encoded
BINARY, Binary data, this is mainly used in case of connected
devices devices
5.4.4. PINPolicy 5.4.4. PINPolicy
The PINPolicy element provides a mean to define how the usage of a The PINPolicy element provides an extensible mean to define how the
specific key is protected by a PIN. The PIN itself can be usage of a specific key is protected by a PIN. The PIN itself can be
transmitted as a key using the container. transmitted as a key using the container.
If the PINPolicy element is present in the Key element then the key If the PINPolicy element is present in the Key element then the key
is protected with a PIN as defined within the PINPolicy element. is protected with a PIN as defined within the PINPolicy element. The
PINPolicy element also has an extension point defined as xs:any to
allow future extensibility
PINPolicy is defined as follows: PINPolicy is defined as follows:
<xs:complexType name="PINPolicyType"> <xs:complexType name="PINPolicyType">
<xs:sequence> <xs:sequence>
<xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/> <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
<xs:element name="WrongPINtry" type="xs:unsignedInt" <xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="MinLength"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="MaxLength"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="Format"
type="pskc:ValueFormatType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="PINKeyId" type="xs:string" use="required"/> <xs:attribute name="PINKeyId" type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
The attributes of PINPolicy have the following meaning The attributes of PINPolicy have the following meaning
o PINKeyId, the unique key Id within this container that contains o PINKeyId (OPTIONAL), the unique key Id of the key held within this
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 <WrongPINtry (OPTIONAL)>, the number of times the PIN can be o <MaxFailedAttempts> (OPTIONAL), the maximum number of times the
entered wrongly before it MUST not be possible to use the key PIN can be entered wrongly before it MUST not be possible to use
anymore the key anymore
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
shorter than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the
unencoded value.
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
longer than this value. If the Format element is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
digits/characters. If the Format attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the
unencoded value.
o <Format> (OPTIONAL), defines the format of the PIN and MUST be one
of the values defined in Section 5.4.3
o <Extensions> (OPTIONAL) element, is the extension point for the
entity. All extensions are grouped under this element and will be
of type pskc:ExtensionType, which contains an optional attribute
'defintion' that can have a URI pointing at the defintion of the
extension. In this way groups of extension can be bundled under a
subelement. For example:
<Extensions>
<MyExtension1
definition="http://ACME/MyExtension1.html">blah</Myextension1>
<YourExtension99>blahblah</YourExtension99>
</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 key. The PINUsageMode element also has an extension point defined as
xs:any to allow future extensibility
PINUsageMode is defined as follows: PINUsageMode is defined as follows:
<xs:complexType name="PINUsageModeType"> <xs:complexType name="PINUsageModeType">
<xs:choice maxOccurs="unbounded"> <xs:choice maxOccurs="unbounded">
<xs:element name="Local"/> <xs:element name="Local"/>
<xs:element name="Prepend"/> <xs:element name="Prepend"/>
<xs:element name="InAlgo"/> <xs:element name="Append"/>
<xs:element name="Algorithmic"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
The elements of PINPolicy have the following meaning The elements of PINPolicy have the following meaning
o <Local>, the PIN is checked locally on the device before allowing o <Local>, the PIN is checked locally on the device before allowing
the key to be used in executing the algorithm the key to be used in executing the algorithm
o <Prepend>, the PIN is prepended to the OTP or response hance it o <Prepend>, the PIN is prepended to the OTP or response hence it
MUST be chacked by the validation server MUST be checked by the validation server
o <InAlgo>, the PIN is used as part of the algorithm computation o <Append>, the PIN is appended to the OTP or response hence it MUST
be checked by the validation server
o <Algorithmic>, the PIN is used as part of the algorithm
computation
6. Usage and profile of algorithms for the portable symmetric key 6. Usage and profile of algorithms for the portable symmetric key
container container
This section details the use of the XML encryption and XML signature This section details the use of the XML encryption and XML signature
elements to protect the keys transported in the cotainer. It also elements to protect the keys transported in the container. It also
profiles the number of algorithms supported by XML encryption and XML profiles the number of algorithms supported by XML encryption and XML
signature to a mandatory subset for interoperability. signature to a mandatory subset for interoperability.
When no algorithm is provided the values within the container are When no algorithm is provided the values within the container are
unencrypted, implementations SHALL ensure the privacy of the key data unencrypted, implementations SHALL ensure the privacy of the key data
through other standard mechanisms e.g. transport level encryption. through other standard mechanisms e.g. transport level encryption.
6.1. Usage of EncryptionKey to protect keys in transit 6.1. Usage of EncryptionKey to protect keys in transit
The EncryptionKey element in the KeyContainer defines the key, The EncryptionKey element in the KeyContainer defines the key,
skipping to change at page 28, line 37 skipping to change at page 33, line 37
The following sections define specifically the different supported The following sections define specifically the different supported
means to protect the keys: means to protect the keys:
6.1.1. Protecting keys using a pre-shared key via symmetric algorithms 6.1.1. Protecting keys using a pre-shared key via symmetric algorithms
When protecting the payload with pre-shared keys implementations When protecting the payload with pre-shared keys implementations
SHOULD set the name of the specific pre-shared key in the KeyName SHOULD set the name of the specific pre-shared key in the KeyName
element of the EncryptionKey of the KeyContainer. For example: element of the EncryptionKey of the KeyContainer. For example:
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container: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>
.... ....
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
skipping to change at page 29, line 35 skipping to change at page 34, line 35
MUST be set in the MACAlgorithm element in the key container entity MUST be set in the MACAlgorithm element in the key container entity
as defined in Section 5.1. Implementations of PSKC MUST support the as defined in Section 5.1. Implementations of PSKC MUST support the
MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be
one of the following: 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
For example: For example:
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container: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 encryption keys
skipping to change at page 30, line 41 skipping to change at page 35, line 41
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 <KeyDerivationMethod>: URI of the algorithms used to derive the
key e.g. key e.g.
(http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2) (http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)
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
o <CarriedKeyName (OPTIONAL)>: friendly name of the key o <CarriedKeyName> (OPTIONAL): friendly name of the key
When using the PKCS5 PBE algorithm When using the PKCS5 PBE algorithm
(URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2) (URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
and related parameters, the DerivedKey element MUST be used within and related parameters, the DerivedKey element MUST be used within
the EncryptionKey element of the KeyContainer in exactly the form as the EncryptionKey element of the KeyContainer in exactly the form as
shown below: 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:container: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> <EncryptionKey>
<DerivedKey Id="#Passphrase1"> <DerivedKey Id="#Passphrase1">
<CarriedKeyName>Passphrase1</CarriedKeyName> <CarriedKeyName>Passphrase1</CarriedKeyName>
<KeyDerivationMethod <KeyDerivationMethod
skipping to change at page 32, line 8 skipping to change at page 37, line 8
o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY
o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL
For example: For example:
<?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:container: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:DeviceId> <pskc:DeviceInfo>
<pskc:Manufacturer>ACME</pskc:Manufacturer> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceId> </pskc:DeviceInfo>
<pskc:Key KeyAlgorithm= <pskc:Key KeyAlgorithm=
"http://www.ietf.org/keyprov/pskc#hotp" "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" <pskc:ResponseFormat Length="8"
Format="DECIMAL"/> Format="DECIMAL"/>
</pskc:Usage> </pskc:Usage>
<pskc:Data Name="COUNTER"> <pskc:Data>
<pskc:PlainValue>AprkuA==</pskc:PlainValue> <pskc:Secret>
</pskc:Data>
<pskc:Data Name="SECRET">
<pskc:EncryptedValue Id="ED"> <pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod <xenc:EncryptionMethod Algorithm=
Algorithm=
"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<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:Counter>
<PlainValue>0</PlainValue>
</pskc:Counter>
</pskc:Data> </pskc:Data>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</pskc:KeyContainer> </pskc:KeyContainer>
6.3. Profile of Key Algorithm 6.3. Profile of Key Algorithm
This section profiles the type(s) of algorithm of that can be used by This section profiles the type(s) of algorithm of that can be used by
the key(s) transported in the container. The following algorithm the key(s) transported in the container. The following algorithm
URIs are among the default support list. URIs are among the default support list.
skipping to change at page 33, line 20 skipping to change at page 38, line 20
o http://www.w3.org/2001/04/xmlenc#aes256-cbc o http://www.w3.org/2001/04/xmlenc#aes256-cbc
o http://www.ietf.org/keyprov/pskc#hotp o http://www.ietf.org/keyprov/pskc#hotp
o http://www.ietf.org/keyprov/pskc#pin o http://www.ietf.org/keyprov/pskc#pin
6.3.1. OTP Key Algorithm Identifiers 6.3.1. OTP Key Algorithm Identifiers
OTP key algorithm URIs have not been defined in a commonly available OTP key algorithm URIs have not been defined in a commonly available
standard specification. This document defines the following URIs for standard specification. This document requests from IANA the
the standard OTP algorithms defined in [HOTP]. creation of a registry (see Section 8.4) and defines URIs for the
standard OTP algorithms in Section 8.4.4.
6.3.1.1. HOTP
Standard document: RFC4226
Identifier: http://www.ietf.org/keyprov/pskc#hotp
Note that the actual URL will be finalized once a URL for this
document is determined.
6.3.1.2. Other OTP Algorithms
An implementation should refer to vendor registered OTP key algorithm
URIs for other existing OTP algorithms, for example, the RSA SecurID
OTP algorithm as follows.
o http://www.rsa.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES
6.3.2. PIN key value compare algorithm identifier 6.3.2. PIN key value compare algorithm identifier
PIN key algorithm URIs have not been defined in a commonly available PIN key algorithm URIs have not been defined in a commonly available
standard specification. This document defines the following URIs for standard specification. This document defines the following URIs for
a straight value comaprison of the transported secret key data as a straight value comparison of the transported secret key data as
when required to compare a PIN. when required to compare a PIN.
Identifier: http://www.ietf.org/keyprov/pskc#pin Identifier: http://www.ietf.org/keyprov/pskc#pin
Note that the actual URL will be finalized once a URL for this Note that the actual URL will be finalized once a URL for this
document is determined. document is determined.
7. Reserved data attribute names 7. Formal Syntax
The following key data attribute names have been reserved:
SECRET: the shared secret key value in binary, base64 encoded
COUNTER: the event counter for event based OTP algorithms. 8 bytes
unsigned integer in big endian (i.e. network byte order) form
base64 encoded
TIME: the time for time based OTP algorithms. 8 bytes unsigned
integer in big endian (i.e. network byte order) form base64
encoded (Number of seconds since 1970)
TIME_INTERVAL: the time interval value for time based OTP
algorithms. 8 bytes unsigned integer in big endian (i.e. network
byte order) form base64 encoded.
TIME_DRIFT: the device clock drift value for time based OTP
algorithms. The value indicates number of seconds that the device
clock may drift each day. 2 bytes unsigned integer in big endian
(i.e. network byte order) form base64 encoded.
8. Formal Syntax
The following syntax specification uses the widely adopted XML schema The following syntax specification uses the widely adopted XML schema
format as defined by a W3C recommendation format as defined by a W3C recommendation
(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
definition in the XML Schema Definition format (XSD) definition in the XML Schema Definition format (XSD)
All implementations of this standard must comply with the schema All implementations of this standard must comply with the schema
below. below.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container: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#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:container: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/2002/ schemaLocation="http://www.w3.org/TR/
REC-xmlenc-core-20021210/xenc-schema.xsd"/> xmlenc-core/xenc-schema.xsd"/>
<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="Device" type="pskc:DeviceType" <xs:element name="KeyProperties"
type="pskc:KeyPropertiesType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="Device" type="pskc:DeviceType"
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"
type="pskc:ExtensionsType" minOccurs="0"
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" 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"/>
<xs:element name="Usage" <xs:element name="Usage"
type="pskc:UsageType" minOccurs="0"/> type="pskc:UsageType" minOccurs="0"/>
<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"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="Data" type="pskc:DataType" <xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="PINPolicy" <xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/> type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" <xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="KeyPropertiesId" <xs:attribute name="ID"
type="xs:string" use="required"/> type="xs:ID" use="required"/>
<xs:attribute name="KeyAlgorithm" <xs:attribute name="KeyAlgorithm"
type="pskc:KeyAlgorithmType" type="pskc:KeyAlgorithmType"
use="optional"/> use="optional"/>
</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"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName" <xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="Data" type="pskc:DataType" <xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="PINPolicy" <xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/> type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" <xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="UserId" type="xs:string"
minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
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="required"/>
<xs:attribute name="KeyProperties"
type="xs:IDREF" use="optional"/>
</xs:complexType>
<xs:complexType name="KeyDataType">
<xs:sequence>
<xs:element name="Secret"
type="pskc:binaryDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Counter"
type="pskc:longDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Time"
type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="TimeInterval"
type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="TimeDrift"
type="pskc:intDataType"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="binaryDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:base64Binary"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="intDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="stringDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:string"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="longDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:long"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</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 name="Id" type="xs:ID" use="optional"/>
skipping to change at page 37, line 29 skipping to change at page 43, line 20
<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:complexType name="PINPolicyType"> <xs:complexType name="PINPolicyType">
<xs:sequence> <xs:sequence>
<xs:element name="PINUsageMode" <xs:element name="PINUsageMode"
type="pskc:PINUsageModeType"/> type="pskc:PINUsageModeType"/>
<xs:element name="WrongPINtry" type="xs:unsignedInt" <xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="MinLength"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="MaxLength"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="Format"
type="pskc:ValueFormatType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="PINKeyId" type="xs:string" <xs:attribute name="PINKeyId" type="xs:string"
use="required"/> use="optional"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="PINUsageModeType"> <xs:complexType name="PINUsageModeType">
<xs:choice maxOccurs="unbounded"> <xs:choice maxOccurs="unbounded">
<xs:element name="Local"/> <xs:element name="Local"/>
<xs:element name="Prepend"/> <xs:element name="Prepend"/>
<xs:element name="Embed"/> <xs:element name="Append"/>
<xs:element name="Algorithmic"/>
<xs:any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
<xs:complexType name="DeviceIdType"> <xs:complexType name="DeviceInfoType">
<xs:sequence> <xs:sequence>
<xs:element name="Manufacturer" type="xs:string"/> <xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="SerialNo" type="xs:string"/> <xs:element name="SerialNo" type="xs:string"/>
<xs:element name="Model" type="xs:string" <xs:element name="Model" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="IssueNo" type="xs:string" <xs:element name="IssueNo" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" <xs:element name="DeviceBinding" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" <xs:element name="StartDate" type="xs:dateTime"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="DeviceType"> <xs:complexType name="DeviceType">
<xs:sequence> <xs:sequence>
<xs:element name="DeviceId" type="pskc:DeviceIdType" <xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Key" type="pskc:KeyType" <xs:element name="Key" type="pskc:KeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="UserId" type="xs:string" <xs:element name="User" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="UsageType"> <xs:complexType name="UsageType">
<xs:sequence> <xs:sequence>
<xs:element name="ChallengeFormat" minOccurs="0"> <xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" <xs:attribute name="Format"
type="pskc:ValueFormatType" use="required"/> type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Min" type="xs:unsignedInt" <xs:attribute name="Min" type="xs:unsignedInt"
use="required"/> use="required"/>
skipping to change at page 38, line 42 skipping to change at page 45, line 6
<xs:element name="ResponseFormat"> <xs:element name="ResponseFormat">
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" <xs:attribute name="Format"
type="pskc:ValueFormatType" use="required"/> type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Length" type="xs:unsignedInt" <xs:attribute name="Length" type="xs:unsignedInt"
use="required"/> use="required"/>
<xs:attribute name="CheckDigits" type="xs:boolean" <xs:attribute name="CheckDigits" type="xs:boolean"
default="false"/> default="false"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="OTP" type="xs:boolean" default="false"/> <xs:attribute name="OTP" type="xs:boolean" default="false"/>
<xs:attribute name="CR" type="xs:boolean" default="false"/> <xs:attribute name="CR" type="xs:boolean" default="false"/>
<xs:attribute name="Integrity" type="xs:boolean" <xs:attribute name="Integrity" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Encrypt" type="xs:boolean" <xs:attribute name="Encrypt" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Unlock" type="xs:boolean" <xs:attribute name="Unlock" type="xs:boolean"
default="false"/> default="false"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="DataType"> <xs:complexType name="ExtensionsType">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:any namespace="##other" processContents="lax"
<xs:element name="PlainValue" type="xs:base64Binary"/> maxOccurs="unbounded"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC" type="xs:base64Binary"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Name" type="xs:string" use="required"/> <xs:attribute name="definition" type="xs:anyURI"
use="optional"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="KeyAlgorithmType"> <xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/> <xs:restriction base="xs:anyURI"/>
</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="KeyContainer" type="pskc:KeyContainerType"/> <xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
</xs:schema> </xs:schema>
9. IANA Considerations 8. IANA Considerations
9.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].
MIME media type name: application MIME media type name: application
MIME subtype name: pskc+xml MIME subtype name: pskc+xml
Mandatory parameters: none Mandatory parameters: none
skipping to change at page 41, line 14 skipping to change at page 47, line 14
Personal and email address for further information: Philip Hoyer, Personal and email address for further information: Philip Hoyer,
Philip.Hoyer@actividentity.com Philip.Hoyer@actividentity.com
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: This specification is a work item of the IETF KEYPROV Author: This specification is a work item of the IETF KEYPROV
working group, with mailing list address <keyprov@ietf.org>. working group, with mailing list address <keyprov@ietf.org>.
Change controller: The IESG <iesg@ietf.org> Change controller: The IESG <iesg@ietf.org>
9.2. XML Schema Registration 8.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:container:1.0 URI: urn:ietf:params:xml:ns:keyprov:pskc:1.0
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com). (Philip.Hoyer@actividentity.com).
XML Schema: The XML schema to be registered is contained in XML Schema: The XML schema to be registered is contained in
Section 8. Its first line is Section 7. Its first line is
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
and its last line is and its last line is
</xs:schema> </xs:schema>
9.3. URN Sub-Namespace Registration for 8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:keyprov:container:1.0 urn:ietf:params:xml:ns:keyprov:pskc:1.0
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:container:1.0", per the guidelines in "urn:ietf:params:xml:ns:keyprov:pskc:1.0", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:container:1.0 URI: urn:ietf:params:xml:ns:keyprov:pskc:1.0
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com). (Philip.Hoyer@actividentity.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title> <title>PSKC Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for PSKC</h1> <h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:container:1.0</h2> <h2>urn:ietf:params:xml:ns:keyprov:pskc:1.0</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: [NOTE TO IANA/RFC-EDITOR:
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
9.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 2434 [RFC2434]as follows:
9.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
specifying the canonical identifier to be used for a given algorithm. specifying the canonical identifier to be used for a given algorithm.
If an algorithm has an identifier specified in the registry a If an algorithm has an identifier specified in the registry an
application that is conformant to a protocol specification that application that is conformant to a protocol specification that
specifies use of that registry to define identifiers SHOULD always specifies use of that registry to define identifiers SHOULD always
use that particular form of the identifier when originating data. A use that particular form of the identifier when originating data. A
conformant application MAY accept other identifiers in data that is conformant application MAY accept other identifiers in data that is
received. received.
For the sake of expediency, the initial registry only defines For the sake of expediency, the initial registry only defines
algorithm classes for symmetric algorithms plus cryptographic message algorithm classes for symmetric algorithms plus cryptographic message
digest functions (one-way hash). While the same principles may be digest functions (one-way hash). While the same principles may be
extended to asymmetric algorithms, doing so would require much extended to asymmetric algorithms, doing so would require much
greater consideration of issues such as key length and treatment of greater consideration of issues such as key length and treatment of
parameters, particularly where eliptic curve cryptography algorithms parameters, particularly where elliptic curve cryptography algorithms
are concerned. are concerned.
As part of this registry the IANA will maintain the following As part of this registry the IANA will maintain the following
information: information:
Common Name The name by which the algorithm is generally referred. Common Name The name by which the algorithm is generally referred.
Class The type of algorithm, encryption, Message Authentication Code Class The type of algorithm, encryption, Message Authentication Code
(MAC), One Time Pawword (OTP), Digest, etc. (MAC), One Time Password (OTP), Digest, etc.
Cannonical URI The cannonical URI to be used to identify the Canonical URI The canonical URI to be used to identify the
algorithm. algorithm.
Algorithm Definition A reference to the document in which the Algorithm Definition A reference to the document in which the
algorithm described by the identifier is defined. algorithm described by the identifier is defined.
Identifier Definition A reference to the document in which the use Identifier Definition A reference to the document in which the use
of the identifier to refer to the algorithm is described. This of the identifier to refer to the algorithm is described. This
would ideally be the document in which the algorithm is defined. would ideally be the document in which the algorithm is defined.
In the case where the registrant does not request a particular In the case where the registrant does not request a particular
URI, the IANA will assign it a Uniform Resource Name (URN) that URI, the IANA will assign it a Uniform Resource Name (URN) that
follows RFC 3553 [RFC3553]. follows RFC 3553 [RFC3553].
Note that where a single algorithm has different forms distinguished Note that where a single algorithm has different forms distinguished
by paremeters such as key length, the algorithm class and each by parameters such as key length, the algorithm class and each
combination of algorithm parameters may be considered a distinct combination of algorithm parameters may be considered a distinct
algorithm for the purpose of assigning identifiers. algorithm for the purpose of assigning identifiers.
9.4.2. Registerable Algorithms 8.4.2. Registerable Algorithms
9.4.2.1. Assigned URIs 8.4.2.1. Assigned URIs
If the registrant wishes to have a URI assigned, then a URN of the If the registrant wishes to have a URI assigned, then a URN of the
form form
urn:ietf:params:xml:<class>:<id> urn:ietf:params:xml:<class>:<id>
will be assigned where <class> is the type of the algorithm being will be assigned where <class> is the type of the algorithm being
identified (see below). <id> is a unique id specified by the party identified (see below). <id> is a unique id specified by the party
making the request and will normally be either the common name of the making the request and will normally be either the common name of the
algorithm or an abbreviation thereof. algorithm or an abbreviation thereof.
NOTE: in order for a URN of this type to be assigned, the item being NOTE: in order for a URN of this type to be assigned, the item being
registered MUST have been through the IETF consensus process. registered MUST have been through the IETF consensus process.
Basically, this means that it must be documented in a RFC. Basically, this means that it must be documented in a RFC.
NOTE: Expert Review is sufficient in cases where the request does not NOTE: Expert Review is sufficient in cases where the request does not
require a URN assignment inthe IETF namespace. IETF consensus is not require a URN assignment in the IETF namespace. IETF consensus is
required. not required.
9.4.2.2. Assigned Classes 8.4.2.2. Assigned Classes
Each algorithm MUST belong to an assigned algorithm class. In the Each algorithm MUST belong to an assigned algorithm class. In the
case that additional classes are required these are to be specified case that additional classes are required these are to be specified
by IETF Consensus action. by IETF Consensus action.
The initial assigned classes are: The initial assigned classes are:
Digest A cryptographic Digest algorithm. Digest A cryptographic Digest algorithm.
MAC A Message Authentication Code algorithm. MAC A Message Authentication Code algorithm.
Symmetric A symmetric encryption algorithm. Symmetric A symmetric encryption algorithm.
OTP A one time password (OTP) algorithm. OTP A one time password (OTP) algorithm.
9.4.3. Registration Procedures 8.4.3. Registration Procedures
9.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 2434 [RFC2434].
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
skipping to change at page 45, line 13 skipping to change at page 51, line 13
the notice of the proposers of the registration and the Security Area the notice of the proposers of the registration and the Security Area
Directors. If the proposers are not willing to accept registration Directors. If the proposers are not willing to accept registration
of the existing identifier the IETF Consensus policy is to apply. of the existing identifier the IETF Consensus policy is to apply.
In reviewing a request, the expert should consider whether the In reviewing a request, the expert should consider whether the
algorithm is sufficiently defined to allow successful interoperation. algorithm is sufficiently defined to allow successful interoperation.
In particular the expert should consider whether issues such as key In particular the expert should consider whether issues such as key
sizes and byte order are sufficiently defined to allow for sizes and byte order are sufficiently defined to allow for
interoperation. interoperation.
While the defintion requirement MAY be satisifed by a comprehensive While the definition requirement MAY be satisfed by a comprehensive
specification of the algorithm, disclosure of the algorithm is not specification of the algorithm, disclosure of the algorithm is not
mandatory. mandatory.
9.4.3.2. Canonical URI 8.4.3.2. Canonical URI
Until the IANA requests or implements an automated process for the Until the IANA requests or implements an automated process for the
registration of these elements, any specifications must make that registration of these elements, any specifications must make that
request part of the IANA considerations section of their respective request part of the IANA considerations section of their respective
documents. That request must be in the form of the following documents. That request must be in the form of the following
template: template:
Common Name The name by which the algorithm is generally referred. Common Name The name by which the algorithm is generally referred.
Class The type of algorithm, encryption, Message Authentication Code Class The type of algorithm, encryption, Message Authentication Code
(MAC), One Time Pawword (OTP), Digest, etc. As specified by a (MAC), One Time Password (OTP), Digest, etc. As specified by a
defined algorithm class. defined algorithm class.
URI The cannonical URI to be used to identify the algorithm. URI The canonical URI to be used to identify the algorithm.
Algorithm Definition A reference to the document in which the Algorithm Definition A reference to the document in which the
algorithm described by the identifier is defined. algorithm described by the identifier is defined.
Identifier Definition A reference to the document in which the use Identifier Definition A reference to the document in which the use
of the identifier to refer to the algorithm is described. This of the identifier to refer to the algorithm is described. This
would ideally be the document in which the algorithm is defined. would ideally be the document in which the algorithm is defined.
Registrant Contact A reference to the document in which the use of Registrant Contact A reference to the document in which the use of
the identifier to refer to the algorithm is described. This would the identifier to refer to the algorithm is described. This would
ideally be the document in which the algorithm is defined. ideally be the document in which the algorithm is defined.
9.4.3.3. Alias URI 8.4.3.3. Alias URI
In the case that multiple identifiers have been assigned to the same In the case that multiple identifiers have been assigned to the same
identifiers, additional identifiers MAY be registered as aliases. An identifiers, additional identifiers MAY be registered as aliases. An
entry for an alias contains all the entries for a canonical URI with entry for an alias contains all the entries for a canonical URI with
the addition of a reference to the canonical URI to be used: the addition of a reference to the canonical URI to be used:
Alias for URI The cannonical URI that identifies the algorithm. The Alias for URI The canonical URI that identifies the algorithm. The
URI referenced MUST be a canonical URI. URI referenced MUST be a canonical URI.
In the case of dispute as to which URI is to be considered canonical In the case of dispute as to which URI is to be considered canonical
the matter is to be settled by IESG action. the matter is to be settled by IESG action.
9.4.4. Initial Values 8.4.4. Initial Values
The following initial values are defined. Note that these values are The following initial values are defined. Note that these values are
limited to identifiers that are required by KEYPROV but not specified limited to identifiers that are required by KEYPROV but not specified
elsewhere: elsewhere:
9.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
9.4.4.2. HOTP-HMAC-SHA-1 8.4.4.2. OCRA (OATH Chellenge Response Algorithm)
Common Name: HOTP-HMAC-SHA-1 Common Name: OCRA
Class: OTP Class: OTP
URI: http://www.ietf.org/rfc/rfc4226.txt#HOTP-HMAC-SHA-1 URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)
- e.g.
http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08
Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt Algorithm Definition: http://www.ietf.org/internet-drafts/
draft-mraihi-mutual-oath-hotp-variants-07.txt
Identifier Definition (this RFC) Identifier Definition (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
9.4.4.3. KEYPROV-PIN 8.4.4.3. TOTP (OATH Time based OTP)
Common Name: TOTP
Class: OTP
URI: http://www.ietf.org/keyprov/pskc#totp
Algorithm Definition: http://www.ietf.org/internet-drafts/
draft-mraihi-totp-timebased-00.txt
Identifier Definition (this RFC)
Registrant Contact: IESG
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)
Identifier Definition (this document) Identifier Definition (this document)
Registrant Contact: IESG Registrant Contact: IESG
9.4.4.4. 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>
9.4.4.5. SecurID-ALGOR 8.4.4.6. SecurID-AES-Counter
Common Name: SecurID-AES-Counter
Class: OTP
URI: http://www.rsa.com/names/2008/04/algorithms/
SecurID#SecurID-AES128-Counter
Algorithm Definition: http://www.rsa.com/names/2008/04/algorithms/
SecurID#SecurID-AES128-Counter
Identifier Definition http://www.rsa.com/names/2008/04/algorithms/
SecurID#SecurID-AES128-Counter
Registrant Contact: Andrea Doherty, RSA the Security Division of
EMC, <andrea.doherty@rsa.com>
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>
9.4.4.6. 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
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>
9.4.4.7. 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>
9.4.4.8. 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
skipping to change at page 49, line 4 skipping to change at page 55, line 39
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>
9.4.4.9. 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,
skipping to change at page 49, line 25 skipping to change at page 57, line 5
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>
9.5. XML Data Tag Identifier Registry 9. Security Considerations
This specification requests the creation of a new IANA registry for
XML Data Tag identifiers in accordance with the principles set out in
RFC 2434 [RFC2434]as follows:
[More explanation of why an escape to tag value lists is desirable
when inserting unstructured data into an XML schema]
9.5.1. Applicability
As part of this registry the IANA will maintain the following
information:
Common Name Common name for by which the tag is referred to
Cannonical URI The cannonical URI to be employed when citing the
tag.
Data Type The data type of the data that is bound to the tag.
Definition A reference to the document in which the data tag
defined by the identifier is defined.
In the case where the registrant does not request a particular URI,
the IANA will assign it a Uniform Resource Name (URN) that follows
RFC 3553 [RFC3553].
9.5.2. Registerable Data Tags
9.5.2.1. Assigned URIs
If the registrant wishes to have a URI assigned, then a URN of the
form
urn:ietf:params:xml:datatag:<tag>
will be assigned where <tag> is a unique id specified by the party
making the request and will normally be either the common name of the
tag or an abbreviation thereof.
NOTE: in order for a URN of this type to be assigned, the item being
registered MUST have been through the IETF consensus process.
Basically, this means that it must be documented in a RFC.
NOTE: Expert Review is sufficient in cases where the request does not
require a URN assignment inthe IETF namespace. IETF consensus is not
required.
9.5.3. Registration Procedures
9.5.3.1. Review
Data tag registrations are to be subject to Expert Review as per RFC
2434 [RFC2434].
9.5.3.2. Data Tag Entry
Until the IANA requests or implements an automated process for the
registration of these elements, any specifications must make that
request part of the IANA considerations section of their respective
documents. That request must be in the form of the following
template:
Common Name Common name for by which the tag is referred to
Cannonical URI The cannonical URI to be employed when citing the
tag.
Data Type The data type of the data that is bound to the tag.
Definition A reference to the document in which the data tag
defined by the identifier is defined.
9.5.4. Initial Values
The following initial values are defined. Note that these values are
limited to identifiers that are required by KEYPROV but not specified
elsewhere:
9.5.4.1. Secret
Common Name Secret
Cannonical URI urn:ietf:params:xml:datatag:secret
Data Type binary, base64 encoded
Defined in (this document)
9.5.4.2. Counter
Common Name Counter
Cannonical URI urn:ietf:params:xml:datatag:counter
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded
Defined in (this document)
9.5.4.3. Time
Common Name Time
Cannonical URI urn:ietf:params:xml:datatag:time
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded (Number of seconds since 1970)
Defined in (this document)
9.5.4.4. Time Interval
Common Name Time Interval
Cannonical URI urn:ietf:params:xml:datatag:time_interval
Data Type 8 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded.
Defined in (this document)
9.5.4.5. Time Drift
Common Name urn:ietf:params:xml:datatag:time_drift
Cannonical URI Time Drift
Data Type 2 bytes unsigned integer in big endian (i.e. network byte
order) form base64 encoded.
Defined in (this document)
10. 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.
10.1. Payload confidentiality 9.1. Payload confidentiality
By design, the container allows two main approaches to guaranteeing By design, the container allows two main approaches to guaranteeing
the confidentiality of the information it contains while transported. the confidentiality of the information it contains while transported.
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
skipping to change at page 54, line 14 skipping to change at page 58, line 14
in this mode. Secure channels that encrypt and digest each message in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature provide an extra measure of security, especially when the signature
of the payload does not encompass the entire payload. of the payload does not encompass the entire payload.
Because of the fact that the plain text payload is protected only by Because of the fact that the plain text payload is protected only by
the transport layer security, practical implementation must ensure the transport layer security, practical implementation must ensure
protection against man-in-the-middle attacks [Schneier]. Validating protection against man-in-the-middle attacks [Schneier]. Validating
the secure channel end-points is critically important for eliminating the secure channel end-points is critically important for eliminating
intruders that may compromise the confidentiality of the payload. intruders that may compromise the confidentiality of the payload.
10.2. Payload integrity 9.2. Payload integrity
The portable symmetric key container provides a mean to guarantee the The portable symmetric key container provides a mean to guarantee the
integrity of the information it contains through digital signatures. integrity of the information it contains through digital signatures.
For best security practices, the digital signature of the container For best security practices, the digital signature of the container
should encompass the entire payload. This provides assurances for should encompass the entire payload. This provides assurances for
the integrity of all attributes. It also allows verification of the the integrity of all attributes. It also allows verification of the
integrity of a given payload even after the container is delivered integrity of a given payload even after the container is delivered
through the communication channel to the target perimeter and channel through the communication channel to the target perimeter and channel
message integrity check is no longer possible. message integrity check is no longer possible.
10.3. Payload authenticity 9.3. Payload authenticity
The digital signature of the payload is the primary way of showing The digital signature of the payload is the primary way of showing
its authenticity. The recipient of the container may use the public its authenticity. The recipient of the container may use the public
key associated with the signature to assert the authenticity of the key associated with the signature to assert the authenticity of the
sender by tracing it back to a preloaded public key or certificate. sender by tracing it back to a preloaded public key or certificate.
Note that the digital signature of the payload can be checked even Note that the digital signature of the payload can be checked even
after the container has been delivered through the secure channel of after the container has been delivered through the secure channel of
communication. communication.
A weaker payload authenticity guarantee may be provided by the A weaker payload authenticity guarantee may be provided by the
transport layer if it is configured to digest each message it transport layer if it is configured to digest each message it
transports. However, no authenticity verification is possible once transports. However, no authenticity verification is possible once
the container is delivered at the recipient end. This approach may the container is delivered at the recipient end. This approach may
be useful in cases where the digital signature of the container does be useful in cases where the digital signature of the container does
not encompass the entire payload. not encompass the entire payload.
11. Acknowledgements 10. Acknowledgements
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, and Anders Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders
Rundgren. Rundgren, Sean Turner and especially Robert Philpott.
12. 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.
12.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
<?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:container:1.0"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device> <Device>
<DeviceId> <DeviceInfo>
<Manufacturer>ACME</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceId> </DeviceInfo>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266"> KeyId="987654321">
<Issuer>AnIssuer</Issuer> <Issuer>Issuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/> <ResponseFormat Length="8"
Format="DECIMAL"/>
</Usage> </Usage>
<Data Name="COUNTER"> <Data>
<PlainValue>AprkuA==</PlainValue> <Secret>
</Data> <PlainValue>
<Data Name="SECRET"> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue> </PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data> </Data>
<ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
12.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:container:1.0"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<Device> <Device>
<DeviceId> <DeviceInfo>
<Manufacturer>ACME</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>0755225266</SerialNo>
</DeviceId> </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 Name="COUNTER"> <Data>
<PlainValue>AprkuA==</PlainValue> <Secret>
</Data> <PlainValue>
<Data Name="SECRET"> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue> </PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data> </Data>
<PINPolicy PINKeyId="07552252661"> <PINPolicy PINKeyId="07552252661">
<PINUsageMode> <PINUsageMode>
<Local/> <Local/>
</PINUsageMode> </PINUsageMode>
</PINPolicy> </PINPolicy>
</Key> </Key>
<Key KeyId="07552252661" <Key KeyId="07552252661"
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin"> KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
<Usage> <Usage>
<ResponseFormat Length="4" Format="DECIMAL"/> <ResponseFormat Length="4" Format="DECIMAL"/>
</Usage> </Usage>
<Data Name="SECRET"> <Data>
<PlainValue>MTIzNA==</PlainValue> <Secret>
<PlainValue>
MTIzNA==
</PlainValue>
</Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
12.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP 11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
Secret Key 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:container: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>
<DeviceId> <DeviceInfo>
<Manufacturer>ACME</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>0755225266</SerialNo>
</DeviceId> </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 Name="COUNTER"> <Data>
<PlainValue>AprkuA==</PlainValue> <Secret>
</Data>
<Data Name="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#aes256-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE= gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
<ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC> <ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
12.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:container: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 Id="#Passphrase1">
<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName> <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
<pskc:KeyDerivationMethod <pskc:KeyDerivationMethod
skipping to change at page 59, line 30 skipping to change at page 64, line 32
<KeyLength>16</KeyLength> <KeyLength>16</KeyLength>
<PRF/> <PRF/>
</pkcs-5:Parameters> </pkcs-5:Parameters>
</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:DeviceId> <pskc:DeviceInfo>
<pskc:Manufacturer>ACME</pskc:Manufacturer> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceId> </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 Name="COUNTER"> <pskc:Data>
<pskc:PlainValue>AprkuA==</pskc:PlainValue> <pskc:Secret>
</pskc:Data>
<pskc:Data Name="SECRET">
<pskc:EncryptedValue Id="ED"> <pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod Algorithm= <xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#kw-aes128"/> "http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
<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:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</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="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI=""> <ds:Reference URI="">
skipping to change at page 60, line 32 skipping to change at page 65, line 36
<ds:X509IssuerSerial> <ds:X509IssuerSerial>
<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US <ds:X509IssuerName>CN=KeyProvisioning'R'Us.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>
12.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:container: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:DeviceId> <pskc:DeviceInfo>
<pskc:Manufacturer>ACME</pskc:Manufacturer> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo> <pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceId> </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 Name="COUNTER"> <pskc:Data>
<pskc:PlainValue>AprkuA==</pskc:PlainValue> <pskc:Secret>
</pskc:Data>
<pskc:Data Name="SECRET">
<pskc:EncryptedValue Id="ED"> <pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod <xenc:EncryptionMethod Algorithm=
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<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:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data> </pskc:Data>
</pskc:Key> </pskc:Key>
</pskc:Device> </pskc:Device>
</pskc:KeyContainer> </pskc:KeyContainer>
13. References 11.6. Symmetric Key Container with a single AES-256-CBC Encrypted OCRA
Secret Key and non-encrypted counter value
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>
<MACAlgorithm>
http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm>
<Device>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</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>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</Device>
</KeyContainer>
13.1. Normative References 11.7. Symmetric Key Container with a single AES-256-CBC Encrypted TOTP
Secret Key and non-encrypted time values
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm>
<Device>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceInfo>
<Key KeyAlgorithm=
"http://www.ietf.org/keyprov/pskc#totp"
KeyId="0755225266">
<Issuer>AnIssuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
</Secret>
<Time>
<PlainValue>0</PlainValue>
</Time>
<TimeInterval>
<PlainValue>30</PlainValue>
</TimeInterval>
</Data>
</Key>
</Device>
</KeyContainer>
11.8. Symmetric Key Container with two devices containing a Non-
Encrypted HOTP Secret Key each sharing common KeyProperties
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
<KeyProperties ID="KPID1"
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp">
<Issuer>Issuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="8"
Format="DECIMAL"/>
</Usage>
<Data>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</KeyProperties>
<Device>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key KeyProperties="KPID1"
KeyId="987654321">
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
</Data>
</Key>
</Device>
<Device>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654322</SerialNo>
</DeviceInfo>
<Key KeyProperties="KPID1"
KeyId="987654322">
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
</Data>
</Key>
</Device>
</KeyContainer>
12. References
12.1. Normative References
[PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
Specifications Version 2.0.", Specifications Version 2.0.",
URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
October 1998. 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.
skipping to change at page 62, line 48 skipping to change at page 71, line 48
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[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/, December 2002.
13.2. Informative References 12.2. Informative References
[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-03.txt,
February 2008. February 2008.
skipping to change at page 64, line 9 skipping to change at page 73, line 9
[Schneier] [Schneier]
Schneier, B., "Secrets and Lies: Digitial Security in a Schneier, B., "Secrets and Lies: Digitial Security in a
Networked World", Wiley Computer Publishing, ISBN 0-8493- Networked World", Wiley Computer Publishing, ISBN 0-8493-
8253-7, 2000. 8253-7, 2000.
Authors' Addresses Authors' Addresses
Philip Hoyer Philip Hoyer
ActivIdentity, Inc. ActivIdentity, Inc.
109 Borough High Street 117 Waterloo Road
London, SE1 1NL London, SE1 8UL
UK UK
Phone: +44 (0) 20 7744 6455 Phone: +44 (0) 20 7744 6455
Email: Philip.Hoyer@actividentity.com Email: Philip.Hoyer@actividentity.com
Mingliang Pei Mingliang Pei
VeriSign, Inc. VeriSign, Inc.
487 E. Middlefield Road 487 E. Middlefield Road
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
 End of changes. 250 change blocks. 
667 lines changed or deleted 1044 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/