< draft-ietf-keyprov-portable-symmetric-key-container-00.txt   draft-ietf-keyprov-portable-symmetric-key-container-01.txt >
Network Working Group P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: January 2, 2008 VeriSign Expires: March 31, 2008 VeriSign
S. Machani S. Machani
Diversinet Diversinet
S. Chang S. Chang
Gemalto Gemalto
July 2007 September 28, 2007
Portable Symmetric Key Container Portable Symmetric Key Container
draft-ietf-keyprov-portable-symmetric-key-container-00.txt draft-ietf-keyprov-portable-symmetric-key-container-01.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 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2008. This Internet-Draft will expire on March 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 (One Time Password (OTP) shared provisioning of symmetric keys (One Time Password (OTP) shared
secrets or symmetric cryptographic keys) to different types of strong secrets or symmetric cryptographic keys) to different types of strong
authentication devices. The standard token format enables authentication devices. The standard token format enables
enterprises to deploy best-of-breed solutions combining components enterprises to deploy best-of-breed solutions combining components
from different vendors into the same infrastructure. from different vendors into the same infrastructure.
This work is a joint effort by the members of OATH (Initiative for
Open AuTHentication) to specify a format that can be freely
distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Credential migration by end-user . . . . . . . . . . . 6 3.1.1. Credential migration by end-user . . . . . . . . . . . 6
3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6
3.1.3. Bulk migration of existing credentials . . . . . . . . 6 3.1.3. Bulk migration of existing credentials . . . . . . . . 6
3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 5 skipping to change at page 3, line 12
5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13
6. Key container XML schema definitions . . . . . . . . . . . . . 17 6. Key container XML schema definitions . . . . . . . . . . . . . 17
6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20
6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22
6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22
6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23
6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24
6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25
6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 27 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 26
6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 28 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 27
6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28
6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30
6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30
6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31
6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33
6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33
6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41
skipping to change at page 4, line 8 skipping to change at page 4, line 8
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44
10.2. Symmetric Key Container with a single Password-based 10.2. Symmetric Key Container with a single Password-based
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45
11. Normative References . . . . . . . . . . . . . . . . . . . . . 46 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 49
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 upon one time password (OTP) and challenge such as systems based one time password (OTP) and challenge response
response mechanisms, there is a need for vendor interoperability and mechanisms, there is a need for vendor interoperability and a
a standard format for importing, exporting or provisioning symmetric standard format for importing, exporting or provisioning symmetric
key based credentials from one system to another. Traditionally key based credentials from one system to another. Traditionally
authentication server vendors and service providers have used authentication server vendors and service providers have used
proprietary formats for importing, exporting and provisioning these proprietary formats for importing, exporting and provisioning these
credentials into their systems making it hard to use tokens from credentials into their systems making it hard to use tokens from
vendor A with a server from vendor B. vendor A with a server from vendor B.
This Internet draft describes a standard format for serializing This Internet draft describes a standard format for serializing
symmetric key based credentials such as OTP shared secrets for system symmetric key based credentials such as OTP shared secrets for system
import, export or network/protocol transport. The goal is that the import, export or network/protocol transport. The goal is that the
format will facilitate dynamic provisioning and transfer of a format will facilitate dynamic provisioning and transfer of a
skipping to change at page 4, line 39 skipping to change at page 4, line 39
interoperability such as the initial event counter used in the HOTP interoperability such as the initial event counter used in the HOTP
algorithm [HOTP]. It is also applicable for other time-based or algorithm [HOTP]. It is also applicable for other time-based or
proprietary algorithms. proprietary algorithms.
To provide an analogy, in public key environments the PKCS#12 format To provide an analogy, in public key environments the PKCS#12 format
[PKCS12] is commonly used for importing and exporting private keys [PKCS12] is commonly used for importing and exporting private keys
and certificates between systems. In the environments outlined in and certificates between systems. In the environments outlined in
this document where OTP credentials may be transported directly down this document where OTP credentials may be transported directly down
to smartcards or devices with limited computing capabilities, a to smartcards or devices with limited computing capabilities, a
format with small (size in bytes) and explicit shared secret format with small (size in bytes) and explicit shared secret
configuration attribute information is desirable, avoiding complexity configuration attribute information is desirable, avoding complexity
of PKCS#12. For example, one would have to use opaque data within of PKCS#12. For example, one would have to use opaque data within
PKCS#12 to carry shared secret attributes used for OTP calculations, PKCS#12 to carry shared secret attributes used for OTP calculations,
whereas a more explicit attribute schema definition is better for wherears a more explicit attribute schema definition is better for
interoperability and efficiency. interoperation and efficiency.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
credentials using some form of a online provisioning protocol. credentials using some form of a online provisioning protocol.
3.2.1. Online provisioning a credential to end-user's authentication 3.2.1. Online provisioning a credential to end-user's authentication
token token
A mobile device user wants to obtain an OTP credential (shared A mobile device user wants to obtain an OTP credential (shared
secret) for use with an OTP soft token on the device. The soft token secret) for use with an OTP soft token on the device. The soft token
client from vendor A initiates the provisioning process against a client from vendor A initiates the provisioning process against a
provisioning system from vendor B using a standards-based provisioning system from vendor B using a standards-based
provisioning protocol such as [DSKPP]. The provisioning system provisioning protocol such as [DSKPP]. The provisioning system
delivers an OTP credential in a standard format that can be processed delivers one or more OTP credential(s) in a standard format that can
by the mobile device. The user can download more than one credential be processed by the mobile device. The user can download a payload
in a single session if the provisioning server holds multiple that contains more than one credential.
credentials for that user.
In a variation of the above, instead of the user's mobile phone, a In a variation of the above, instead of the user's mobile phone, a
credential is provisioned in the user's soft token application on a credential is provisioned in the user's soft token application on a
laptop using a network-based online protocol. As before, the laptop using a network-based online protocol. As before, the
provisioning system delivers an OTP credential in a standard format provisioning system delivers an OTP credential 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.
3.2.2. Server to server provisioning of credentials 3.2.2. Server to server provisioning of credentials
Sometimes, instead of importing token information from a manufacturer Sometimes, instead of importing token information from manufacturer
using a file, an OTP validation server may download the credential using a file, an OTP validation server may download the credential
seed records using an online protocol. The credentials can be seed records using an online protocol. The credentials can be
downloaded in a standard format that can be processed by a validation downloaded in a standard format that can be processed by a validation
system. system.
In another scenario, an OTA (over-the-air) credential provisioning In another scenario, an OTA (over-the-air) credential provisioning
gateway that provisions credentials to mobile phones may obtain gateway that provisions credentials to mobile phones may obtain
credentials from the credential issuer using an online protocol. The credentials from the credential issuer using an online protocol. The
credentials are delivered in a standard format that can be processed credentials are delivered in a standard format that can be processed
by the OTA credential provisioning gateway and subsequently sent to by the OTA credential provisioning gateway and subsequently sent to
skipping to change at page 11, line 22 skipping to change at page 11, line 22
5.1. Common Attributes 5.1. Common Attributes
5.1.1. Data (OPTIONAL) 5.1.1. Data (OPTIONAL)
Defines the data attributes of the symmetric key. Each is a name Defines the data attributes of the symmetric key. Each is a name
value pair which has both a base64 encoded value and a base 64 value pair which has both a base64 encoded value and a base 64
encoded valueDigest. The value can be encrypted. If the container encoded valueDigest. The value can be encrypted. If the container
has been encrypted the valueDigest MUST be populated with the digest has been encrypted the valueDigest MUST be populated with the digest
of the unencrypted value. of the unencrypted value.
This is also where the key value is held, therefore the following This is also where the key value is held, therefore the follwoing
list of attribute names have been reserved: list of attribute names have been reserved:
SECRET: the shared secret key value in binary, base64 encoded SECRET: the shared secret key value in binary, base64 encoded
COUNTER: the event counter for event based OTP algorithms. 8 bytes COUNTER: the event counter for event based OTP algorithms. 8 bytes
unsigned integer in big endian (i.e. network byte order) form unsigned integer in big endian (i.e. network byte order) form
base64 encoded base64 encoded
TIME: the time for time based OTP algorithms. 8 bytes unsigned TIME: the time for time based OTP algorithms. 8 bytes unsigned
integer in big endian (i.e. network byte order) form base64 integer in big endian (i.e. network byte order) form base64
skipping to change at page 12, line 28 skipping to change at page 12, line 28
Additional attributes that are specific to the usage type MAY be Additional attributes that are specific to the usage type MAY be
required. Section 6.1 describes OTP and CR specific attributes. required. Section 6.1 describes OTP and CR specific attributes.
5.1.4. KeyId (MANDATORY) 5.1.4. KeyId (MANDATORY)
A unique and global identifier of the symmetric key. The identifier A unique and global identifier of the symmetric key. The identifier
is defined as a string of alphanumeric characters. is defined as a string of alphanumeric characters.
5.1.5. Issuer (MANDATORY) 5.1.5. Issuer (MANDATORY)
The key issuer name, this is normally the name of the organization The key issuer name, this is normally the name of the organisation
that issues the key to the end user of the key. For example MyBank that issues the key to the end user of the key. For example MyBank
issuing hardware tokens to their retail banking users 'MyBank' would issuing hardware tokens to their retail banking users 'MyBank' would
be the issuer. The Issuer is defined as a String. be the issuer. The Issuer is defined as a String.
5.1.6. FriendlyName (OPTIONAL) 5.1.6. FriendlyName (OPTIONAL)
The user friendly name that is assigned to the secret key for easy The user friendly name that is assigned to the secret key for easy
reference. The FriendlyName is defined as a String. reference. The FriendlyName is defined as a String.
5.1.7. AccessRules (OPTIONAL) 5.1.7. AccessRules (OPTIONAL)
skipping to change at page 13, line 11 skipping to change at page 13, line 11
Identifies the encryption algorithm and possible parameters used to Identifies the encryption algorithm and possible parameters used to
protect the Secret Key data in the container and MUST be set to one protect the Secret Key data in the container and MUST be set to one
of the values defined in Section 6.2. If 'OTHER' is specified an of the values defined in Section 6.2. If 'OTHER' is specified an
extension value MUST be set in the 'ext-algorithm' attribute. extension value MUST be set in the 'ext-algorithm' attribute.
When the value is set to NONE, implementations SHALL ensure the When the value is set to NONE, implementations SHALL ensure the
privacy of the key data through other standard mechanisms e.g. privacy of the key data through other standard mechanisms e.g.
transport level encryption. transport level encryption.
When the KeyContainer contains more than one key and EncryptionMethod When the container (payload) contains more than one key and
is different from NONE, the same encryption key MUST be used to EncryptionMethod is different from NONE, the same encryption key MUST
encrypt all the key data elements in the container. be used to encrypt all the key data elements in the container.
5.1.9. DigestMethod (MANDATORY when Digest is present) 5.1.9. DigestMethod (MANDATORY when Digest is present)
Identifies the algorithm and possible parameters used to generate a Identifies the algorithm and possible parameters used to generate a
digest of the Secret Key data. The digest guarantees the integrity digest of the the Secret Key data. The digest guarantees the
and the authenticity of the key data. The Digest algorithm MUST be integrity and the authenticity of the key data. The Digest algorithm
set to one of the values defined in Section 6.4. If 'OTHER' is MUST be set to one of the values defined in Section 6.4. If 'OTHER'
specified an extension value MUST be set in the 'ext-algorithm' is specified an extension value MUST be set in the 'ext-algorithm'
attribute. attribute.
See Section 6.1.8 for more information on Digest data value type. See Section 6.1.8 for more information on Digest data value type.
5.1.10. OTP and CR specific Attributes (OPTIONAL) 5.1.10. OTP and CR specific Attributes (OPTIONAL)
When the key usage is set to OTP or CR, additional attributes MUST be When the key usage is set to OTP or CR, additional attributes MUST be
provided to support the OTP and/or the response computation as provided to support the OTP and/or the response computation as
required by the underlying algorithm and to customize or configure required by the underlying algorithm and to customize or configure
the outcome of the computation (format, length and usage modes). the outcome of the computation (format, length and usage modes).
skipping to change at page 13, line 48 skipping to change at page 13, line 48
1. Format (MANDATORY) 1. Format (MANDATORY)
Defines the format of the challenge accepted by the device and Defines the format of the challenge accepted by the device and
MUST be one of the values defined in Section 6.6 MUST be one of the values defined in Section 6.6
2. CheckDigit (OPTIONAL) 2. CheckDigit (OPTIONAL)
Defines if the device needs to check the appended Luhn check Defines if the device needs to check the appended Luhn check
digit contained in a provided challenge. This is only valid digit contained in a provided challenge. This is only valid
if the Format attribute is 'DECIMAL'. Value MUST be: 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
3. Min (MANDATORY) 3. Min (MANDATORY)
Defines the minimum size of the challenge accepted by the Defines the minimum size of the challenge accepted by the
device for CR mode. device for CR mode.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL','HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the minimum number of 'ALPHANUMERIC' this value indicates the minimum number of
digits/characters. digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the minimum number of bytes of the unencoded value. indicates the minimum number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
4. Max (MANDATORY) 4. Max (MANDATORY)
Defines the maximum size of the challenge accepted by the Defines the maximum size of the challenge accepted by the
device for CR mode. device for CR mode.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL','HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the maximum number of 'ALPHANUMERIC' this value indicates the maximum number of
digits/characters. digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the maximum number of bytes of the unencoded value. indicates the maximum number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
skipping to change at page 15, line 13 skipping to change at page 15, line 13
the following sub-attributes: the following sub-attributes:
1. Format (MANDATORY) 1. Format (MANDATORY)
Defines the format of the response generated by the device and Defines the format of the response generated by the device and
MUST be one of the values defined in Section 6.6 MUST be one of the values defined in Section 6.6
2. CheckDigit (OPTIONAL) 2. CheckDigit (OPTIONAL)
Defines if the device needs to append a Luhn check digit to Defines if the device needs to append a Luhn check digit to
the response. This is only valid if the Format attribute is the response. This is only valid if the Format attribute
'DECIMAL'. Value MUST be: is'DECIMAL'. Value MUST be:
TRUE device will append a Luhn check digit to the response. TRUE device will append a Luhn check digit to the response.
FALSE device will not append a Luhn check digit to the FALSE device will not append a Luhn check digit to the
response. response.
3. Length (MANDATORY) 3. Length (MANDATORY)
Defines the length of the response generated by the device. Defines the length of the response generated by the device.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL','HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the number of digits/ 'ALPHANUMERIC' this value indicates the number of digits/
characters. characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value. indicates the number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
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 and may be associated to one or more contain one or more Key entities and may be associated to one or more
User entities. User 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 |
| | | |
| ----------------- ----------------- | | ------------------ ----------------- |
| | Device 1 | | Device n | | | | Device 1 | | Device n | |
| | | | | | | | | | | |
| | ----------- | | ----------- | | | | ------------ | | ------------ | |
| | | Key 1 | | | | Key n | | | | | | Key 1 | | | | Key n | | |
| | ----------- | | ----------- | | | | ------------ | | ------------ | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | ----------- | | ----------- | | | | ------------ | | ------------ | |
| | | Key m | | | | Key p | | | | | | Key m | | | | Key p | | |
| | ----------- | | ----------- | | | | ------------ | | ------------ | |
| ----------------- ----------------- | | ------------------ ----------------- |
| | | | | | | | | |
| | | | | | | | | |
| --------- --------- --------- | | ---------- ---------- ---------- |
| | User 1 | | User 1 | | User n | | | | User 1 | | User 1 | | User n | |
| --------- --------- --------- | | ---------- ---------- ---------- |
| | | |
-------------------------------------------- --------------------------------------------
6.1. XML Schema Types 6.1. XML Schema Types
The following types are defined to represent the portable key The following types are defined to represent the portable key
container entities and associated attributes. container entities and associated attributes.
6.1.1. KeyType 6.1.1. KeyType
skipping to change at page 18, line 21 skipping to change at page 18, line 21
<sequence> <sequence>
<element name="Issuer" type="string"/> <element name="Issuer" type="string"/>
<element name="Usage" type="pskc:UsageType"/> <element name="Usage" type="pskc:UsageType"/>
<element name="FriendlyName" type="string" minOccurs="0"/> <element name="FriendlyName" type="string" minOccurs="0"/>
<element name="Data" type="pskc:DataType" minOccurs="0" <element name="Data" type="pskc:DataType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element name="AccessRules" minOccurs="0"> <element name="AccessRules" minOccurs="0">
<complexType> <complexType>
<simpleContent> <simpleContent>
<extension base="string"> <extension base="string">
<attribute name="userPIN" type="boolean" use="optional" <attribute name="userPIN" type="boolean"
default="false"/> default="false"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
</element> </element>
<element name="Logo" type="logo:LogoType" minOccurs="0"/> <element name="Logo" type="logo:LogoType" minOccurs="0"/>
<element name="Expiry" type="string" minOccurs="0"/> <element name="Expiry" type="string" minOccurs="0"/>
</sequence> </sequence>
<attribute name="KeyId" type="string" use="required"/> <attribute name="KeyId" type="string" use="required"/>
<attribute name="KeyAlgorithm" type= <attribute name="KeyAlgorithm" type=
skipping to change at page 18, line 48 skipping to change at page 18, line 48
o <Usage> of type UsageType defines the usage of the Secret Key. The o <Usage> of type UsageType defines the usage of the Secret Key. The
Usage attribute is described in Section 5.1.3. Usage attribute is described in Section 5.1.3.
o <Issuer> identifies the issuer of the Secret Key. The Issuer o <Issuer> identifies the issuer of the Secret Key. The Issuer
attribute is described in Section 5.1.5. attribute is described in Section 5.1.5.
o <FriendlyName> is a user friendly name that is assigned to the o <FriendlyName> is a user friendly name that is assigned to the
Secret Key for easy reference. Secret Key for easy reference.
o <Data> conveys the data attributes (e.g. the Secret Key) in name o <Data> conveys the data attributes (eg the Secret Key) in name
(string) value (base64 encoded) pairs. The value can be (string) value (base64 encoded) pairs. The value can be
encrypted, in this case a digest of the non-encrypted data is encrypted, in this case a digest of the non-encrypted data is
present. The <Data> component is further described below. present. The <Data> component is further described below.
o <AccessRules> Defines the rules for accessing the credential on o <AccessRules> Defines the rules for accessing the credential on
the device e.g. a password must be provided by the user to view the device e.g. a password must be provided by the user to view
credential info or use the credential to generate an OTP response credential info or use the credential to generate an OTP response
o KeyId is a global identifier of the Secret Key. See Section 5.1.4. o KeyId is a global identifier of the Secret Key. See Section 5.1.4.
skipping to change at page 19, line 36 skipping to change at page 19, line 36
<complexType name="DataType"> <complexType name="DataType">
<sequence> <sequence>
<element name="Value" type="base64Binary"/> <element name="Value" type="base64Binary"/>
<element name="ValueDigest" type="base64Binary" minOccurs="0"/> <element name="ValueDigest" type="base64Binary" minOccurs="0"/>
<attribute name="Name" type="string" use="required"/> <attribute name="Name" type="string" use="required"/>
</sequence> </sequence>
</complexType> </complexType>
The 'Name' attribute defines the name of the name-value pair, the The 'Name' attribute defines the name of the name-value pair, the
following list of attribute names have been reserved: follwoing list of attribute names have been reserved:
SECRET: the key value in binary, base64 encoded SECRET: the key key value in binary, base64 encoded
COUNTER: the event counter for event based OTP algorithms. 8 bytes COUNTER: the event counter for event based OTP algorithms. 8 bytes
unsigned integer in big endian (i.e. network byte order) form unsigned integer in big endian (i.e. network byte order) form
base64 encoded base64 encoded
TIME: the time for time based OTP algorithms. 8 bytes unsigned TIME: the time for time based OTP algorithms. 8 bytes unsigned
integer in big endian (i.e. network byte order) form base64 integer in big endian (i.e. network byte order) form base64
encoded (Number of seconds since 1970) encoded (Number of seconds since 1970)
TIME_INTERVAL: the time interval value for time based OTP TIME_INTERVAL: the time interval value for time based OTP
skipping to change at page 21, line 16 skipping to change at page 21, line 16
<sequence> <sequence>
<element name="AlgorithmIdentifier" <element name="AlgorithmIdentifier"
type="pskc:AlgorithmIdentifierType" minOccurs="0"/> type="pskc:AlgorithmIdentifierType" minOccurs="0"/>
<element name="ResponseFormat"> <element name="ResponseFormat">
<complexType> <complexType>
<attribute name="format" type="pskc:valueFormat" <attribute name="format" type="pskc:valueFormat"
use="required"/> use="required"/>
<attribute name="length" type="unsignedInt" <attribute name="length" type="unsignedInt"
use="required"/> use="required"/>
<attribute name="checkDigits" type="boolean" <attribute name="checkDigits" type="boolean"
use="optional" default="false"/> default="false"/>
</complexType> </complexType>
</element> </element>
<element name="ChallengeFormat" minOccurs="0"> <element name="ChallengeFormat" minOccurs="0">
<complexType> <complexType>
<attribute name="format" type="pskc:valueFormat" <attribute name="format" type="pskc:valueFormat"
use="required"/> use="required"/>
<attribute name="min" type="unsignedInt" use="required"/> <attribute name="min" type="unsignedInt" use="required"/>
<attribute name="max" type="unsignedInt" use="required"/> <attribute name="max" type="unsignedInt" use="required"/>
<attribute name="checkDigits" type="boolean" use="optional" <attribute name="checkDigits" type="boolean"
default="false"/> default="false"/>
</complexType> </complexType>
</element> </element>
<element name="AppProfileId" type="string" minOccurs="0"/> <element name="AppProfileId" type="string" minOccurs="0"/>
</sequence> </sequence>
<attribute name="otp" type="boolean" use="optional" <attribute name="otp" type="boolean"
default="false"/>
<attribute name="cr" type="boolean" use="optional"
default="false"/>
<attribute name="sign" type="boolean" use="optional"
default="false"/>
<attribute name="encrypt" type="boolean" use="optional"
default="false"/> default="false"/>
<attribute name="unlock" type="boolean" use="optional" <attribute name="cr" type="boolean"
default="false"/> default="false"/>
<attribute name="sign" type="boolean" default="false"/>
<attribute name="encrypt" type="boolean" default="false"/>
<attribute name="unlock" type="boolean" default="false"/>
</complexType> </complexType>
The UsageType components have the following meanings: The UsageType components have the following meanings:
o <AlgorithmIdentifier> the AlgorithmIdentifier as defined in o <AlgorithmIdentifier> the AlgorithmIdentifier as defined in
[OCRA]]. [OCRA]].
o <ChallengeFormat> hold the challenge attributes in CR based
algorithm computations.
o <ResponseFormat> holds the algorithm response attributes. o <ResponseFormat> holds the algorithm response attributes.
o <AccessRules> holds a set of access rules and policies for the key o <ChallengeFormat> hold the challenge attributes in CR based
once provisioned on the Device. Currently only the userPIN algorithm computations.
attribute is defined. The userPIN indicates whether the user MUST
provide a PIN to unlock the key.
o <AppProfileId> Is the unique shared identifier for out of band o <AppProfileId> Is the unique shared identifier for out of band
shared common parameters. shared common parameters.
6.1.3. DeviceType 6.1.3. DeviceType
The DeviceType type represents the Device entity in the Container. A The DeviceType type represents the Device entity in the Container. A
Device MAY be bound to a user and MAY contain more than one keys. It Device MAY be bound to a user and MAY contain more than one keys. It
is recommended that a key is bound to one and only one Device. is recommended that a key is bound to one and only one Device.
skipping to change at page 22, line 51 skipping to change at page 22, line 43
6.1.4. DeviceIdType 6.1.4. DeviceIdType
The DeviceId type represents the identifying criteria to uniquely The DeviceId type represents the identifying criteria to uniquely
identify the device that contains the associated keys. Since devices identify the device that contains the associated keys. Since devices
can come in different form factors such as hardware tokens, can come in different form factors such as hardware tokens,
smartcards, soft tokens in a mobile phone or PC etc this type allows smartcards, soft tokens in a mobile phone or PC etc this type allows
different criteria to be used. Combined though the criteria MUST different criteria to be used. Combined though the criteria MUST
uniquely identify the device. For example for hardware tokens the uniquely identify the device. For example for hardware tokens the
combination of SerialNo and Manufacturer will uniquely identify a combination of SerialNo and Manufacturer will uniquely identify a
device but not serialNo alone since two different token manufacturers device but not serialNo alone since two different token manufacturers
might issue devices with the same serial number (similar to the might issue devices with the same serialnumber (similar to the
IssuerDN and serial number of a certificate). For keys hold on IssuerDN and serialnumber of a certificate). For keys hold on
banking cards the identification of the device is often done via the banking cards the identification of the device is often done via the
Primary Account Number (PAN, the big number printed on the front of Primary Account Number (PAN, the big number printed on the front of
the card) and an expiry date of the card. DeviceId is an extensible the card) and an expiry date of the card. DeviceId is an extensible
type that allows all these different ways to uniquely identify a type that allows all these different ways to uniquely identify a
specific key containing device. specific key containing device.
The DeviceIdType is defined as follows: The DeviceIdType is defined as follows:
<complexType name="DeviceIdType"> <complexType name="DeviceIdType">
<sequence> <sequence>
skipping to change at page 26, line 16 skipping to change at page 25, line 35
The EncryptionMethodType is defined as follows: The EncryptionMethodType is defined as follows:
<complexType name="EncryptionMethodType"> <complexType name="EncryptionMethodType">
<sequence> <sequence>
<element name="EncKeyLabel" minOccurs="0"/> <element name="EncKeyLabel" minOccurs="0"/>
<choice> <choice>
<sequence> <sequence>
<element name="KeyInfo" type="ds:KeyInfoType" minOccurs="0"/> <element name="KeyInfo" type="ds:KeyInfoType" minOccurs="0"/>
<element name="OAEPParams" type="base64Binary" minOccurs="0"/> <element name="OAEPParams" type="base64Binary" minOccurs="0"/>
<element name="HashAlgorithm"
type="pskc:HashAlgorithmType" minOccurs="0"/>
</sequence> </sequence>
<sequence> <sequence>
<element name="PBESalt" type="base64Binary" minOccurs="0"/> <element name="PBESalt" type="base64Binary" minOccurs="0"/>
<element name="PBEIterationCount" type="int" minOccurs="0"/> <element name="PBEIterationCount" type="int" minOccurs="0"/>
<element name="IV" type="base64Binary" minOccurs="0"/> <element name="IV" type="base64Binary" minOccurs="0"/>
</sequence> </sequence>
</choice> </choice>
</sequence> </sequence>
<attribute name="algorithm" type="pskc:EncryptionAlgorithmType" <attribute name="algorithm" type="pskc:EncryptionAlgorithmType"
use="required"/> use="required"/>
skipping to change at page 27, line 16 skipping to change at page 26, line 34
o <EncKeyLabel>: identifies a unique label for a pre-shared o <EncKeyLabel>: identifies a unique label for a pre-shared
encryption key. encryption key.
o <KeyInfo>: conveys the information of the key if an RSA algorithm o <KeyInfo>: conveys the information of the key if an RSA algorithm
has been used. has been used.
o <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has o <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has
been used. been used.
o <HashAlgorithm>: conveys the digest algorithm if an RSA algorithm
has been used.
6.1.8. DigestMethodType 6.1.8. DigestMethodType
The DigestMethodType defines the algorithm and parameters used to The DigestMethodType defines the algorithm and parameters used to
create the digest on the unencrypted Secret Key data in the create the digest on the unencrypted Secret Key data in the
Container. The digest is applied on each individual Secret Key data Container. The digest is applied on each individual Secret Key data
in the Container before encryption. The digest method MUST be the in the Container before encryption. The digest method MUST be the
same for all Secret Key data in the container. Unless a different same for all Secret Key data in the container. Unless a different
digest key is specified it is assumed that keyed digest algorithms digest key is specified it is assumed that keyed digest algorithms
will use the same key as for encryption will use the same key as for encryption
skipping to change at page 28, line 10 skipping to change at page 27, line 27
information on supported algorithms information on supported algorithms
o <DigestKeyLabel>: identifies a unique label for a pre-shared o <DigestKeyLabel>: identifies a unique label for a pre-shared
digest key. digest key.
6.1.9. AlgorithmIdentifierType 6.1.9. AlgorithmIdentifierType
The AlgorithmIdentiferType defines the Algorithm identifier (AI) The AlgorithmIdentiferType defines the Algorithm identifier (AI)
specified in [OCRA]. specified in [OCRA].
The AlgorithmIdentifierType is defined as follows: The AlgorithmIdentifierType is defines as follows:
<complexType name="AlgorithmIdentifierType"> <complexType name="AlgorithmIdentifierType">
<sequence> <sequence>
<element name="Algorithm"> <element name="Algorithm">
<simpleType> <simpleType>
<restriction base="string"> <restriction base="string">
<enumeration value="OCRA-HOTP"/> <enumeration value="OCRA-HOTP"/>
</restriction> </restriction>
</simpleType> </simpleType>
</element> </element>
skipping to change at page 30, line 43 skipping to change at page 30, line 43
<simpleType name="HashAlgorithmType"> <simpleType name="HashAlgorithmType">
<restriction base="string"> <restriction base="string">
<enumeration value="SHA1"/> <enumeration value="SHA1"/>
<enumeration value="SHA256"/> <enumeration value="SHA256"/>
<enumeration value="SHA512"/> <enumeration value="SHA512"/>
</restriction> </restriction>
</simpleType> </simpleType>
SHA1 when the digest was performed using the SHA1 algorithm SHA1 when the digest was performed using the SHA1 algorithm
SHA192 when the digest was performed using the SHA192 algorithm
SHA256 when the digest was performed using the SHA256 algorithm SHA256 when the digest was performed using the SHA256 algorithm
SHA512 when the digest was performed using the SHA512 algorithm
6.4. DigestAlgorithmType 6.4. DigestAlgorithmType
The DigestAlgorithmType defines the allowed algorithms for generating The DigestAlgorithmType defines the allowed algorithms for generating
a digest on the unencrypted Secret Key data in the Container. a digest on the unencrypted Secret Key data in the Container.
The DigestAlgorithmType is defined as follows: The DigestAlgorithmType is defined as follows:
<simpleType name="DigestAlgorithmType"> <simpleType name="DigestAlgorithmType">
<restriction base="string"> <restriction base="string">
<enumeration value="HMAC-SHA1"/> <enumeration value="HMAC-SHA1"/>
<enumeration value="HMAC-SHA256"/> <enumeration value="HMAC-SHA256"/>
<enumeration value="HMAC-SHA512"/> <enumeration value="HMAC-SHA512"/>
<enumeration value="OTHER"/> <enumeration value="OTHER"/>
</restriction> </restriction>
</simpleType> </simpleType>
HMAC-SHA1 when the digest was performed using the HMAC-SHA1 HMAC-SHA1 when the digest was performed using the HMAC-SHA1
algorithm algorithm
HMAC-SHA192 when the digest was performed using the HMAC-SHA192 HMAC-SHA256 when the digest was performed using the HMAC-SHA256
algorithm algorithm
HMAC-SHA256 when the digest was performed using the HMAC-SHA256 HMAC-SHA512 when the digest was performed using the HMAC-SHA512
algorithm algorithm
OTHER extension point for not already defined algorithms in this OTHER extension point for not already defined algorithms in this
list. list.
6.5. KeyAlgorithmType 6.5. KeyAlgorithmType
The KeyAlgorithmType defines the algorithms in which the Secret Key The KeyAlgorithmType defines the algorithms in which the Secret Key
data is used. data is used.
skipping to change at page 36, line 40 skipping to change at page 36, line 40
type="boolean"/> type="boolean"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="KeyType"> <complexType name="KeyType">
<sequence> <sequence>
<element name="Issuer" type="string"/> <element name="Issuer" type="string"/>
<element name="Usage" type="pskc:UsageType"/> <element name="Usage" type="pskc:UsageType"/>
<element name="FriendlyName" type="string" <element name="FriendlyName" type="string"
minOccurs="0"/> minOccurs="0"/>
<element name="Data" type="pskc:DataType" <element name="Data" type="pskc:DataType"
minOccurs="0"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="AccessRules" minOccurs="0"> <element name="AccessRules" minOccurs="0">
<complexType> <complexType>
<simpleContent> <simpleContent>
<extension base="string"> <extension base="string">
<attribute name="userPIN" type="boolean" <attribute name="userPIN" type="boolean" default="false"/>
use="optional" default="false"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
</element> </element>
<element name="Logo" type="logo:LogoType" <element name="Logo" type="logo:LogoType"
minOccurs="0"/> minOccurs="0"/>
<element name="Expiry" type="string" minOccurs="0"/> <element name="Expiry" type="string" minOccurs="0"/>
</sequence> </sequence>
<attribute name="KeyId" type="string" use="required"/> <attribute name="KeyId" type="string" use="required"/>
<attribute name="KeyAlgorithm" <attribute name="KeyAlgorithm"
skipping to change at page 37, line 50 skipping to change at page 37, line 49
</complexType> </complexType>
<complexType name="UsageType"> <complexType name="UsageType">
<sequence> <sequence>
<element name="AlgorithmIdentifier" <element name="AlgorithmIdentifier"
type="pskc:AlgorithmIdentifierType" minOccurs="0"/> type="pskc:AlgorithmIdentifierType" minOccurs="0"/>
<element name="ResponseFormat"> <element name="ResponseFormat">
<complexType> <complexType>
<attribute name="format" type="pskc:valueFormat" <attribute name="format" type="pskc:valueFormat"
use="required"/> use="required"/>
<attribute name="length" type="unsignedInt" use="required"/> <attribute name="length" type="unsignedInt" use="required"/>
<attribute name="checkDigits" type="boolean" use="optional" <attribute name="checkDigits" type="boolean" default="false"/>
default="false"/>
</complexType> </complexType>
</element> </element>
<element name="ChallengeFormat" minOccurs="0"> <element name="ChallengeFormat" minOccurs="0">
<complexType> <complexType>
<attribute name="format" type="pskc:valueFormat" <attribute name="format" type="pskc:valueFormat"
use="required"/> use="required"/>
<attribute name="min" type="unsignedInt" use="required"/> <attribute name="min" type="unsignedInt" use="required"/>
<attribute name="max" type="unsignedInt" use="required"/> <attribute name="max" type="unsignedInt" use="required"/>
<attribute name="checkDigits" type="boolean" use="optional" <attribute name="checkDigits" type="boolean"
default="false"/> default="false"/>
</complexType> </complexType>
</element> </element>
<element name="Time" type="unsignedLong" minOccurs="0"/> <element name="Time" type="unsignedLong" minOccurs="0"/>
<element name="AppProfileId" type="string" minOccurs="0"/> <element name="AppProfileId" type="string" minOccurs="0"/>
</sequence> </sequence>
<attribute name="otp" type="boolean" use="optional" <attribute name="otp" type="boolean"
default="false"/> default="false"/>
<attribute name="cr" type="boolean" use="optional" <attribute name="cr" type="boolean"
default="false"/> default="false"/>
<attribute name="sign" type="boolean" use="optional" <attribute name="sign" type="boolean"
default="false"/> default="false"/>
<attribute name="encrypt" type="boolean" use="optional" <attribute name="encrypt" type="boolean"
default="false"/> default="false"/>
<attribute name="unlock" type="boolean" use="optional" <attribute name="unlock" type="boolean"
default="false"/> default="false"/>
</complexType> </complexType>
<complexType name="AttributeType"> <complexType name="AttributeType">
<simpleContent> <simpleContent>
<extension base="string"> <extension base="string">
<attribute name="name" type="string" use="required"/> <attribute name="name" type="string" use="required"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<complexType name="EncryptionMethodType"> <complexType name="EncryptionMethodType">
<sequence> <sequence>
<element name="EncKeyLabel" minOccurs="0"/> <element name="EncKeyLabel" minOccurs="0"/>
<choice> <choice>
<sequence> <sequence>
<element name="KeyInfo" <element name="KeyInfo"
type="ds:KeyInfoType" minOccurs="0"/> type="ds:KeyInfoType" minOccurs="0"/>
<element name="OAEPParams" <element name="OAEPParams"
type="base64Binary" minOccurs="0"/> type="base64Binary" minOccurs="0"/>
<element name="HashAlgorithm"
type="pskc:HashAlgorithmType" minOccurs="0"/>
</sequence> </sequence>
<sequence> <sequence>
<element name="PBESalt" type="base64Binary" <element name="PBESalt" type="base64Binary"
minOccurs="0"/> minOccurs="0"/>
<element name="PBEIterationCount" type="int" <element name="PBEIterationCount" type="int"
minOccurs="0"/> minOccurs="0"/>
<element name="IV" type="base64Binary" minOccurs="0"/> <element name="IV" type="base64Binary" minOccurs="0"/>
</sequence> </sequence>
</choice> </choice>
</sequence> </sequence>
skipping to change at page 40, line 46 skipping to change at page 40, line 41
</restriction> </restriction>
</simpleType> </simpleType>
<element name="KeyContainer" <element name="KeyContainer"
type="pskc:KeyContainerType"/> type="pskc:KeyContainerType"/>
<complexType name="DataType"> <complexType name="DataType">
<sequence> <sequence>
<element name="Value" type="base64Binary"/> <element name="Value" type="base64Binary"/>
<element name="ValueDigest" <element name="ValueDigest"
type="base64Binary" minOccurs="0"/> type="base64Binary" minOccurs="0"/>
</sequence> </sequence>
<attribute name="Name" type="string"
use="required"/>
</complexType> </complexType>
</schema> </schema>
8. Security Considerations 8. 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
skipping to change at page 42, line 16 skipping to change at page 42, line 16
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.
8.2. Payload integrity 8.2. Payload integrity
The portable symmetric key container provides a means to guarantee The portable symmetric key container provides a mean to guarantee the
the integrity of the information it contains through digital integrity of the information it contains through digital signatures.
signatures. For best security practices, the digital signature of For best security practices, the digital signature of the container
the container should encompass the entire payload. This provides should encompass the entire payload. This provides assurances for
assurances for the integrity of all attributes. It also allows the integrity of all attributes. It also allows verification of the
verification of the integrity of a given payload even after the integrity of a given payload even after the container is delivered
container is delivered through the communication channel to the through the communication channel to the target perimeter and channel
target perimeter and channel message integrity check is no longer message integrity check is no longer possible.
possible.
8.3. Payload authenticity 8.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.
9. Acknowledgements 9. Acknowledgements
This work initiated from a joint effort by the members of OATH The authors of this draft would like to thank the following people
(Initiative for Open AuTHentication). The authors of this draft for their contributions and support to make this a better
would like to thank the following people for their contributions and specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu
support to make this a better specification: Apostol Vassilev, Jon Veath, Kevin Lewis, and Andrea Doherty.
Martinson, Siddhart Bajaj, Stu Veath, Kevin Lewis, and Andrea
Doherty.
10. Appendix A - Example Symmetric Key Containers 10. 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. However, <Signature>, Key <Value> and Key schema in section 7. However, <Signature>, Key <Value> and Key
<ValueDigest> data values are fictitious <ValueDigest> data values are fictitious
10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
Key Key
skipping to change at page 46, line 10 skipping to change at page 46, line 10
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
11. Normative References 11. Normative 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., Nystroem, M., and S. Machani, [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet
"Dynamic Symmetric Key Provisioning Protocol", Internet Draft Informational, URL: http://tools.ietf.org/wg/
Draft Informational, URL: http://tools.ietf.org/id/ keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.
draft-ietf-keyprov-dskpp-00.txt, July 2007.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, Algorithm", RFC 4226,
URL: http://rfc.sunsite.dk/rfc/rfc4226.html, URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
December 2005. December 2005.
[OATH] "Initiative for Open AuTHentication", [OATH] "Initiative for Open AuTHentication",
URL: http://www.openauthentication.org. URL: http://www.openauthentication.org.
[OCRA] MRaihi, D., Rydell, J., Machani, S., and S. Bajaj, "OCRA: [OATHRefArch]
OATH Challenge Response Algorithm", Internet OATH, "Reference Architecture",
Draft Informational, URL: http://www.ietf.org/ URL: http://www.openauthentication.org, Version 1.0, 2005.
[OCRA] MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
Internet Draft Informational, URL: http://www.ietf.org/
internet-drafts/ internet-drafts/
draft-mraihi-mutual-oath-hotp-variants-05.txt, draft-mraihi-mutual-oath-hotp-variants-01.txt,
December 2005. December 2005.
[PKCS1] Kaliski, B. and J. Staddon, "RFC 2437: PKCS #1: RSA [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
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.
[PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
Syntax Standard", Version 1.0, Syntax Standard", Version 1.0,
URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/. URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.
[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: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/, URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
March 1999. March 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[XMLENC] Eastlake, D. and J. Reagle, "XML Encryption Syntax and [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
Processing.", URL: http://www.w3.org/TR/xmlenc-core/, URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
December 2002.
[XMLSIG] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing",
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.
Authors' Addresses Authors' Addresses
Philip Hoyer Philip Hoyer
ActivIdenity, Inc. ActivIdenity, Inc.
109 Borough High Street 109 Borough High Street
London, SE1 1NL London, SE1 1NL
UK UK
skipping to change at page 48, line 37 skipping to change at page 48, line 37
2225 Sheppard Avenue East 2225 Sheppard Avenue East
Suite 1801 Suite 1801
Toronto, Ontario M2J 5C2 Toronto, Ontario M2J 5C2
Canada Canada
Phone: +1 416 756 2324 Ext. 321 Phone: +1 416 756 2324 Ext. 321
Email: smachani@diversinet.com Email: smachani@diversinet.com
Shuh Chang Shuh Chang
Gemalto Inc. Gemalto Inc.
9442 Capital of Texas Hwy. North
Suite 400, Arboretum Plaza II
Austin, Texas 78759
USA
Phone: +1 512 257 3859
Email: shuh.chang@gemalto.com Email: shuh.chang@gemalto.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 66 change blocks. 
128 lines changed or deleted 110 lines changed or added

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