keyprov P. Hoyer Internet-Draft ActivIdentity Intended status: Standards Track M. Pei Expires:October 23, 2008January 15, 2009 VeriSign S. Machani DiversinetApril 21,July 14, 2008 Portable Symmetric Key Containerdraft-ietf-keyprov-portable-symmetric-key-container-04.txtdraft-ietf-keyprov-portable-symmetric-key-container-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onOctober 23, 2008.January 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a symmetric key format for transport and provisioning of symmetric keys (for example One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of crypto modules such as a strong authentication device. The standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Transport of keys from Server toCrypto ModuleCryptomodule . . . . 8 3.1.2. Transport of keys fromCrypto ModuleCryptomodule toCrypto Module . . . . . . . . . . . . . . . . . . . . . . .Cryptomodule . 8 3.1.3. Transport of keys fromCrypto ModuleCryptomodule to Server . . . . 9 3.1.4. Server to server Bulk import/export of keys . . . . . 9 3.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Server to server Bulk import/export of keys . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Portable Key container definition . . . . . . . . . . . . . . 13 5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . .1314 5.2.Device .KeyProperties . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Device . . .15 5.2.1. DeviceId. . . . . . . . . . . . . . . . . . . . . . .15 5.3. KeyProperties17 5.3.1. DeviceInfo . . . . . . . . . . . . . . . . . . . . . .1618 5.4. Key . . . . . . . . . . . . . . . . . . . . . . . . . . .1719 5.4.1.Data (OPTIONAL)KeyData . . . . . . . . . . . . . . . . . . .20. . . . 23 5.4.2. Usage(MANDATORY). . . . . . . . . . . . . . . . . .21. . . . . . 25 5.4.3. ValueFormat . . . . . . . . . . . . . . . . . . . . .2529 5.4.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . .2629 6. Usage and profile of algorithms for the portable symmetric key container . . . . . . . . . . . . . . . . . . . . . . . .2833 6.1. Usage of EncryptionKey to protect keys in transit . . . .2833 6.1.1. Protecting keys using a pre-shared key via symmetric algorithms . . . . . . . . . . . . . . . . .2833 6.1.2. Protecting keys using passphrase based encryption keys . . . . . . . . . . . . . . . . . . . . . . . . .2934 6.2. Protecting keys using asymmetric algorithms . . . . . . .3136 6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . .3237 6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . .3338 6.3.2. PIN key value compare algorithm identifier . . . . . .3338 7.Reserved data attribute names . . . . . . . . . . . . . . . . 34 8.Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .35 9.39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .40 9.1.46 8.1. Content-type registration for 'application/pskc+xml' . . .40 9.2.46 8.2. XML Schema Registration . . . . . . . . . . . . . . . . .41 9.3.47 8.3. URN Sub-Namespace Registration forurn:ietf:params:xml:ns:keyprov:container:1.0urn:ietf:params:xml:ns:keyprov:pskc:1.0 . . . . . . .41 9.4.. . 47 8.4. Symmetric Key Algorithm Identifier Registry . . . . . . .42 9.4.1.48 8.4.1. Applicability . . . . . . . . . . . . . . . . . . . .42 9.4.2.48 8.4.2. Registerable Algorithms . . . . . . . . . . . . . . .43 9.4.3.49 8.4.3. Registration Procedures . . . . . . . . . . . . . . .44 9.4.4.50 8.4.4. Initial Values . . . . . . . . . . . . . . . . . . . .46 9.5. XML Data Tag Identifier Registry . . . . . . . . .52 9. Security Considerations . . . .49 9.5.1. Applicability. . . . . . . . . . . . . . . 57 9.1. Payload confidentiality . . . . .49 9.5.2. Registerable Data Tags. . . . . . . . . . . . 57 9.2. Payload integrity . . . .50 9.5.3. Registration Procedures. . . . . . . . . . . . . . .50 9.5.4. Initial Values. 58 9.3. Payload authenticity . . . . . . . . . . . . . . . . . . .5158 10.Security Considerations . . . . . .Acknowledgements . . . . . . . . . . . . .53 10.1. Payload confidentiality. . . . . . . . . . 59 11. Appendix A - Example Symmetric Key Containers . . . . . . .53 10.2. Payload integrity. 60 11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . . . .54 10.3. Payload authenticity. . 60 11.2. Symmetric Key Container with a single PIN protected Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 60 11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP Secret Key and non-encrypted counter value . . .54 11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .55 12. Appendix A - Example62 11.4. Symmetric KeyContainersContainer with signature and a single Password-based Encrypted HOTP Secret Key . . . . . . . .56 12.1.. 63 11.5. Symmetric Key Container with a singleNon-EncryptedRSA 1.5 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . .. . . . . 56 12.2.65 11.6. Symmetric Key Container with a singlePIN protected Non-Encrypted HOTPAES-256-CBC Encrypted OCRA Secret Key and non-encrypted counter value . . . . . . . . . . . . . .56 12.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP Secret Key . .. . . . . . . . . . . .. . 57 12.4.66 11.7. Symmetric Key Container withsignature anda singlePassword-basedAES-256-CBC EncryptedHOTPTOTP Secret Key and non-encrypted time values .. . . . . . . . 58 12.5.68 11.8. Symmetric Key Container with two devices containing asingle RSA 1.5 EncryptedNon-Encrypted HOTP Secret Key each sharing common KeyProperties . . . . . . . . . . . . . . . .60 13.. . . . . . 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . .62 13.1.71 12.1. Normative References . . . . . . . . . . . . . . . . . . .62 13.2.71 12.2. Informative References . . . . . . . . . . . . . . . . . .6271 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .6473 Intellectual Property and Copyright Statements . . . . . . . . . .6574 1. Introduction With increasing use of symmetric key based authentication systems such as systems based one time password (OTP) and challenge response mechanisms, there is a need for vendor interoperability and a standard format for importing, exporting or provisioning symmetric keys from one system to another. Traditionally authentication server vendors and service providers have used proprietary formats for importing, exporting and provisioning these keys into their systems making it hard to use tokens from vendor A with a server from vendor B. This Internet draft describes a standard format for serializing symmetric keys such as OTP shared secrets for system import, export or network/protocol transport. The goal is that the format will facilitate dynamic provisioning and transfer ofasymmetric keys such asanOTP sharedsecretsecrets oranencryptionkeykeys of different types. In the case of OTP shared secrets, the format will facilitate dynamic provisioning using an online provisioning protocol to different flavors of embedded tokens or allow customers to import new or existing tokens in batch or single instances into a compliant system. This draft also specifies the key attributes required for computation such as the initial event counter used in the HOTP algorithm [HOTP]. It is also applicable for other time-based or proprietary algorithms. To provide an analogy, in public key environments the PKCS#12 format [PKCS12] is commonly used for importing and exporting private keys and certificates between systems. In the environments outlined in this document where OTP keys may be transported directly down to smartcards or devices with limited computing capabilities, a format with small (size in bytes) and explicit shared secret configuration attribute information is desirable, avoiding complexity of PKCS#12. For example, one would have to use opaque data within PKCS#12 to carry shared secret attributes used for OTP calculations, whereas a more explicit attribute schema definition is better for interoperability and efficiency. 2. Terminology 2.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Definitions This section defines terms used in this document. The same terms may be defined differently in other documents. Authentication Token: A physical device that an authorized user of computer services is given to aid in authentication. The term may also refer to software tokens. Bulk Provisioning: Transferring multiple keys linked to multiple devices in a single execution step within one single PSKC KeyContainer Cryptographic Module: A component of an application, which enables symmetric key cryptographic functionality Cryptographic Key: A parameter used in conjunction with a cryptographic algorithm that determines its operation in such a way that an entity with knowledge of the key can reproduce or reverse the operation, while an entity without knowledge of the key cannot (see [NIST-SP800-57]) Cryptographic Token: See Authentication Token Device: A physical piece of hardware, or a software framework, that hosts symmetric keysDevice ID (DeviceId):DeviceInfo: Aunique identifier for the device, representing the identifying criteria toset of elements whose values combined uniquely identify a device e.g. Manufacture 'Manufacturer and Serialnumber '12345678' Dynamic Provisioning: Usage of a protocol, such as DSKPP, to make a key container available to a recipient Encryption Key: A key used to encrypt key Key: See Cryptographic Key Hardware Token: See Authentication Token Key Algorithm: A well-defined computational procedure that takes variable inputs including a cryptographic key and produces an output. Key Container: An object that encapsulates symmetric keys and their attributes for set of devices Key ID (KeyID): A unique identifier for the symmetric key Key Issuer: An organization that issues symmetric keys to end-users Key Type: The type of symmetric key cryptographic methods for which the key will be used (e.g., OATH HOTP or RSA SecurID authentication, AES encryption, etc.) Secret Key: The symmetric key data Software Token: A type of authentication token that is stored on a general-purpose electronic device such as a desktop computer, laptop, PDA, or mobile phone Token: See Authentication Token User: The person or client to whom devices are issued User ID: A unique identifier for the user or client 3. Use Cases This section describes a comprehensive list of use cases that inspired the development of this specification. These requirements were used to derive the primary requirement that drove the design. These requirements are covered in the next section. These use cases also help in understanding the applicability of this specification to real world situations. 3.1. Online Use Cases This section describes the use cases related to provisioning the keys using an online provisioning protocol such as [DSKPP] 3.1.1. Transport of keys from Server toCrypto ModuleCryptomodule For example, a mobile device user wants to obtain a symmetric key for use with a cryptomodule on the device. The cryptomodule client from vendor A initiates the provisioning process against a provisioning system from vendor B using a standards-based provisioning protocol such as [DSKPP]. The provisioning entity delivers one or more keys in a standard format that can be processed by the mobile device. For example, in a variation of the above, instead of the user's mobile phone, a key is provisioned in the user's soft token application on a laptop using a network-based online protocol. As before, the provisioning system delivers a key in a standard format that can be processed by the soft token on the PC. For example, the end-user or the key issuer wants to update or configure an existing key in the cryptomodule and requests a replacement key container. The container may or may not include a new key and may include new or updated key attributes such as a new counter value in HOTP key case, a modified response format or length, a new friendly name, etc. 3.1.2. Transport of keys fromCrypto ModuleCryptomodule toCrypto ModuleCryptomodule For example, a user wants to transport a key from one cryptomodule to another. There may be two cryptographic modules, one on a computer one on a mobile phone, and the user wants to transport a key from the computer to the mobile phone. The user can export the key and related data in a standard format for input into the other cryptomodule. 3.1.3. Transport of keys fromCrypto ModuleCryptomodule to Server For example, a user wants to activate and use a new key and related data against a validation system that is not aware of this key. This key may be embedded in the cryptomodule (e.g. SD card, USB drive) that the user has purchased at the local electronics retailer. Along with the cryptomodule, the user may get the key on a CD or a floppy in a standard format. The user can now upload via a secure online channel or import this key and related data into the new validation system and start using the key. 3.1.4. Server to server Bulk import/export of keys From time to time, a key management system may be required to import or export keys in bulk from one entity to another. For example, instead of importing keys from a manufacturer using a file, a validation server may download the keys using an online protocol. The keys can be downloaded in a standard format that can be processed by a validation system. For example, in a variation of the above, an OTA key provisioning gateway that provisions keys to mobile phones may obtain key material from a key issuer using an online protocol. The keys are delivered in a standard format that can be processed by the key provisioning gateway and subsequently sent to the end-user's mobile phone. 3.2. Offline Use Cases This section describes the use cases relating to offline transport of keys from one system to another, using some form of export and import model. 3.2.1. Server to server Bulk import/export of keys For example,crypto modulescryptomodules such as OTP authentication tokens, may have their symmetric keys initialized during the manufacturing process in bulk, requiring copies of the keys and algorithm data to be loaded into the authentication system through a file on portable media. The manufacturer provides the keys and related data in the form of a file containing records in standard format, typically on a CD. Note that the token manufacturer and the vendor for the validation system may be the same or different. Some crypto modules will allow local PIN management (the device will have a PIN pad) hence random initial PINs set at manufacturing should be transmitted together with the respective keys they protect. For example, an enterprise wants to port keys and related data from an existing validation system A into a different validation system B. The existing validation system provides the enterprise with a functionality that enables export of keys and related data (e.g. for OTP authentication tokens) in a standard format. Since the OTP tokens are in the standard format, the enterprise can import the token records into the new validation system B and start using the existing tokens. Note that the vendors for the two validation systems may be the same or different. 4. Requirements This section outlines the most relevant requirements that are the basis of this work. Several of the requirements were derived from use cases described above. R1: The format MUST support transport of multiple types of symmetric keys and related attributes for algorithms including HOTP, other OTP, challenge-response, etc. R2: The format MUST handle the symmetric key itself as well of attributes that are typically associated with symmetric keys. Some of these attributes may be * Unique Key Identifier * Issuer information * Algorithm ID * Algorithm mode * Issuer Name * Key friendly name * Event counter value (moving factor for OTP algorithms) * Time value R3: The format SHOULD support both offline and online scenarios. That is it should be serializable to a file as well as it should be possible to use this format in online provisioning protocols such as [DSKPP] R4: The format SHOULD allow bulk representation of symmetric keys R5: The format SHOULD allow bulk representation of PINs related to specific keys R6: The format SHOULD be portable to various platforms. Furthermore, it SHOULD be computationally efficient to process. R7: The format MUST provide appropriate level of security in terms of data encryption and data integrity. R8: For online scenarios the format SHOULD NOT rely on transport level security (e.g., SSL/TLS) for core security requirements. R9: The format SHOULD be extensible. It SHOULD enable extension points allowing vendors to specify additional attributes in the future. R10: The format SHOULD allow for distribution of key derivation data without the actual symmetric key itself. This is to support symmetric key management schemes that rely on key derivation algorithms based on a pre-placed master key. The key derivation data typically consists of a reference to the key, rather than the key value itself. R11: The format SHOULD allow for additional lifecycle management operations such as counter resynchronization. Such processes require confidentiality between client and server, thus could use a common secure container format, without the transfer of key material. R12: The format MUST support the use of pre-shared symmetric keys to ensure confidentiality of sensitive data elements. R13: The format MUST support a password-based encryption (PBE) [PKCS5] scheme to ensure security of sensitive data elements. This is a widely used method for various provisioning scenarios. R14: The format SHOULD support asymmetric encryption algorithms such as RSA to ensure end-to-end security of sensitive data elements. This is to support scenarios where a pre-set shared encryption key is difficult to use. 5. Portable Key container definition The portable key container is based on an XML schema definition and contains the following main entities: 1. KeyContainer entity as defined in Section 5.1 2.DeviceKeyProperties entity as defined in Section 5.2 3. Device entity as defined in Section 5.3 4. Key entity as defined in Section 5.4 Additionally other XML schema types have been defined and are detailed in the relevant subsections of this document A KeyContainer MAY contain one or more Device entities. A Device MAY contain one or more Key entities The figure below indicates a possible relationship diagram of a container. -------------------------------------------- | KeyContainer | | | | -------------------- | | | Keyproperties 1 | | | | | | | -------------------- | | ------------------ ----------------- | | | Device 1 | | Device n | | | | | | | | | | ------------ | | ------------ | | | | | Key 1 | | | | Key n | | | | | ------------ | | ------------ | | | | | | | | | | | | | | | | ------------ | | ------------ | | | | | Key m | | | | Key p | | | | | ------------ | | ------------ | | | ------------------ ----------------- | | | -------------------------------------------- The followingsectionsections describe in detail all the entities and related XML schema elements and attributes: 5.1. KeyContainer The KeyContainer represents the key container entity. A Container MAY contain more than one Device entity; each Device entity MAY contain more than one Key entity. The KeyContainer is defined as follows: <xs:complexType name="KeyContainerType"> <xs:sequence> <xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/> <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType" minOccurs="0"/> <xs:element name="KeyProperties" type="pskc:KeyPropertiesType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Device" type="pskc:DeviceType" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Version" type="pskc:VersionType" use="required"/> <xs:attribute name="ID" type="xs:ID" use="optional"/> </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: o<EncryptionKey (OPTIONAL)>,<EncryptionKey> (OPTIONAL), Identifies the encryption key, algorithm and possible parameters used to protect the Secret Key data in the container. Please see Section 6.1 for detailed description of how to protect key data in transit and the usage of this element. o<MACAlgorithm (OPTIONAL)>,<MACAlgorithm> (OPTIONAL), Identifies the algorithm used to generate a keyed digest of thetheSecret Key data values when protection algorithms are used that do not have integrity checks. The digest guarantees the integrity and the authenticity of the key data. for profile and usage please see Section 6.1.1 o<Device>,<KeyProperties> (OPTIONAL), key property entities containing key related properties that are common for keys within this container. Please see Section 5.2 for detailed description of this element.The KeyContainer MAY contain multiple KeyProperties elements each containing a set of properties related to one or more keys transported within the container. o <Device> (MANDATORY), the host Device for one or more Keys as defined in Section5.25.3 The KeyContainer MAY contain multiple Device data elements, allowing for bulk provisioning of multiple devices each containing multiple keys. o<Signature (OPTIONAL)>,<Signature> (OPTIONAL), the signature value of the Container. When the signature is applied to the entire container, it MUST use XML Signature methods as defined in [XMLDSIG]. It MAY be omitted when application layer provisioning or transport layer provisioning protocols provide the integrity and authenticity of the payload between the sender and the recipient of the container. When required, this specification recommends using a symmetric key based signature with the same key used in the encryption of the secret key data. The signature is enveloped. o<Version (MANDATORY)>,<Extensions> (OPTIONAL), is theversion numberextension 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 theportabledefintion 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.2. KeyProperties The KeyProperties represents common properties shared by more than one keycontainer format (the XML schemaheld 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 inthis document). 5.2.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 representsthean extensible Device entity in the Container. A Device MAY be bound to a user and MAY contain more than onekeys.key. A key SHOULD be bound to only one Device. The Device is defined as follows: <xs:complexType name="DeviceType"> <xs:sequence> <xs:elementname="DeviceId" type="pskc:DeviceIdType"name="DeviceInfo" type="pskc:DeviceInfoType" minOccurs="0"/> <xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/> <xs:elementname="UserId"name="User" type="xs:string" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> The elements of the Device have the following meanings: o<DeviceId>,<DeviceInfo> (OPTIONAL), aunique identifier forset of elements containing information about the device, whose values uniquely identify the device, defined in Section5.2.15.3.1 o<Key>,<Key> (MANDATORY), represents the key entity as defined in Section 5.4 o<UserId>, optionally<User> (OPTIONAL), identifies the owner or the user of the Device, a string representation of a Distinguished Name as defined in [RFC4514]. For example UID=jsmith,DC=example,DC=net. In systems where unique user Ids are used the string representation 'UID=[uniqueId]'MUSTSHOULD be used.5.2.1. DeviceIdo <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: <Extensions> <MyExtension1 definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99>blahblah</YourExtension99> </Extensions> 5.3.1. DeviceInfo TheDeviceIdDeviceInfo represents an extensible set of elements that form the identifying criteria to uniquely identify the device that contains the associated keys. Since devices can come in different form factors such as hardware tokens, smart-cards, soft tokens in a mobile phone or PC etc this element allows different criteria to be used. Combined though the criteria MUST uniquely identify the device. For example for hardware tokens the combination of SerialNo and Manufacturer will uniquely identify a device but not SerialNo alone since two different token manufacturers might issue devices with the same serial number (similar to the IssuerDN and serial number of a certificate). Symmetric Keys used in the payment industry are usually stored on Integrated Circuit Smart Cards. These cards are uniquely identified via the Primary Account Number (PAN, the long number printed on the front of the card) and an expiry date of the card.DeviceIdDeviceInfo is an extensible type that allows all these different ways to uniquely identify a specific key containing device. TheDeviceIdDeviceInfo is defined as follows: <xs:complexTypename="DeviceIdType">name="DeviceInfoType"> <xs:sequence> <xs:element name="Manufacturer" type="xs:string"/> <xs:element name="SerialNo" type="xs:string"/> <xs:element name="Model" type="xs:string" minOccurs="0"/> <xs:element name="IssueNo" type="xs:string" minOccurs="0"/> <xs:elementname="ExpiryDate" type="xs:dateTime"name="DeviceBinding" type="xs:string" 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:complexType> The elements ofDeviceIdDeviceInfo have the following meanings: o<Manufacturer>,<Manufacturer> (MANDATORY), the manufacturer of the device. o<SerialNo>,<SerialNo> (MANDATORY), the serial number of the device or the PAN (primary account number) in case of payment smart cards. o<Model>,<Model> (OPTIONAL), the model of the device(e.g one-button-HOTP-token-V1)(e.g. one-button-HOTP- token-V1) o<IssueNo>,<IssueNo> (OPTIONAL), the issue number in case of smart cards with the same PAN, equivalent to a PSN (PAN Sequence Number). o<ExpiryDate>,<DeviceBinding> (OPTIONAL), theexpiryidentifier that can be used to bind keys to the device or class of device. When loading keys into a device, this identifier can be checked against information obtained from the device to ensure that the correct device or class of device is being used. o <StartDate> (OPTIONAL), the start date of a device (such as the one on a paymentcard,usedcard, 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<StartDate>,<ExpiryDate> (OPTIONAL), thestartexpiry date of a device (such as the one on a paymentcard,usedcard, used when issue numbers are not printed on cards).5.3. KeyProperties The KeyProperties represents common properties shared by more than one key heldMUST be expressed inthe container. If a valueUTC 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 <Extensions> (OPTIONAL), isset in the propertiestheKey element can refer to it via KeyPropertiesId attribute. Values thatextension point for this entity. All extensions arepresent in the Keygrouped under this elementitself MUST take precendence 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: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 meanings: o KeyPropertiesId (MANDATORY), a uniqueandglobal identifier of setwill be ofKeyProperties. The identifier is defined astype pskc:ExtensionType, which contains an optional attribute 'defintion' that can have astring of alphanumeric characters. o <KeyAlgorithm (OPTIONAL)>, the uniqueURIofpointing at thetypedefintion ofalgorithm to use withthesecret key, for profiles are described in Section 6.3 Since KeyProperties are a method to commonalise the elements in Key please refer to section Section 5.4 for detailed descriptionextension. In this way groups ofall elements.extension can be bundled under a subelement. For example: <Extensions> <MyExtension1 definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99>blahblah</YourExtension99> </Extensions> 5.4. Key The Key represents the key entity in the KeyContainer. The Key is defined as follows: <xs:complexType name="KeyType"> <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="FriendlyName" type="xs:string" minOccurs="0"/> <xs:element name="Data"type="pskc:DataType"type="pskc:KeyDataType" minOccurs="0"maxOccurs="unbounded"/>maxOccurs="1"/> <xs:element name="PINPolicy" type="pskc:PINPolicyType" minOccurs="0"/> <xs:elementname="ExpiryDate"name="StartDate" type="xs:dateTime" minOccurs="0"/> <xs:elementname="StartDate"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:attribute name="KeyId" type="xs:string" use="required"/> <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType" use="optional"/> <xs:attributename="KeyPropertiesId" type="xs:string"name="KeyProperties" type="xs:IDREF" use="optional"/> </xs:complexType> The attributes of the Key entity have the following meanings: o KeyId (MANDATORY), a unique and global identifier of the symmetric key. The identifier is defined as a string of alphanumeric characters. This identifier SHOULD be valid globally and outside of the instance document of the container. o<KeyAlgorithm (OPTIONAL)>,KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm to use with the secret key, for profiles are described in Section 6.3 o<KeyPropertiesId (OPTIONAL)>,KeyProperties (OPTIONAL), the references to the unique id of the KeyProperties whose value the instance of this key inherits. If this value is set implementation MUST lookup the Keyproperties element referred to by this unique Id and this instance of key will inherit all values from the KeyProperties. Values held in the key instanceitMUST take precedence over values inherited from KeyProperties."/> The elements of the Key entity have the following meanings: o<Issuer (OPTIONAL)>,<Issuer> (OPTIONAL), The key issuer name, this is normally the name of the organization that issues the key to the end user of the key. For example MyBank issuing hardware tokens to their retail banking users 'MyBank' would be the issuer. The Issuer is defined as a String. o<Usage (MANDATORY)>,<Usage> (OPTIONAL), defines the intended usage of the key and related metadata as defined in Section 5.4.2 o<KeyProfileId (OPTIONAL)>,<KeyProfileId> (OPTIONAL), A unique identifier used between the sending and receiving party of the container to establish a set of constant values related to a key that are not transmitted via the container. For example a smart card application personalisation profile id related to attributes present on a smart card application that have influence when computing a response. An example could be an EMV MasterCard CAP [CAP] application on a card personalised with data for a specific batch of cards such as: IAF Internet authentication flag CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA 13, VISA14) AIP (Application Interchange Profile), 2 bytes TVR Terminal Verification Result, 5 bytes CVR The card verification result AmountOther TransactionDate TerminalCountryCode TransactionCurrencyCode AmountAuthorised IIPB These values are not contained within attributes in the container but are shared between the manufacturing and the validation service through this unique KeyProfileId. The KeyProfileId is defined as a String. o<MasterKeyId (OPTIONAL)>,<MasterKeyId> (OPTIONAL), The unique reference toaan external master key when key derivation schemes are used and no specific key is transported but only the reference to the master key used to derive a specific key and some derivationdata.data (e.g. the PKCS#11 key label in an HSM). o<FriendlyName (OPTIONAL)>,<FriendlyName> (OPTIONAL), The user friendly name that is assigned to the secret key for easy reference. The FriendlyName is defined as a String. o<Data (OPTIONAL)>,<Data> (OPTIONAL), the element carrying the data related to the key as defined in Section 5.4.1 o<PINPolicy (OPTIONAL)>,<PINPolicy> (OPTIONAL), the policy of the PIN relating to the usage of this key as defined in Section 5.4.4 o<ExpiryDate (OPTIONAL)>,<StartDate> (OPTIONAL), theexpirystart date of the key, it MUST not be possible to use this keyafterbefore thisdatedate. 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)>,<ExpiryDate> (OPTIONAL), thestartexpiry date of the key, it MUST not be possible to use this keybeforeafter thisdate 5.4.1. Data (OPTIONAL) Definesdate. 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 <UserId> (OPTIONAL), identifies thedata attributes ofuser account (e.g. username or user id) to which thesymmetric key. Eachkey isa nameassigned. The valuepair which has eitherMAY be aplain value (in casestring representation ofno encryption) oraencrypted valueDistinguished Name as defined inEncryptedDataType[RFC4514]. For example "UID=jsmith,DC=example,DC=net". In systems where unique user Ids are used the string representation 'UID=[uniqueId]' SHOULD be used. o <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: <Extensions> <MyExtension1 definition="http://ACME/MyExtension1.html">blah</Myextension1> <YourExtension99>blahblah</YourExtension99> </Extensions> 5.4.1. KeyData Defines an extensible set of data elements relating to a key including the key value itself (secret). After considerable discussions in forums and at IETF the authors needed a mean to convey data related to a key in an extensible form. The requirements were that the data elements could be encrypted but not via XMLEncryption.encryption which was deemed to complex because of canonicalization. Hence earlier drafts made use of a list of name value pairs. Thisiswas not considered to be very XML like and alsowherelacked inbuilt support for typing. Hence thekey valuecurrent apporach istransported, Section 7 definesto have within KeyData alistset ofreserved attribute names.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:complexTypename="DataType">name="intDataType"> <xs:sequence> <xs:choice> <xs:element name="PlainValue"type="xs:base64Binary"/>type="xs:int"/> <xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/> </xs:choice> <xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/> </xs:sequence><xs:attribute name="Name" type="xs:string" use="required"/></xs:complexType> Theattributesfollowing typed base types have been defined within the current schema of theDataPSKC 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 elementhaveis of type xs:integer. When encrypted thefollowing meanings: o Name, definesbinary 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 thenamebinary 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 thename-value pair, Section 7 defines a listbinary 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 ofreserved attribute namesthis 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> The elements of the Data element have the following meanings: oThe <PlainValue> conveys an unencrypted<Secret> (OPTIONAL), the value of thename-value pairkey itself inbase 64 encoding.binary. oThe <EncryptedValue> element in the DataType conveys an encrypted value of<Counter> (OPTIONAL), thename-value pair inside an EncryptedDataType as defined in XML Encryption.event counter for event based OTP algorithms. oThe <ValueMAC (OPTIONAL)><Time> (OPTIONAL), the time for time based OTP algorithms. (If time interval is used, this elementincarries theDataType conveysnumber of time intervals passed from akeyed MACspecific start point, normally algorithm dependent) o <TimeInterval> (OPTIONAL), the time interval valueoffor time based OTP algorithms. o <TimeDrift> (OPTIONAL), theunencrypted datadevice clock drift value for time based OTP algorithms. The value indicates number of seconds that thecases wheredevice clock may drift each day. o <xs:any ..> thealgorithm to protect key data in transit,extension point for carrying future elements. Please note that all elements added MUST carry PlainValue and EncryptedValue sub eleemnts as describedin section Section 6.1.1 ,does not support integrity checks.above. 5.4.2. Usage(MANDATORY)The Usage element defines the usage attribute(s) of the key entity. Usage is defined as follows: <xs:complexType name="UsageType"> <xs:sequence> <xs:element name="ChallengeFormat" minOccurs="0"> <xs:complexType> <xs:attribute name="Format" type="pskc:ValueFormatType" use="required"/> <xs:attribute name="Min" type="xs:unsignedInt" use="required"/> <xs:attribute name="Max" type="xs:unsignedInt" use="required"/> <xs:attribute name="CheckDigits" type="xs:boolean" default="false"/> </xs:complexType> </xs:element> <xs:element name="ResponseFormat"> <xs:complexType> <xs:attribute name="Format" type="pskc:ValueFormatType" use="required"/> <xs:attribute name="Length" type="xs:unsignedInt" use="required"/> <xs:attribute name="CheckDigits" type="xs:boolean" default="false"/> </xs:complexType> </xs:element> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="OTP" type="xs:boolean" default="false"/> <xs:attribute name="CR" type="xs:boolean" default="false"/> <xs:attribute name="Integrity" type="xs:boolean" default="false"/> <xs:attribute name="Encrypt" type="xs:boolean" default="false"/> <xs:attribute name="Unlock" type="xs:boolean" default="false"/> <xs:anyAttribute namespace="##other"/> </xs:complexType> The attributes of the Usage element define the intended usage of thekey andkey. This list of attributes is extensible for future needs. They are a combination of one or more of the following (set to true): o OTP, the key will be used for OTP generation o CR, the key will be used for Challenge/Response 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 for data integrity or authentication purposes. 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 many times (for devices with PIN-input capability) 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(OPTIONAL)When the intended usage of a key usage is OTP and/or CR, the following additional elements MUST be provided within the Usage element to support the OTP and/or the response computation as required by the underlying algorithm. These elements also allowto customizecustomizing orconfigureconfiguring the result of the computation (e.g. format, length). 5.4.2.1.1. ChallengeFormat element(MANDATORY)(OPTIONAL) The ChallengeFormat element defines the characteristics of the challenge in a CR usage scenario. The Challenge element is defined by the following attributes: o Format(MANDATORY) Defines(MANDATORY), defines the format of the challenge accepted by the device and MUST be one of the values defined in Section 5.4.3 o CheckDigit(OPTIONAL) Defines(OPTIONAL), defines if the device needs to check the appended Luhn check digit contained in a provided challenge. This is only valid if the Format attribute is 'DECIMAL'. Value MUST be: TRUE device will check the appended Luhn check digit in a provided challenge FALSE device will not check appended Luhn check digit in challenge o Min(MANDATORY) Defines(MANDATORY), defines the minimum size of the challenge accepted by the device for CR mode. If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or '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 MUSTbe:be Unsigned integer. o Max(MANDATORY) Defines(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 MUSTbe:be Unsigned integer. 5.4.2.1.2. ResponseFormat element (MANDATORY) The ResponseFormat element defines the characteristics of the result of a computation. This defines the format of the OTP or of the response to a challenge. For cases where the key is a PIN value, this element contains the format of the PIN itself (e.g. DECIMAL, length 4 for a 4 digit PIN). The Response attribute is defined by the following attributes: o Format(MANDATORY) Defines(MANDATORY), defines the format of the response generated by the device and MUST be one of the values defined in Section 5.4.3 o CheckDigit(OPTIONAL) Defines(OPTIONAL), defines if the device needs to append a Luhn check digit to the response. This is only valid if the Format attribute is 'DECIMAL'. Value MUST be: TRUE device will append a Luhn check digit to the response. FALSE device will not append a Luhn check digit to the response. o Length(MANDATORY) Defines(MANDATORY), defines the length of the response generated by the device. If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number ofdigits/ characters.digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value. Value MUSTbe:be Unsigned integer. 5.4.3. ValueFormat The ValueFormat element defines allowed formats for challenges or responses in OTP algorithms. ValueFormat is defined as follows: <simpleType name="ValueFormat"> <restriction base="string"> <enumeration value="DECIMAL"/> <enumeration value="HEXADECIMAL"/> <enumeration value="ALPHANUMERIC"/> <enumeration value="BASE64"/> <enumeration value="BINARY"/> </restriction> </simpleType>DECIMALDECIMAL, Only numerical digitsHEXADECIMALHEXADECIMAL, Hexadecimal responseALPHANUMERICALPHANUMERIC, All letters and numbers (case sensitive)BASE64BASE64, Base 64 encodedBINARYBINARY, Binary data, this is mainly used in case of connected devices 5.4.4. PINPolicy The PINPolicy element providesaan extensible mean to define how the usage of a specific key is protected by a PIN. The PIN itself can be transmitted as a key using the container. If the PINPolicy element is present in the Key element then the key 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: <xs:complexType name="PINPolicyType"> <xs:sequence> <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/> <xs:elementname="WrongPINtry"name="MaxFailedAttempts" type="xs:unsignedInt" 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:attribute name="PINKeyId" type="xs:string"use="required"/>use="optional"/> </xs:complexType> The attributes of PINPolicy have the following meaning oPINKeyId,PINKeyId (OPTIONAL), the unique key Id of the key held within this container that contains the value of the PIN that protects the key The elements of PINPolicy have the following meaning o<PINUsageMode (MANDATORY)><PINUsageMode> (MANDATORY) , the way the PIN is used during the usage of the key as defined in Section 5.4.4.1 o<WrongPINtry (OPTIONAL)>,<MaxFailedAttempts> (OPTIONAL), the maximum number of times the PIN can be entered wrongly before it MUST not be possible to use 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 The PINUsageMode element defines how the PIN is used with a specifickeykey. The PINUsageMode element also has an extension point defined as xs:any to allow future extensibility PINUsageMode is defined as follows: <xs:complexType name="PINUsageModeType"> <xs:choice maxOccurs="unbounded"> <xs:element name="Local"/> <xs:element name="Prepend"/> <xs:elementname="InAlgo"/>name="Append"/> <xs:element name="Algorithmic"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:complexType> The elements of PINPolicy have the following meaning o <Local>, the PIN is checked locally on the device before allowing the key to be used in executing the algorithm o <Prepend>, the PIN is prepended to the OTP or responsehancehence it MUST be checked by the validation server o <Append>, the PIN is appended to the OTP or response hence it MUST bechackedchecked by the validation server o<InAlgo>,<Algorithmic>, the PIN is used as part of the algorithm computation 6. Usage and profile of algorithms for the portable symmetric key container This section details the use of the XML encryption and XML signature elements to protect the keys transported in thecotainer.container. It also profiles the number of algorithms supported by XML encryption and XML signature to a mandatory subset for interoperability. When no algorithm is provided the values within the container are unencrypted, implementations SHALL ensure the privacy of the key data through other standard mechanisms e.g. transport level encryption. 6.1. Usage of EncryptionKey to protect keys in transit The EncryptionKey element in the KeyContainer defines the key, algorithm and parameters used to encrypt the Secret Key data attributes in the Container. The standard schema [XMLENC] is adopted in carry such information and an encrypted value. The encryption is applied on each individual Secret Key data in the Container. The encryption method MUST be the same for all Secret Key data in the container. The following sections define specifically the different supported means to protect the keys: 6.1.1. Protecting keys using a pre-shared key via symmetric algorithms When protecting the payload with pre-shared keys implementations SHOULD set the name of the specific pre-shared key in the KeyName element of the EncryptionKey of the KeyContainer. For example: <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:xenc="http://www.w3.org/2001/04/xmlenc#"> <EncryptionKey> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName> </EncryptionKey> .... The following is the list of symmetric key encryption algorithm and possible parameters used to protect the Secret Key data in the container. Systems implementing PSKC MUST support the MANDATORY algorithms detailed below. The encryption algorithm URI can be one of the following. o http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY o http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY o http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL o http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY o http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY o http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY o http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY o http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL When algorithms without integrity checks are used (e.g. http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value using the same key as the encryption key SHOULD be placed in the ValueMAC element of the Data element. In this case the MAC algorithm type MUST be set in the MACAlgorithm element in the key container entity as defined in Section 5.1. Implementations of PSKC MUST support the MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be one of the following: o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY For example: <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: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> ..... 6.1.2. Protecting keys using passphrase based encryption keys To be able to support passphrase based encryption keys as defined in PKCS#5 the following XML representation of the PBE relates parameters have been introduced in the schema. Although the approach is extensible implementations of PSKC MUST support the KeyDerivationMethod algorithm URI of http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2. <xs:complexType name="DerivedKeyType"> <xs:sequence> <xs:element name="KeyDerivationMethod" type="pskc:KeyDerivationMethodType" minOccurs="0"/> <xs:element ref="xenc:ReferenceList" minOccurs="0"/> <xs:element name="CarriedKeyName" type="xs:string" minOccurs="0"/> </xs:sequence> <xs:attribute name="Id" type="xs:ID" use="optional"/> <xs:attribute name="Type" type="xs:anyURI" use="optional"/> </xs:complexType> <xs:complexType name="KeyDerivationMethodType"> <xs:sequence> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType> The attributes of the DerivedKey have the following meanings: o ID (OPTIONAL), the unique ID for this key o Type (OPTIONAL), This attribute was included for conformance with xml encryption, it is an optional attribute identifying type information about the plaintext form of the encrypted content. Please see [XMLENC] section 3.1 Type for more details. The elements of the DerivedKey have the following meanings: o <KeyDerivationMethod>: URI of the algorithms used to derive the key e.g. (http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2) o<ReferenceList (OPTIONAL)>:<ReferenceList> (OPTIONAL): a list of IDs of the elements that have been encrypted by this key o<CarriedKeyName (OPTIONAL)>:<CarriedKeyName> (OPTIONAL): friendly name of the key When using the PKCS5 PBE algorithm (URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2) and related parameters, the DerivedKey element MUST be used within the EncryptionKey element of the KeyContainer in exactly the form as shown below: <?xml version="1.0" encoding="UTF-8"?> <KeyContainerxmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pkcs-5= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0"> <EncryptionKey> <DerivedKey Id="#Passphrase1"> <CarriedKeyName>Passphrase1</CarriedKeyName> <KeyDerivationMethod Algorithm= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> <Parameters xsi:type="pkcs-5:PBKDF2ParameterType"> <Salt> <Specified>Df3dRAhjGh8=</Specified> </Salt> <IterationCount>2000</IterationCount> <KeyLength>16</KeyLength> <PRF/> </Parameters> </KeyDerivationMethod> </DerivedKey> </EncryptionKey> .... 6.2. Protecting keys using asymmetric algorithms The following is the list of asymmetric key encryption algorithm and possible parameters used to protect the Secret Key data in the container. Systems implementing PSKC MUST support the MANDATORY algorithms detailed below. The encryption algorithm URI can be one of the following. o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL For example: <?xml version="1.0" encoding="UTF-8"?> <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:xenc="http://www.w3.org/2001/04/xmlenc#"> <pskc:EncryptionKey> <ds:X509Data> <ds:X509Certificate>miib</ds:X509Certificate> </ds:X509Data> </pskc:EncryptionKey> <pskc:Device><pskc:DeviceId> <pskc:Manufacturer>ACME</pskc:Manufacturer><pskc:DeviceInfo> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:SerialNo>0755225266</pskc:SerialNo></pskc:DeviceId></pskc:DeviceInfo> <pskc:Key KeyAlgorithm= "http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Usage OTP="true"> <pskc:ResponseFormat Length="8" Format="DECIMAL"/> </pskc:Usage><pskc:Data Name="COUNTER"> <pskc:PlainValue>AprkuA==</pskc:PlainValue> </pskc:Data> <pskc:Data Name="SECRET"><pskc:Data> <pskc:Secret> <pskc:EncryptedValue Id="ED"> <xenc:EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> <xenc:CipherData> <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= </xenc:CipherValue> </xenc:CipherData> </pskc:EncryptedValue> </pskc:Secret> <pskc:Counter> <PlainValue>0</PlainValue> </pskc:Counter> </pskc:Data> </pskc:Key> </pskc:Device> </pskc:KeyContainer> 6.3. Profile of Key Algorithm This section profiles the type(s) of algorithm of that can be used by the key(s) transported in the container. The following algorithm URIs are among the default support list. o http://www.w3.org/2001/04/xmlenc#tripledes-cbc o http://www.w3.org/2001/04/xmlenc#aes128-cbc o http://www.w3.org/2001/04/xmlenc#aes192-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#pin 6.3.1. OTP Key Algorithm Identifiers OTP key algorithm URIs have not been defined in a commonly available standard specification. This documentdefinesrequests from IANA thefollowingcreation of a registry (see Section 8.4) and defines URIs for the standard OTP algorithmsdefinedin[HOTP]. 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-AESSection 8.4.4. 6.3.2. PIN key value compare algorithm identifier PIN key algorithm URIs have not been defined in a commonly available standard specification. This document defines the following URIs for a straight valuecomaprisoncomparison of the transported secret key data as when required to compare a PIN. Identifier: http://www.ietf.org/keyprov/pskc#pin Note that the actual URL will be finalized once a URL for this document is determined. 7.Reserved data attribute names 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 format as defined by a W3C recommendation (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax definition in the XML Schema Definition format (XSD) All implementations of this standard must comply with the schema below. <?xml version="1.0" encoding="UTF-8"?> <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: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" version="1.0"> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation= "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ xmldsig-core-schema.xsd"/> <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"schemaLocation="http://www.w3.org/TR/2002/ REC-xmlenc-core-20021210/xenc-schema.xsd"/>schemaLocation="http://www.w3.org/TR/ xmlenc-core/xenc-schema.xsd"/> <xs:complexType name="KeyContainerType"> <xs:sequence> <xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/> <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType" minOccurs="0"/> <xs:element name="KeyProperties" type="pskc:KeyPropertiesType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Device" type="pskc:DeviceType" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Version" type="pskc:VersionType" use="required"/> <xs:attribute name="ID" type="xs:ID" use="optional"/> </xs:complexType> <xs:simpleType name="VersionType" final="restriction"> <xs:restriction base="xs:string"> <xs:pattern value="\d{1,2}\.\d{1,3}"/> </xs:restriction> </xs:simpleType> <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:DataType"type="pskc:KeyDataType" minOccurs="0"maxOccurs="unbounded"/>maxOccurs="1"/> <xs:element name="PINPolicy" type="pskc:PINPolicyType" minOccurs="0"/> <xs:elementname="ExpiryDate"name="StartDate" type="xs:dateTime" minOccurs="0"/> <xs:elementname="StartDate"name="ExpiryDate" type="xs:dateTime" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attributename="KeyPropertiesId" type="xs:string"name="ID" type="xs:ID" use="required"/> <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType" use="optional"/> </xs:complexType> <xs:complexType name="KeyType"> <xs:sequence> <xs:element name="Issuer" type="xs:string" minOccurs="0"/> <xs:element name="Usage" type="pskc:UsageType"/> <xs:element name="KeyProfileId" type="xs:string" minOccurs="0"/> <xs:element name="MasterKeyId" type="xs:string" minOccurs="0"/> <xs:element name="FriendlyName" type="xs:string" minOccurs="0"/> <xs:element name="Data"type="pskc:DataType"type="pskc:KeyDataType" minOccurs="0"maxOccurs="unbounded"/>maxOccurs="1"/> <xs:element name="PINPolicy" type="pskc:PINPolicyType" minOccurs="0"/> <xs:elementname="ExpiryDate"name="StartDate" type="xs:dateTime" minOccurs="0"/> <xs:elementname="StartDate"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:attribute name="KeyId" type="xs:string" use="required"/> <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType" 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 name="DerivedKeyType"> <xs:sequence> <xs:element name="KeyDerivationMethod" type="pskc:KeyDerivationMethodType" minOccurs="0"/> <xs:element ref="xenc:ReferenceList" minOccurs="0"/> <xs:element name="CarriedKeyName" type="xs:string" minOccurs="0"/> </xs:sequence> <xs:attribute name="Id" type="xs:ID" use="optional"/> <xs:attribute name="Type" type="xs:anyURI" use="optional"/> </xs:complexType> <xs:complexType name="KeyDerivationMethodType"> <xs:sequence> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType> <xs:complexType name="PINPolicyType"> <xs:sequence> <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/> <xs:elementname="WrongPINtry"name="MaxFailedAttempts" type="xs:unsignedInt" 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:attribute name="PINKeyId" type="xs:string"use="required"/>use="optional"/> </xs:complexType> <xs:complexType name="PINUsageModeType"> <xs:choice maxOccurs="unbounded"> <xs:element name="Local"/> <xs:element name="Prepend"/> <xs:elementname="Embed"/>name="Append"/> <xs:element name="Algorithmic"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:complexType> <xs:complexTypename="DeviceIdType">name="DeviceInfoType"> <xs:sequence> <xs:element name="Manufacturer" type="xs:string"/> <xs:element name="SerialNo" type="xs:string"/> <xs:element name="Model" type="xs:string" minOccurs="0"/> <xs:element name="IssueNo" type="xs:string" minOccurs="0"/> <xs:elementname="ExpiryDate" type="xs:dateTime"name="DeviceBinding" type="xs:string" 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:complexType> <xs:complexType name="DeviceType"> <xs:sequence> <xs:elementname="DeviceId" type="pskc:DeviceIdType"name="DeviceInfo" type="pskc:DeviceInfoType" minOccurs="0"/> <xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/> <xs:elementname="UserId"name="User" type="xs:string" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="UsageType"> <xs:sequence> <xs:element name="ChallengeFormat" minOccurs="0"> <xs:complexType> <xs:attribute name="Format" type="pskc:ValueFormatType" use="required"/> <xs:attribute name="Min" type="xs:unsignedInt" use="required"/> <xs:attribute name="Max" type="xs:unsignedInt" use="required"/> <xs:attribute name="CheckDigits" type="xs:boolean" default="false"/> </xs:complexType> </xs:element> <xs:element name="ResponseFormat"> <xs:complexType> <xs:attribute name="Format" type="pskc:ValueFormatType" use="required"/> <xs:attribute name="Length" type="xs:unsignedInt" use="required"/> <xs:attribute name="CheckDigits" type="xs:boolean" default="false"/> </xs:complexType> </xs:element> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="OTP" type="xs:boolean" default="false"/> <xs:attribute name="CR" type="xs:boolean" default="false"/> <xs:attribute name="Integrity" type="xs:boolean" default="false"/> <xs:attribute name="Encrypt" type="xs:boolean" default="false"/> <xs:attribute name="Unlock" type="xs:boolean" default="false"/> <xs:anyAttribute namespace="##other"/> </xs:complexType> <xs:complexTypename="DataType">name="ExtensionsType"> <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:any namespace="##other" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:attributename="Name" type="xs:string" use="required"/>name="definition" type="xs:anyURI" use="optional"/> </xs:complexType> <xs:simpleType name="KeyAlgorithmType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> <xs:simpleType name="ValueFormatType"> <xs:restriction base="xs:string"> <xs:enumeration value="DECIMAL"/> <xs:enumeration value="HEXADECIMAL"/> <xs:enumeration value="ALPHANUMERIC"/> <xs:enumeration value="BASE64"/> <xs:enumeration value="BINARY"/> </xs:restriction> </xs:simpleType> <xs:element name="KeyContainer" type="pskc:KeyContainerType"/> </xs:schema>9.8. IANA Considerations9.1.8.1. Content-type registration for 'application/pskc+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023]. MIME media type name: application MIME subtype name: pskc+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2. Security considerations: This content type is designed to carry PSKC protocol payloads. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] Applications which use this media type: This MIME type is being used as a symmetric key container format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. As such, it is used for key provisioning systems. Additional information: Magic Number: None File Extension: .pskcxml Macintosh file type code: 'TEXT' Personal and email address for further information: Philip Hoyer, Philip.Hoyer@actividentity.com Intended usage: LIMITED USE Author: This specification is a work item of the IETF KEYPROV working group, with mailing list address <keyprov@ietf.org>. Change controller: The IESG <iesg@ietf.org>9.2.8.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI:urn:ietf:params:xml:ns:keyprov:container:1.0urn:ietf:params:xml:ns:keyprov:pskc:1.0 Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com). XML Schema: The XML schema to be registered is contained in Section8.7. Its first line is <?xml version="1.0" encoding="UTF-8"?> and its last line is </xs:schema>9.3.8.3. URN Sub-Namespace Registration forurn:ietf:params:xml:ns:keyprov:container:1.0urn:ietf:params:xml:ns:keyprov:pskc:1.0 This section registers a new XML namespace,"urn:ietf:params:xml:ns:keyprov:container:1.0","urn:ietf:params:xml:ns:keyprov:pskc:1.0", per the guidelines in [RFC3688]. URI:urn:ietf:params:xml:ns:keyprov:container:1.0urn:ietf:params:xml:ns:keyprov:pskc:1.0 Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com). XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>PSKC Namespace</title> </head> <body> <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 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]</a>.</p> </body> </html> END9.4.8.4. Symmetric Key Algorithm Identifier Registry This specification requests the creation of a new IANA registry for symmetric key cryptographic algorithm identifiers in accordance with the principles set out in RFC 2434 [RFC2434]as follows:9.4.1.8.4.1. Applicability The use of URIs as algorithm identifiers provides an effectively unlimited namespace. While this eliminates the possibility of namespace exhaustion it creates a new concern, that divergent identifiers will be employed for the same purpose in different contexts. The key algorithm registry is intended to provide a means of specifying the canonical identifier to be used for a given algorithm. If an algorithm has an identifier specified in the registryaan application that is conformant to a protocol specification that specifies use of that registry to define identifiers SHOULD always use that particular form of the identifier when originating data. A conformant application MAY accept other identifiers in data that is received. For the sake of expediency, the initial registry only defines algorithm classes for symmetric algorithms plus cryptographic message digest functions (one-way hash). While the same principles may be extended to asymmetric algorithms, doing so would require much greater consideration of issues such as key length and treatment of parameters, particularly whereelipticelliptic curve cryptography algorithms are concerned. As part of this registry the IANA will maintain the following information: Common Name The name by which the algorithm is generally referred. Class The type of algorithm, encryption, Message Authentication Code (MAC), One TimePawwordPassword (OTP), Digest, etc.CannonicalCanonical URI Thecannonicalcanonical URI to be used to identify the algorithm. Algorithm Definition A reference to the document in which the algorithm described by the identifier is defined. Identifier Definition A reference to the document in which the use of the identifier to refer to the algorithm is described. This would ideally be the document in which the algorithm 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]. Note that where a single algorithm has different forms distinguished byparemetersparameters such as key length, the algorithm class and each combination of algorithm parameters may be considered a distinct algorithm for the purpose of assigning identifiers.9.4.2.8.4.2. Registerable Algorithms9.4.2.1.8.4.2.1. Assigned URIs If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:xml:<class>:<id> will be assigned where <class> is the type of the algorithm being 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 algorithm 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 assignmentinthein the IETF namespace. IETF consensus is not required.9.4.2.2.8.4.2.2. Assigned Classes Each algorithm MUST belong to an assigned algorithm class. In the case that additional classes are required these are to be specified by IETF Consensus action. The initial assigned classes are: Digest A cryptographic Digest algorithm. MAC A Message Authentication Code algorithm. Symmetric A symmetric encryption algorithm. OTP A one time password (OTP) algorithm.9.4.3.8.4.3. Registration Procedures9.4.3.1.8.4.3.1. Review Algorithm identifier registrations are to be subject to Expert Review as per RFC 2434 [RFC2434]. The need for supporting documentation for the registration depends on 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 URI allocation would normally appear within the RFC itself. In the case of a cryptographic algorithm that is fully and comprehensively defined in another form, it would not be necessary to duplicate the information for the sake of issuing the information in the RFC series. In other cases an RFC may be required in order to ensure that certain algorithm parameters are sufficiently and unambiguously defined. The scope of such expert review is to be strictly limited to identifying possible ambiguity and/or duplication of existing identifiers. The expert review MUST NOT consider the cryptographic properties, intellectual property considerations or any other factor not related to the use of the identifier. In reviewing a request, the expert should consider whether other URI identifiers are already defined for a given algorithm. In such cases it is the duty of the expert to bring the potential duplication to the notice of the proposers of the registration and the Security Area Directors. If the proposers are not willing to accept registration of the existing identifier the IETF Consensus policy is to apply. In reviewing a request, the expert should consider whether the algorithm is sufficiently defined to allow successful interoperation. In particular the expert should consider whether issues such as key sizes and byte order are sufficiently defined to allow for interoperation. While thedefintiondefinition requirement MAY besatisifedsatisfed by a comprehensive specification of the algorithm, disclosure of the algorithm is not mandatory.9.4.3.2.8.4.3.2. Canonical URI 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 The name by which the algorithm is generally referred. Class The type of algorithm, encryption, Message Authentication Code (MAC), One TimePawwordPassword (OTP), Digest, etc. As specified by a defined algorithm class. URI Thecannonicalcanonical URI to be used to identify the algorithm. Algorithm Definition A reference to the document in which the algorithm described by the identifier is defined. Identifier Definition A reference to the document in which the use of the identifier to refer to the algorithm is described. This would ideally be the document in which the algorithm is defined. Registrant Contact A reference to the document in which the use of the identifier to refer to the algorithm is described. This would ideally be the document in which the algorithm is defined.9.4.3.3.8.4.3.3. Alias URI In the case that multiple identifiers have been assigned to the same identifiers, additional identifiers MAY be registered as aliases. An 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: Alias for URI Thecannonicalcanonical URI that identifies the algorithm. The URI referenced MUST be a canonical URI. In the case of dispute as to which URI is to be considered canonical the matter is to be settled by IESG action.9.4.4.8.4.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.4.4.1.8.4.4.1. HOTP Common Name: HOTP Class: OTP URI: http://www.ietf.org/keyprov/pskc#hotp Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt Identifier Definition (this RFC) Registrant Contact: IESG9.4.4.2. HOTP-HMAC-SHA-18.4.4.2. OCRA (OATH Chellenge Response Algorithm) Common Name:HOTP-HMAC-SHA-1OCRA Class: OTP URI:http://www.ietf.org/rfc/rfc4226.txt#HOTP-HMAC-SHA-1http://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.txthttp://www.ietf.org/internet-drafts/ draft-mraihi-mutual-oath-hotp-variants-07.txt Identifier Definition (this RFC) Registrant Contact: IESG 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: IESG9.4.4.3.8.4.4.4. KEYPROV-PIN Common Name: KEYPROV-PIN Class: Symmetric static credential comparison URI: http://www.ietf.org/keyprov/pskc#pin Algorithm Definition: (this document) Identifier Definition (this document) Registrant Contact: IESG9.4.4.4.8.4.4.5. SecurID-AES Common Name: SecurID-AES Class: OTP URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ otps-wst#SecurID-AES Algorithm 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 EMC, <andrea.doherty@rsa.com>9.4.4.5.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 Class: OTP URI: http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ otps-wst#SecurID-ALGOR Algorithm 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 EMC, <andrea.doherty@rsa.com>9.4.4.6.8.4.4.8. ActivIdentity-3DES Common Name: ActivIdentity-3DES Class: OTP URI: http://www.actividentity.com/2008/04/algorithms/ algorithms#ActivIdentity-3DES Algorithm Definition: http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-3DES Identifier Definition http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-3DES Registrant Contact: Philip Hoyer, ActivIdentity Inc, <philip.hoyer@actividentity.com>9.4.4.7.8.4.4.9. ActivIdentity-AES Common Name: ActivIdentity-AES Class: OTP URI: http://www.actividentity.com/2008/04/algorithms/ algorithms#ActivIdentity-AES Algorithm Definition: http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-AES Identifier Definition http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-AES Registrant Contact: Philip Hoyer, ActivIdentity Inc, <philip.hoyer@actividentity.com>9.4.4.8.8.4.4.10. ActivIdentity-DES Common Name: ActivIdentity-DES Class: OTP URI: http://www.actividentity.com/2008/04/algorithms/ algorithms#ActivIdentity-DES Algorithm Definition: http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-DES Identifier Definition http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-DES Registrant Contact: Philip Hoyer, ActivIdentity Inc, <philip.hoyer@actividentity.com>9.4.4.9.8.4.4.11. ActivIdentity-EVENT Common Name: ActivIdentity-EVENT Class: OTP URI: http://www.actividentity.com/2008/04/algorithms/ algorithms#ActivIdentity-EVENT Algorithm Definition: http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-EVENT Identifier Definition http://www.actividentity.com/2008/04/ algorithms/algorithms#ActivIdentity-EVENT Registrant Contact: Philip Hoyer, ActivIdentity Inc, <philip.hoyer@actividentity.com>9.5. XML Data Tag Identifier Registry 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.9. Security Considerations The portable key container carries sensitive information (e.g., cryptographic keys) and may be transported across the boundaries of one secure perimeter to another. For example, a container residing within the secure perimeter of a back-end provisioning server in a secure room may be transported across the internet to an end-user device attached to a personal computer. This means that special care must be taken to ensure the confidentiality, integrity, and authenticity of the information contained within.10.1.9.1. Payload confidentiality By design, the container allows two main approaches to guaranteeing the confidentiality of the information it contains while transported. First, the container key data payload may be encrypted. In this case no transport layer security is required. However, standard security best practices apply when selecting the strength of the cryptographic algorithm for payload encryption. Symmetric cryptographic cipher should be used - the longer the cryptographic key, the stronger the protection. At the time of this writing both 3DES and AES are mandatory algorithms but 3DES may be dropped in the relatively near future. Applications concerned with algorithm longevity are advised to use AES-256-CBC. In cases where the exchange of encryption keys between the sender and the receiver is not possible, asymmetric encryption of the secret key payload may be employed. Similarly to symmetric key cryptography, the stronger the asymmetric key, the more secure the protection is. If the payload is encrypted with a method that uses one of the password-based encryption methods provided above, the payload may be subjected to password dictionary attacks to break the encryption password and recover the information. Standard security best practices for selection of strong encryption passwords apply [Schneier]. Practical implementations should use PBESalt and PBEIterationCount when PBE encryption is used. Different PBESalt value per key container should be used for best protection. The second approach to protecting the confidentiality of the payload is based on using transport layer security. The secure channel established between the source secure perimeter (the provisioning server from the example above) and the target perimeter (the device attached to the end-user computer) utilizes encryption to transport the messages that travel across. No payload encryption is required in this mode. Secure channels that encrypt and digest each message provide an extra measure of security, especially when the signature of the payload does not encompass the entire payload. Because of the fact that the plain text payload is protected only by the transport layer security, practical implementation must ensure protection against man-in-the-middle attacks [Schneier]. Validating the secure channel end-points is critically important for eliminating intruders that may compromise the confidentiality of the payload.10.2.9.2. Payload integrity The portable symmetric key container provides a mean to guarantee the integrity of the information it contains through digital signatures. For best security practices, the digital signature of the container should encompass the entire payload. This provides assurances for the integrity of all attributes. It also allows verification of the integrity of a given payload even after the container is delivered through the communication channel to the target perimeter and channel message integrity check is no longer possible.10.3.9.3. Payload authenticity The digital signature of the payload is the primary way of showing its authenticity. The recipient of the container may use the public key associated with the signature to assert the authenticity of the sender by tracing it back to a preloaded public key or certificate. Note that the digital signature of the payload can be checked even after the container has been delivered through the secure channel of communication. A weaker payload authenticity guarantee may be provided by the transport layer if it is configured to digest each message it transports. However, no authenticity verification is possible once the container is delivered at the recipient end. This approach may be useful in cases where the digital signature of the container does not encompass the entire payload.11.10. Acknowledgements The authors of this draft would like to thank the following people for their contributions and support to make this a better specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses,andAndersRundgren. 12.Rundgren, Sean Turner and especially Robert Philpott. 11. Appendix A - Example Symmetric Key Containers All examples are syntactically correct and compatible with the XML schema in section 7.12.1.11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret Key <?xml version="1.0" encoding="UTF-8"?> <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><DeviceId> <Manufacturer>ACME</Manufacturer> <SerialNo>0755225266</SerialNo> </DeviceId><DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>987654321</SerialNo> </DeviceInfo> <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"KeyId="0755225266"> <Issuer>AnIssuer</Issuer>KeyId="987654321"> <Issuer>Issuer</Issuer> <Usage OTP="true"> <ResponseFormatLength="6"Length="8" Format="DECIMAL"/> </Usage><Data Name="COUNTER"> <PlainValue>AprkuA==</PlainValue> </Data> <Data Name="SECRET"> <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue><Data> <Secret> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= </PlainValue> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data><ExpiryDate>2012-12-31T00:00:00</ExpiryDate></Key> </Device> </KeyContainer>12.2.11.2. Symmetric Key Container with a single PIN protected Non-Encrypted HOTP Secret Key <?xml version="1.0" encoding="UTF-8"?> <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><DeviceId> <Manufacturer>ACME</Manufacturer><DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>0755225266</SerialNo></DeviceId></DeviceInfo> <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <Issuer>AnIssuer</Issuer> <Usage OTP="true"> <ResponseFormat Length="6" Format="DECIMAL"/> </Usage><Data Name="COUNTER"> <PlainValue>AprkuA==</PlainValue> </Data> <Data Name="SECRET"> <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue><Data> <Secret> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= </PlainValue> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data> <PINPolicy PINKeyId="07552252661"> <PINUsageMode> <Local/> </PINUsageMode> </PINPolicy> </Key> <Key KeyId="07552252661" KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin"> <Usage> <ResponseFormat Length="4" Format="DECIMAL"/> </Usage><Data Name="SECRET"> <PlainValue>MTIzNA==</PlainValue><Data> <Secret> <PlainValue> MTIzNA== </PlainValue> </Secret> </Data> </Key> </Device> </KeyContainer>12.3.11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP 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:container: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><DeviceId> <Manufacturer>ACME</Manufacturer><DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>0755225266</SerialNo></DeviceId></DeviceInfo> <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <Issuer>AnIssuer</Issuer> <Usage OTP="true"> <ResponseFormat Length="8" Format="DECIMAL"/> </Usage><Data Name="COUNTER"> <PlainValue>AprkuA==</PlainValue> </Data> <Data Name="SECRET"><Data> <Secret> <EncryptedValue> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <xenc:CipherData> <xenc:CipherValue>kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok= </xenc:CipherValue> </xenc:CipherData> </EncryptedValue><ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC><ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data> </Key> </Device> </KeyContainer>12.4.11.4. Symmetric Key Container with signature and a single Password- based Encrypted HOTP Secret Key <?xml version="1.0" encoding="UTF-8"?> <pskc:KeyContainerxmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0" xmlns:pkcs-5= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0"> <pskc:EncryptionKey> <pskc:DerivedKey Id="#Passphrase1"> <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName> <pskc:KeyDerivationMethod Algorithm= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> <pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType"> <Salt> <Specified>Df3dRAhjGh8=</Specified> </Salt> <IterationCount>2000</IterationCount> <KeyLength>16</KeyLength> <PRF/> </pkcs-5:Parameters> </pskc:KeyDerivationMethod> <xenc:ReferenceList> <xenc:DataReference URI="#ED"/> </xenc:ReferenceList> </pskc:DerivedKey> </pskc:EncryptionKey> <pskc:Device><pskc:DeviceId> <pskc:Manufacturer>ACME</pskc:Manufacturer><pskc:DeviceInfo> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:SerialNo>0755225266</pskc:SerialNo></pskc:DeviceId></pskc:DeviceInfo> <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Usage OTP="true"> <pskc:ResponseFormat Length="6" Format="DECIMAL"/> </pskc:Usage><pskc:Data Name="COUNTER"> <pskc:PlainValue>AprkuA==</pskc:PlainValue> </pskc:Data> <pskc:Data Name="SECRET"><pskc:Data> <pskc:Secret> <pskc:EncryptedValue Id="ED"> <xenc:EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <xenc:CipherData> <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= </xenc:CipherValue> </xenc:CipherData> </pskc:EncryptedValue> </pskc:Secret> <pskc:Counter> <pskc:PlainValue>0</pskc:PlainValue> </pskc:Counter> </pskc:Data> </pskc:Key> </pskc:Device> <pskc:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI=""> <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509IssuerSerial> <ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US </ds:X509IssuerName> <ds:X509SerialNumber>12345678</ds:X509SerialNumber> </ds:X509IssuerSerial> </ds:X509Data> </ds:KeyInfo> </pskc:Signature> </pskc:KeyContainer>12.5.11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP Secret Key <?xml version="1.0" encoding="UTF-8"?> <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:xenc="http://www.w3.org/2001/04/xmlenc#"> <pskc:EncryptionKey> <ds:X509Data> <ds:X509Certificate>miib</ds:X509Certificate> </ds:X509Data> </pskc:EncryptionKey> <pskc:Device><pskc:DeviceId> <pskc:Manufacturer>ACME</pskc:Manufacturer><pskc:DeviceInfo> <pskc:Manufacturer>Manufacturer</pskc:Manufacturer> <pskc:SerialNo>0755225266</pskc:SerialNo></pskc:DeviceId></pskc:DeviceInfo> <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <pskc:Issuer>AnIssuer</pskc:Issuer> <pskc:Usage OTP="true"> <pskc:ResponseFormat Length="8" Format="DECIMAL"/> </pskc:Usage><pskc:Data Name="COUNTER"> <pskc:PlainValue>AprkuA==</pskc:PlainValue> </pskc:Data> <pskc:Data Name="SECRET"><pskc:Data> <pskc:Secret> <pskc:EncryptedValue Id="ED"> <xenc:EncryptionMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>Algorithm= "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> <xenc:CipherData> <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= </xenc:CipherValue> </xenc:CipherData> </pskc:EncryptedValue> </pskc:Secret> <pskc:Counter> <pskc:PlainValue>0</pskc:PlainValue> </pskc:Counter> </pskc:Data> </pskc:Key> </pskc:Device> </pskc:KeyContainer>13.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> 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. References13.1.12.1. Normative References [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0.", URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, October 1998. [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard", Version 2.0, URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.ietf.org/rfc/rfc2119.txt>. [RFC2434] Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3553] Mealling, M., "An IETF URN Sub-namespace for Registered Protocol Parameters", RFC 3553, June 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006. [XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, W3C Recommendation, February 2002. [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", URL: http://www.w3.org/TR/xmlenc-core/, December 2002.13.2.12.2. Informative References [CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004. [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, "Dynamic Symmetric Key Provisioning Protocol", Internet Draft Informational, URL: http://www.ietf.org/ internet-drafts/draft-ietf-keyprov-dskpp-03.txt, February 2008. [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One Time Password Algorithm", RFC 4226, URL: http://rfc.sunsite.dk/rfc/rfc4226.html, December 2005. [NIST-SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part I: General (Revised)", NIST 800-57, URL: http://csrc.nist.gov/ publications/nistpubs/800-57/ sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007. [OATH] "Initiative for Open AuTHentication", URL: http://www.openauthentication.org. [OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S. Bajaj, "OCRA: OATH Challenge Response Algorithm", Internet Draft Informational, URL: http://www.ietf.org/ internet-drafts/ draft-mraihi-mutual-oath-hotp-variants-06.txt, December 2007. [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange Syntax Standard", Version 1.0, URL: http://www.rsasecurity.com/rsalabs/pkcs/. [Schneier] Schneier, B., "Secrets and Lies: Digitial Security in a Networked World", Wiley Computer Publishing, ISBN 0-8493- 8253-7, 2000. Authors' Addresses Philip Hoyer ActivIdentity, Inc.109 Borough High Street117 Waterloo Road London, SE11NL8UL UK Phone: +44 (0) 20 7744 6455 Email: Philip.Hoyer@actividentity.com Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA Phone: +1 650 426 5173 Email: mpei@verisign.com Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada Phone: +1 416 756 2324 Ext. 321 Email: smachani@diversinet.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).