idnits 2.17.1 draft-ietf-keyprov-portable-symmetric-key-container-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1931. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-ietf-keyprov-portable-symmetric-key-container', is 51 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2007) is 6054 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'OATH' is defined on line 1816, but no explicit reference was found in the text == Unused Reference: 'OATHRefArch' is defined on line 1819, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSKPP' ** Downref: Normative reference to an Informational RFC: RFC 4226 (ref. 'HOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'OATH' -- Possible downref: Non-RFC (?) normative reference: ref. 'OATHRefArch' == Outdated reference: A later version (-14) exists of draft-mraihi-mutual-oath-hotp-variants-01 ** Downref: Normative reference to an Informational draft: draft-mraihi-mutual-oath-hotp-variants (ref. 'OCRA') ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1') (Obsoleted by RFC 3447) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS12' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSIG' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 keyprov P. Hoyer 3 Internet-Draft ActivIdentity 4 Intended status: Standards Track M. Pei 5 Expires: March 31, 2008 VeriSign 6 S. Machani 7 Diversinet 8 S. Chang 9 Gemalto 10 September 28, 2007 12 Portable Symmetric Key Container 13 draft-ietf-keyprov-portable-symmetric-key-container-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 31, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document specifies a symmetric key format for transport and 47 provisioning of symmetric keys (One Time Password (OTP) shared 48 secrets or symmetric cryptographic keys) to different types of strong 49 authentication devices. The standard token format enables 50 enterprises to deploy best-of-breed solutions combining components 51 from different vendors into the same infrastructure. 53 This work is a joint effort by the members of OATH (Initiative for 54 Open AuTHentication) to specify a format that can be freely 55 distributed to the technical community. The authors believe that a 56 common and shared specification will facilitate adoption of two- 57 factor authentication on the Internet by enabling interoperability 58 between commercial and open-source implementations. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions used in this document . . . . . . . . . . . . . . 5 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6 66 3.1.1. Credential migration by end-user . . . . . . . . . . . 6 67 3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6 68 3.1.3. Bulk migration of existing credentials . . . . . . . . 6 69 3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7 70 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7 71 3.2.1. Online provisioning a credential to end-user's 72 authentication token . . . . . . . . . . . . . . . . . 7 73 3.2.2. Server to server provisioning of credentials . . . . . 8 74 3.2.3. Online update of an existing authentication token 75 credential . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11 78 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 79 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11 80 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11 81 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11 82 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12 83 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12 84 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 12 85 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12 86 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute 87 is encrypted)) . . . . . . . . . . . . . . . . . . . . 12 88 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13 89 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13 90 6. Key container XML schema definitions . . . . . . . . . . . . . 17 91 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17 92 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18 93 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20 94 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 95 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22 96 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23 97 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24 98 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25 99 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 26 100 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 27 101 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28 102 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30 103 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30 104 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31 105 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33 106 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33 107 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33 108 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 110 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41 111 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 42 112 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 42 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 114 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 44 115 10.1. Symmetric Key Container with a single Non-Encrypted 116 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44 117 10.2. Symmetric Key Container with a single Password-based 118 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45 119 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 121 Intellectual Property and Copyright Statements . . . . . . . . . . 49 123 1. Introduction 125 With increasing use of symmetric key based authentication systems 126 such as systems based one time password (OTP) and challenge response 127 mechanisms, there is a need for vendor interoperability and a 128 standard format for importing, exporting or provisioning symmetric 129 key based credentials from one system to another. Traditionally 130 authentication server vendors and service providers have used 131 proprietary formats for importing, exporting and provisioning these 132 credentials into their systems making it hard to use tokens from 133 vendor A with a server from vendor B. 135 This Internet draft describes a standard format for serializing 136 symmetric key based credentials such as OTP shared secrets for system 137 import, export or network/protocol transport. The goal is that the 138 format will facilitate dynamic provisioning and transfer of a 139 symmetric key such as an OTP shared secret or an encryption key of 140 different types. In the case of OTP shared secrets, the format will 141 facilitate dynamic provisioning using an OTP provisioning protocol to 142 different flavors of embedded tokens for OTP credentials or allow 143 customers to import new or existing tokens in batch or single 144 instances into a compliant system. 146 This draft also specifies the token attributes required for 147 interoperability such as the initial event counter used in the HOTP 148 algorithm [HOTP]. It is also applicable for other time-based or 149 proprietary algorithms. 151 To provide an analogy, in public key environments the PKCS#12 format 152 [PKCS12] is commonly used for importing and exporting private keys 153 and certificates between systems. In the environments outlined in 154 this document where OTP credentials may be transported directly down 155 to smartcards or devices with limited computing capabilities, a 156 format with small (size in bytes) and explicit shared secret 157 configuration attribute information is desirable, avoding complexity 158 of PKCS#12. For example, one would have to use opaque data within 159 PKCS#12 to carry shared secret attributes used for OTP calculations, 160 wherears a more explicit attribute schema definition is better for 161 interoperation and efficiency. 163 2. Conventions used in this document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 In examples, "C:" and "S:" indicate lines sent by the client and 170 server respectively. 172 In the text below, OTP refers to one time password. 174 3. Use Cases 176 This section describes a comprehensive list of use cases that 177 inspired the development of this specification. These requirements 178 were used to derive the primary requirement that drove the design. 179 These requirements are covered in the next section. 181 These use cases also help in understanding the applicability of this 182 specification to real world situations. 184 3.1. Offline Use Cases 186 This section describes the use cases relating to offline transport of 187 credentials from one system to another, using some form of export and 188 import model. 190 3.1.1. Credential migration by end-user 192 A user wants to migrate a credential from one authentication token 193 (container) to a different authentication token. For example, the 194 authentication tokens may be soft tokens on two different systems 195 (computers or mobile phones). The user can export the credential in 196 a standard format for import into the other authentication token. 198 The key protection mechanism may rely on password-based encryption 199 for soft tokens, a pre-placed hardware-protected transfer key shared 200 between the two systems or may also rely on asymmetric keys/ PKI if 201 available. 203 3.1.2. Bulk import of new credentials 205 Tokens are manufactured in bulk and associated credentials (key 206 records) need to be loaded into the validation system through a file 207 on portable media. The manufacturer provides the credentials in the 208 form of a file containing records in standard format, typically on a 209 CD. Note that the token manufacturer and the vendor for the 210 validation system may be the same or different. 212 In this case the file usually is protected by a symmetric transport 213 key which was communicated separately outside of the file between the 214 two parties. 216 3.1.3. Bulk migration of existing credentials 218 An enterprise wants to port credentials from an existing validation 219 system A into a different validation system B. The existing 220 validation system provides the enterprise with a functionality that 221 enables export of credentials (OTP tokens) in a standard format. 223 Since the OTP tokens are in the standard format, the enterprise can 224 import the token records into the new validation system B and start 225 using the existing tokens. Note that the vendors for the two 226 validation systems may be the same or different. 228 In this case the file usually is protected by a symmetric transport 229 key which was communicated separately outside of the file between the 230 two validation systems. 232 3.1.4. Credential upload case 234 User wants to activate and use a new credential against a validation 235 system that is not aware of this credential. This credential may be 236 embedded in the authentication token (e.g. SD card, USB drive) that 237 the user has purchased at the local electronics retailer. Along with 238 the authentication token, the user may get the credential on a CD or 239 a floppy in a standard format. The user can now upload via a secure 240 online channel or import this credential into the new validation 241 system and start using the credential. 243 The key protection mechanism may rely on password-based encryption, 244 or a pre-placed hardware-protected transfer key shared between the 245 token manufacturer and the validation system(s) if available. 247 3.2. Online Use Cases 249 This section describes the use cases related to provisioning the 250 credentials using some form of a online provisioning protocol. 252 3.2.1. Online provisioning a credential to end-user's authentication 253 token 255 A mobile device user wants to obtain an OTP credential (shared 256 secret) for use with an OTP soft token on the device. The soft token 257 client from vendor A initiates the provisioning process against a 258 provisioning system from vendor B using a standards-based 259 provisioning protocol such as [DSKPP]. The provisioning system 260 delivers one or more OTP credential(s) in a standard format that can 261 be processed by the mobile device. The user can download a payload 262 that contains more than one credential. 264 In a variation of the above, instead of the user's mobile phone, a 265 credential is provisioned in the user's soft token application on a 266 laptop using a network-based online protocol. As before, the 267 provisioning system delivers an OTP credential in a standard format 268 that can be processed by the soft token on the PC. 270 3.2.2. Server to server provisioning of credentials 272 Sometimes, instead of importing token information from manufacturer 273 using a file, an OTP validation server may download the credential 274 seed records using an online protocol. The credentials can be 275 downloaded in a standard format that can be processed by a validation 276 system. 278 In another scenario, an OTA (over-the-air) credential provisioning 279 gateway that provisions credentials to mobile phones may obtain 280 credentials from the credential issuer using an online protocol. The 281 credentials are delivered in a standard format that can be processed 282 by the OTA credential provisioning gateway and subsequently sent to 283 the end-user's mobile phone. 285 3.2.3. Online update of an existing authentication token credential 287 The end-user or the credential issuer wants to update or configure an 288 existing credential in the authentication token and requests a 289 replacement credential container. The container may or may not 290 include a new secret key and may include new or updated secret key 291 attributes such as a new counter value in HOTP credential case, a new 292 logo, a modified response format or length, a new friendly name, etc. 294 4. Requirements 296 This section outlines the most relevant requirements that are the 297 basis of this work. Several of the requirements were derived from 298 use cases described above. 300 R1: The format MUST support transport of multiple types of 301 symmetric key credentials including HOTP, other OTP, challenge- 302 response, etc. 304 R2: The format MUST handle the symmetric key itself as well of 305 attributes that are typically associated with symmetric keys. 306 Some of these attributes may be 308 * Unique Key Identifier 310 * Issuer information 312 * Algorithm ID 314 * Algorithm mode 316 * Issuer Name 318 * Issuer logo 320 * Credential friendly name 322 * Event counter value (moving factor for OTP algorithms) 324 * Time value 326 R3: The format SHOULD support both offline and online scenarios. 327 That is it should be serializable to a file as well as it 328 should be possible to use this format in online provisioning 329 protocols 331 R4: The format SHOULD allow bulk representation of symmetric key 332 credentials. 334 R5: The format SHOULD be portable to various platforms. 335 Furthermore, it SHOULD be computationally efficient to process. 337 R6: The format MUST provide appropriate level of security in terms 338 of data encryption and data integrity. 340 R7: For online scenarios the format SHOULD NOT rely on transport 341 level security (e.g., SSL/TLS) for core security requirements. 343 R8: The format SHOULD be extensible. It SHOULD enable extension 344 points allowing vendors to specify additional attributes in the 345 future. 347 R9: The format SHOULD allow for distribution of key derivation data 348 without the actual symmetric key itself. This is to support 349 symmetric key management schemes that rely on key derivation 350 algorithms based on a pre-placed master key. The key 351 derivation data typically consists of a reference to the key, 352 rather than the key value itself. 354 R10: The format SHOULD allow for additional lifecycle management 355 operations such as counter resynchronization. Such processes 356 require confidentiality between client and server, thus could 357 use a common secure container format, without the transfer of 358 key material. 360 R11: The format MUST support the use of pre-shared symmetric keys to 361 ensure confidentiality of sensitive data elements. 363 R12: The format MUST support a password-based encryption (PBE) 364 [PKCS5] scheme to ensure security of sensitive data elements. 365 This is a widely used method for various provisioning 366 scenarios. 368 R13: The format SHOULD support asymmetric encryption algorithms such 369 as RSA to ensure end-to-end security of sensitive data 370 elements. This is to support scenarios where a pre-set shared 371 encryption key is difficult to use. 373 5. Symmetric Key Attributes 375 The symmetric key includes a number of data attributes that define 376 the type of the key its usage and associated meta-information 377 required during the provisioning, configuration, access or usage in 378 the host device. 380 5.1. Common Attributes 382 5.1.1. Data (OPTIONAL) 384 Defines the data attributes of the symmetric key. Each is a name 385 value pair which has both a base64 encoded value and a base 64 386 encoded valueDigest. The value can be encrypted. If the container 387 has been encrypted the valueDigest MUST be populated with the digest 388 of the unencrypted value. 390 This is also where the key value is held, therefore the follwoing 391 list of attribute names have been reserved: 393 SECRET: the shared secret key value in binary, base64 encoded 395 COUNTER: the event counter for event based OTP algorithms. 8 bytes 396 unsigned integer in big endian (i.e. network byte order) form 397 base64 encoded 399 TIME: the time for time based OTP algorithms. 8 bytes unsigned 400 integer in big endian (i.e. network byte order) form base64 401 encoded (Number of seconds since 1970) 403 TIME_INTERVAL: the time interval value for time based OTP 404 algorithms. 8 bytes unsigned integer in big endian (i.e. network 405 byte order) form base64 encoded. 407 5.1.2. KeyAlgorithm (MANDATORY) 409 Defines the type of algorithm of the secret key and MUST be set to 410 one of the values defined in Section 6.5. If 'OTHER' is specified an 411 extension value MUST be set in the 'ext-KeyAlgorithm' attribute. 413 5.1.3. Usage (MANDATORY) 415 Defines the intended usage of the key and is a combination of one or 416 more of the following (set to true): 418 OTP: the key will be used for OTP generation 420 CR: the key will be used for Challenge/Response purposes 422 ENCRYPT: the key will be used for data encryption purposes 424 SIGN: the key will be used to generate a signature or keyed 425 hashing for data integrity or authentication purposes. 427 UNLOCK: the key will be used for an inverse challenge response in 428 the case a user has locked the device by entering a wrong PIN too 429 many times (for devices with PIN-input capability) 431 Additional attributes that are specific to the usage type MAY be 432 required. Section 6.1 describes OTP and CR specific attributes. 434 5.1.4. KeyId (MANDATORY) 436 A unique and global identifier of the symmetric key. The identifier 437 is defined as a string of alphanumeric characters. 439 5.1.5. Issuer (MANDATORY) 441 The key issuer name, this is normally the name of the organisation 442 that issues the key to the end user of the key. For example MyBank 443 issuing hardware tokens to their retail banking users 'MyBank' would 444 be the issuer. The Issuer is defined as a String. 446 5.1.6. FriendlyName (OPTIONAL) 448 The user friendly name that is assigned to the secret key for easy 449 reference. The FriendlyName is defined as a String. 451 5.1.7. AccessRules (OPTIONAL) 453 Defines a set of access rules and policies for the protection of the 454 key on the host Device. Currently only the userPIN policy is 455 defined. The userPIN policy specifies whether the user MUST enter a 456 PIN (for devices with PIN input capability) in order to unlock or 457 authenticate to the device hosting the key container. The userPIN is 458 defined as a Boolean (TRUE or FALSE). When the user PIN is required, 459 the policy MUST be set to TRUE. If the userPIN is NOT provided, 460 implementations SHALL default the value to FALSE. 462 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted)) 464 Identifies the encryption algorithm and possible parameters used to 465 protect the Secret Key data in the container and MUST be set to one 466 of the values defined in Section 6.2. If 'OTHER' is specified an 467 extension value MUST be set in the 'ext-algorithm' attribute. 469 When the value is set to NONE, implementations SHALL ensure the 470 privacy of the key data through other standard mechanisms e.g. 471 transport level encryption. 473 When the container (payload) contains more than one key and 474 EncryptionMethod is different from NONE, the same encryption key MUST 475 be used to encrypt all the key data elements in the container. 477 5.1.9. DigestMethod (MANDATORY when Digest is present) 479 Identifies the algorithm and possible parameters used to generate a 480 digest of the the Secret Key data. The digest guarantees the 481 integrity and the authenticity of the key data. The Digest algorithm 482 MUST be set to one of the values defined in Section 6.4. If 'OTHER' 483 is specified an extension value MUST be set in the 'ext-algorithm' 484 attribute. 486 See Section 6.1.8 for more information on Digest data value type. 488 5.1.10. OTP and CR specific Attributes (OPTIONAL) 490 When the key usage is set to OTP or CR, additional attributes MUST be 491 provided to support the OTP and/or the response computation as 492 required by the underlying algorithm and to customize or configure 493 the outcome of the computation (format, length and usage modes). 495 5.1.10.1. ChallengeFormat (MANDATORY) 497 The ChallengeFormat attribute defines the characteristics of the 498 challenge in a CR usage scenario. The Challenge attribute is defined 499 by the following sub-attributes: 501 1. Format (MANDATORY) 503 Defines the format of the challenge accepted by the device and 504 MUST be one of the values defined in Section 6.6 506 2. CheckDigit (OPTIONAL) 508 Defines if the device needs to check the appended Luhn check 509 digit contained in a provided challenge. This is only valid 510 if the Format attribute is'DECIMAL'. Value MUST be: 512 TRUE device will check the appended Luhn check digit in a 513 provided challenge 515 FALSE device will not check appended Luhn check digit in 516 challenge 518 3. Min (MANDATORY) 520 Defines the minimum size of the challenge accepted by the 521 device for CR mode. 523 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 524 'ALPHANUMERIC' this value indicates the minimum number of 525 digits/characters. 527 If the Format attribute is 'BASE64' or 'BINARY', this value 528 indicates the minimum number of bytes of the unencoded value. 530 Value MUST be: 532 Unsigned integer. 534 4. Max (MANDATORY) 536 Defines the maximum size of the challenge accepted by the 537 device for CR mode. 539 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 540 'ALPHANUMERIC' this value indicates the maximum number of 541 digits/characters. 543 If the Format attribute is 'BASE64' or 'BINARY', this value 544 indicates the maximum number of bytes of the unencoded value. 546 Value MUST be: 548 Unsigned integer. 550 5.1.10.2. ResponseFormat (MANDATORY) 552 The ResponseFormat attribute defines the characteristics of the 553 result of a computation. This defines the format of the OTP or of 554 the response to a challenge. The Response attribute is defined by 555 the following sub-attributes: 557 1. Format (MANDATORY) 559 Defines the format of the response generated by the device and 560 MUST be one of the values defined in Section 6.6 562 2. CheckDigit (OPTIONAL) 564 Defines if the device needs to append a Luhn check digit to 565 the response. This is only valid if the Format attribute 566 is'DECIMAL'. Value MUST be: 568 TRUE device will append a Luhn check digit to the response. 570 FALSE device will not append a Luhn check digit to the 571 response. 573 3. Length (MANDATORY) 575 Defines the length of the response generated by the device. 577 If the Format attribute is 'DECIMAL','HEXADECIMAL' or 578 'ALPHANUMERIC' this value indicates the number of digits/ 579 characters. 581 If the Format attribute is 'BASE64' or 'BINARY', this value 582 indicates the number of bytes of the unencoded value. 584 Value MUST be: 586 Unsigned integer. 588 5.1.10.3. AppProfileId (OPTIONAL) 590 Defines the application profile id related to attributes present on a 591 smart card that have influence when computing a response. An example 592 could be an EMV MasterCard CAP [CAP] application on a card that 593 contains attributes or uses fixed data for a specific batch of cards 594 such as: 596 IAF Internet authentication flag 598 CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA 599 13, VISA14) 600 AIP (Application Interchange Profile), 2 bytes 602 TVR Terminal Verification Result, 5 bytes 604 CVR The card verification result 606 AmountOther 608 TransactionDate 610 TerminalCountryCode 612 TransactionCurrencyCode 614 AmountAuthorised 616 IIPB 618 These values are not contained within attributes in the container but 619 are shared between the manufacturing and the validation service 620 through this unique AppProfileId. 622 6. Key container XML schema definitions 624 The portable key container is defined by the following entities: 626 1. KeyContainer entity 628 2. Device entity 630 3. Key entity 632 4. User entity 634 A KeyContainer MAY contain one or more Device entities. A Device MAY 635 contain one or more Key entities and may be associated to one or more 636 User entities. 638 The figure below indicates a possible relationship diagram of a 639 container. 641 -------------------------------------------- 642 | KeyContainer | 643 | | 644 | ------------------ ----------------- | 645 | | Device 1 | | Device n | | 646 | | | | | | 647 | | ------------ | | ------------ | | 648 | | | Key 1 | | | | Key n | | | 649 | | ------------ | | ------------ | | 650 | | | | | | 651 | | | | | | 652 | | ------------ | | ------------ | | 653 | | | Key m | | | | Key p | | | 654 | | ------------ | | ------------ | | 655 | ------------------ ----------------- | 656 | | | | | 657 | | | | | 658 | ---------- ---------- ---------- | 659 | | User 1 | | User 1 | | User n | | 660 | ---------- ---------- ---------- | 661 | | 662 -------------------------------------------- 664 6.1. XML Schema Types 666 The following types are defined to represent the portable key 667 container entities and associated attributes. 669 6.1.1. KeyType 671 The KeyType represents the key entity in the KeyContainer. The 672 KeyType is defined as follows: 674 675 676 677 678 679 681 682 683 684 685 687 688 689 690 691 692 693 694 695 697 698 700 The components of the KeyType have the following meanings (see 701 Section 5 for further information): 703 o of type UsageType defines the usage of the Secret Key. The 704 Usage attribute is described in Section 5.1.3. 706 o identifies the issuer of the Secret Key. The Issuer 707 attribute is described in Section 5.1.5. 709 o is a user friendly name that is assigned to the 710 Secret Key for easy reference. 712 o conveys the data attributes (eg the Secret Key) in name 713 (string) value (base64 encoded) pairs. The value can be 714 encrypted, in this case a digest of the non-encrypted data is 715 present. The component is further described below. 717 o Defines the rules for accessing the credential on 718 the device e.g. a password must be provided by the user to view 719 credential info or use the credential to generate an OTP response 721 o KeyId is a global identifier of the Secret Key. See Section 5.1.4. 723 o KeyAlgorithm defines the algorithm used with the Secret Key. The 724 type values are defined in Section 6.5. If 'OTHER' is specified 725 an extension value MUST be set in the 'ext-KeyAlgorithm' 726 attribute. 728 o ext-KeyAlgorithm is the extension point for KeyAlgorithms not 729 already defined Section 6.5 731 o Logo of type LogoType associates display logos with this Secret 732 Key 734 o Expiry defines the expiry date of the Secret Key in format DD/MM/ 735 YYYY 737 The element is of type and is defined as follows: 739 740 741 742 743 744 745 747 The 'Name' attribute defines the name of the name-value pair, the 748 follwoing list of attribute names have been reserved: 750 SECRET: the key key value in binary, base64 encoded 752 COUNTER: the event counter for event based OTP algorithms. 8 bytes 753 unsigned integer in big endian (i.e. network byte order) form 754 base64 encoded 756 TIME: the time for time based OTP algorithms. 8 bytes unsigned 757 integer in big endian (i.e. network byte order) form base64 758 encoded (Number of seconds since 1970) 760 TIME_INTERVAL: the time interval value for time based OTP 761 algorithms. 8 bytes unsigned integer in big endian (i.e. network 762 byte order) form base64 encoded. 764 The element in the DataType conveys the value of the name- 765 value pair in base 64 encoding. The value MAY be encrypted or in 766 clear text as per the EncryptionMethod data element in the 767 KeyContainer (see Section 6.1.6 for details about KeyContainerType). 768 When the value is encrypted, the digest value in 'ValueDigest' MUST 769 be provided. The digest MUST be calculated on the unencrypted value 770 and MUST use one of the Digest algorithms specified in 771 DigestMethodType element of the KeyContainer. The MAC key for the 772 MAC calculation should use the same key as the encryption key 773 specified in the EncryptionMethod unless a separate MAC key is 774 specified. When PBE method is used for encryption, a different 775 password is recommended for the MAC key derivation. When the key 776 data is in clear text, the KeyContainer payload signature MAY be used 777 to check the integrity of the key octets. 779 6.1.2. UsageType 781 The UsageType defines the usage attribute of the key entity. The 782 UsageType is defined as follows: 784 785 786 788 789 790 792 794 796 797 798 799 800 802 803 804 806 807 808 809 810 812 814 815 816 817 819 The UsageType components have the following meanings: 821 o the AlgorithmIdentifier as defined in 822 [OCRA]]. 824 o holds the algorithm response attributes. 826 o hold the challenge attributes in CR based 827 algorithm computations. 829 o Is the unique shared identifier for out of band 830 shared common parameters. 832 6.1.3. DeviceType 834 The DeviceType type represents the Device entity in the Container. A 835 Device MAY be bound to a user and MAY contain more than one keys. It 836 is recommended that a key is bound to one and only one Device. 838 The DeviceType is defined as follows: 840 841 842 844 846 847 848 850 The components of the DeviceType have the following meanings: 852 o , a unique identifier for the device, defined by the 853 DeviceId type. 855 o , represents the key entity defined by the KeyType. 857 o , optionally identifies the owner or the user of the Device, 858 as defined by the UserType . 860 6.1.4. DeviceIdType 862 The DeviceId type represents the identifying criteria to uniquely 863 identify the device that contains the associated keys. Since devices 864 can come in different form factors such as hardware tokens, 865 smartcards, soft tokens in a mobile phone or PC etc this type allows 866 different criteria to be used. Combined though the criteria MUST 867 uniquely identify the device. For example for hardware tokens the 868 combination of SerialNo and Manufacturer will uniquely identify a 869 device but not serialNo alone since two different token manufacturers 870 might issue devices with the same serialnumber (similar to the 871 IssuerDN and serialnumber of a certificate). For keys hold on 872 banking cards the identification of the device is often done via the 873 Primary Account Number (PAN, the big number printed on the front of 874 the card) and an expiry date of the card. DeviceId is an extensible 875 type that allows all these different ways to uniquely identify a 876 specific key containing device. 878 The DeviceIdType is defined as follows: 880 881 882 883 884 885 886 887 888 890 The components of the DeviceId type have the following meanings: 892 o , the manufacturer of the device. 894 o , the model of the device (e.g one-button-HOTP-token-V1) 896 o , the serial number of the device or the PAN (primary 897 account number) in case of EMV (Europay-MasterCard-Visa) smart 898 cards. 900 o , the issue number in case of smart cards with the same 901 PAN, equivalent to a PSN (PAN Sequence Number). 903 o , the expiry date of a device (such as the one on an EMV 904 card,used when issue numbers are not printed on cards). In format 905 DD/MM/YYYY 907 6.1.5. UserType Type 909 The UserType represents the identifying criteria to uniquely identify 910 the user who is bound to this device. 912 The UserType is defined as follows: 914 915 916 917 918 919 920 921 922 923 925 The components of the UserType type have the following meanings: 927 o , user first name. 929 o , user last name. 931 o , user id (UID) or user name. 933 o , user organization name. 935 6.1.6. KeyContainerType 937 The KeyContainerType represents the key container entity. A 938 Container MAY contain more than one Device entity; each Device entity 939 MAY contain more than one Key entity. 941 The KeyContainerType is defined as follows: 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 961 963 964 966 968 The components of the KeyContainer have the following meanings: 970 o version, the version number for the portable key container format 971 (the XML schema defined in this document). 973 o , the encryption method used to protect the Key 974 data attributes 976 o , the digest method used to sign the unencrypted the 977 Secret Key data attributes 979 o , the host Device for one or more Keys. 981 o , contains the signature value of the Container. When 982 the signature is applied to the entire container, it MUST use XML 983 Signature methods as defined in [XMLSIG]. The signature is 984 enveloped. 986 6.1.7. EncryptionMethodType 988 The EncryptionMethodType defines the algorithm and parameters used to 989 encrypt the Secret Key data attributes in the Container. The 990 encryption is applied on each individual Secret Key data in the 991 Container. The encryption method MUST be the same for all Secret Key 992 data in the container. 994 The EncryptionMethodType is defined as follows: 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1013 1014 1016 The components of the EncryptionMethodType have the following 1017 meanings: 1019 o algorithm: identifies the encryption algorithm used to protect the 1020 Secret Key data. When 'NONE' is specified, implementations MUST 1021 guarantee the privacy of the Secret Key Data through other 1022 mechanisms e.g. through transport level security. If 'OTHER' is 1023 specified an extension value MUST be set in the 'ext-algorithm' 1024 attribute. Please see EncryptionAlgorithmType for more 1025 information on supported algorithms 1027 o : conveys the Salt when [PKCS5] password-based encryption 1028 is applied. 1030 o : conveys the iteration count value in [PKCS5] 1031 password-based encryption if it is different from the default 1032 value. 1034 o : conveys the initialization vector for CBC based encryption 1035 algorithms. It is recommended for security reasons to transmit 1036 this value out of band and treat it the same manner as the key 1037 value. 1039 o : identifies a unique label for a pre-shared 1040 encryption key. 1042 o : conveys the information of the key if an RSA algorithm 1043 has been used. 1045 o : conveys the OAEP parameters if an RSA algorithm has 1046 been used. 1048 6.1.8. DigestMethodType 1050 The DigestMethodType defines the algorithm and parameters used to 1051 create the digest on the unencrypted Secret Key data in the 1052 Container. The digest is applied on each individual Secret Key data 1053 in the Container before encryption. The digest method MUST be the 1054 same for all Secret Key data in the container. Unless a different 1055 digest key is specified it is assumed that keyed digest algorithms 1056 will use the same key as for encryption 1058 The DigestMethodType is defined as follows: 1060 1061 1062 1063 1064 1066 1068 The components of the DigestMethodType have the following meanings: 1070 o algorithm, identifies the digest algorithm used to protect the 1071 Secret Key data. Please see DigestAlgorithmType for more 1072 information on supported algorithms 1074 o : identifies a unique label for a pre-shared 1075 digest key. 1077 6.1.9. AlgorithmIdentifierType 1079 The AlgorithmIdentiferType defines the Algorithm identifier (AI) 1080 specified in [OCRA]. 1082 The AlgorithmIdentifierType is defines as follows: 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1111 See [OCRA] for a full description of the components of the 1112 AlgorithmIdentifierType. 1114 6.2. EncryptionAlgorithmType 1116 The EncryptionAlgorithmType defines the allowed algorithms for 1117 encrypting the Secret Key data in the Container. 1119 The EncryptionAlgorithmType is defined as follows: 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1140 NONE when no encryption is applied on the key 1142 PBE-3DES112-CBC when password-based encryption is applied using a 1143 112-bit 3DES key in CBC mode 1145 PBE-3DES168-CBC when password-based encryption is applied using a 1146 168-bit 3DES key in CBC mode 1148 PBE-AES128-CBC when password-based encryption is applied using a 1149 128-bit AES key in CBC mode 1151 PBE-AES192-CBC when password-based encryption is applied using a 1152 192-bit AES key in CBC mode is applied. 1154 PBE-AES256-CBC password-based encryption is applied using a 256- 1155 bit AES key in CBC mode is applied. 1157 3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC 1158 mode is applied. 1160 3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC 1161 mode is applied. 1163 AES128-CBC encryption using a pre-shared 128-bit AES key in CBC 1164 mode is applied. 1166 AES192-CBC encryption using a pre-shared 192-bit AES key in CBC 1167 mode is applied. 1169 AES256-CBC encryption using a pre-shared 256-bit AES key in CBC 1170 mode is applied. 1172 RSA-1_5 The RSAES-PKCS1-v1_5 algorithm, specified in [PKCS1], 1173 takes no explicit parameters. 1175 RSA-OAEP-MGF1P The same algorithm as defined in section 5.4.2 RSA- 1176 OAEP in [XMLENC] It is the RSAES-OAEP-ENCRYPT algorithm, as 1177 specified in [PKCS1], it takes three parameters. The two user 1178 specified parameters are a MANDATORY message digest function and 1179 an OPTIONAL encoding octet string OAEPparams. The message digest 1180 function is indicated by the Algorithm attribute of a child ds: 1181 DigestMethod element and the mask generation function, the third 1182 parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier). 1184 OTHER extension point for not already defined algorithms in this 1185 list. 1187 6.3. HashAlgorithmType 1189 The HashAlgorithmType defines the allowed algorithms for generating a 1190 digest in the RSA algorithms. 1192 The HashAlgorithmType is defined as follows: 1194 1195 1196 1197 1198 1199 1200 1202 SHA1 when the digest was performed using the SHA1 algorithm 1204 SHA256 when the digest was performed using the SHA256 algorithm 1206 SHA512 when the digest was performed using the SHA512 algorithm 1208 6.4. DigestAlgorithmType 1210 The DigestAlgorithmType defines the allowed algorithms for generating 1211 a digest on the unencrypted Secret Key data in the Container. 1213 The DigestAlgorithmType is defined as follows: 1215 1216 1217 1218 1219 1220 1221 1222 1224 HMAC-SHA1 when the digest was performed using the HMAC-SHA1 1225 algorithm 1227 HMAC-SHA256 when the digest was performed using the HMAC-SHA256 1228 algorithm 1230 HMAC-SHA512 when the digest was performed using the HMAC-SHA512 1231 algorithm 1233 OTHER extension point for not already defined algorithms in this 1234 list. 1236 6.5. KeyAlgorithmType 1238 The KeyAlgorithmType defines the algorithms in which the Secret Key 1239 data is used. 1241 The KeyAlgorithmType is defined as follows: 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1261 3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES) 1263 3DES168, a 168-bit parity-checked 3DES key 1265 ACTI, algorithm family from ActivIdentity 1267 AES128, a 128-bit AES key 1269 AES192, a 192-bit AES key 1271 AES256, a 256-bit AES key 1273 ANSIX9.9, ANSI X9.9 algorithm 1275 DES, a standard DES key 1277 HOTP, as defined in [HOTP] 1279 MKEYLABEL, master key abel or name when an embedded device key is 1280 used to derive the Key 1282 RSASECUREID, SecureId algorithm family from RSA 1284 VASCO, algorithm family from Vasco 1286 OTHER extension point for not already defined algorithms in this 1287 list. 1289 6.6. valueFormat 1291 The valueFormat defines allowed formats for challenges or responses 1292 in the OTP algorithms. 1294 The valueFormat is defined as follows: 1296 1297 1298 1299 1300 1301 1302 1303 1304 1306 DECIMAL Only numerical digits 1308 HEXADECIMAL Hexadecimal response 1310 ALPHANUMERIC All letters and numbers (case sensitive) 1312 BASE64 Base 64 encoded 1314 BINARY Binary data, this is mainly used in case of connected 1315 devices 1317 6.7. Data elements 1319 6.7.1. KeyContainer 1321 The KeyContainer data element is defined as: 1323 1325 The KeyContainer data element is of type KeyContainerType defined in 1326 Section 6.1.6. 1328 The EncryptionMethod data element in the KeyContainer defines the 1329 encryption algorithm used to protect the Key data. In a multi-key 1330 KeyContainer, the same encryption method and the same encryption key 1331 MUST be used for all key data elements. 1333 The KeyContainer data element MAY contain multiple Device data 1334 elements, allowing for bulk provisioning of keys. 1336 The Signature data element is of type as defined in 1337 [XMLSIG] and MAY be omitted in the KeyContainer data element when 1338 application layer provisioning or transport layer provisioning 1339 protocols provide the integrity and authenticity of the payload 1340 between the sender and the recipient of the container. When 1341 required, this specification recommends using a symmetric key based 1342 signature with the same key used in the encryption of the secret key 1343 data. The signature is enveloped. 1345 7. Formal Syntax 1347 The following syntax specification uses the widely adopted XML schema 1348 format as defined by a W3C recommendation 1349 (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax 1350 definition in the XML Schema Definition format (XSD) 1352 All implentations of this standard must comply with the schema below. 1354 1355 1361 1364 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1384 1386 1387 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1401 1402 1403 1404 1405 1406 1407 1408 1409 1411 1413 1415 1417 1419 1420 1421 1422 1423 1424 1425 1427 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1440 1441 1442 1443 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1460 1462 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1480 1481 1482 1484 1485 1486 1487 1488 1489 1490 1492 1493 1494 1496 1497 1498 1499 1500 1501 1503 1505 1507 1509 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1526 1528 1529 1530 1532 1534 1535 1536 1537 1538 1540 1541 1542 1543 1544 1545 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1615 1616 1617 1618 1620 1621 1623 1624 1626 8. Security Considerations 1628 The portable key container carries sensitive information (e.g., 1629 cryptographic keys) and may be transported across the boundaries of 1630 one secure perimeter to another. For example, a container residing 1631 within the secure perimeter of a back-end provisioning server in a 1632 secure room may be transported across the internet to an end-user 1633 device attached to a personal computer. This means that special care 1634 must be taken to ensure the confidentiality, integrity, and 1635 authenticity of the information contained within. 1637 8.1. Payload confidentiality 1639 By design, the container allows two main approaches to guaranteeing 1640 the confidentiality of the information it contains while transported. 1642 First, the container key data payload may be encrypted. 1644 In this case no transport layer security is required. However, 1645 standard security best practices apply when selecting the strength of 1646 the cryptographic algorithm for payload encryption. Symmetric 1647 cryptographic cipher should be used - the longer the cryptographic 1648 key, the stronger the protection. At the time of this writing both 1649 3DES and AES are recommended algorithms but 3DES may be dropped in 1650 the relatively near future. Applications concerned with algorithm 1651 longevity are advised to use AES. In cases where the exchange of 1652 encryption keys between the sender and the receiver is not possible, 1653 asymmetric encryption of the secret key payload may be employed. 1654 Similarly to symmetric key cryptography, the stronger the asymmetric 1655 key, the more secure the protection is. 1657 If the payload is encrypted with a method that uses one of the 1658 password-based encryption methods provided above, the payload may be 1659 subjected to password dictionary attacks to break the encryption 1660 password and recover the information. Standard security best 1661 practices for selection of strong encryption passwords apply 1662 [Schneier]. 1664 Practical implementations should use PBESalt and PBEIterationCount 1665 when PBE encryption is used. Different PBESalt value per credential 1666 record should be used for best protection. 1668 The second approach to protecting the confidentiality of the payload 1669 is based on using transport layer security. The secure channel 1670 established between the source secure perimeter (the provisioning 1671 server from the example above) and the target perimeter (the device 1672 attached to the end-user computer) utilizes encryption to transport 1673 the messages that travel across. No payload encryption is required 1674 in this mode. Secure channels that encrypt and digest each message 1675 provide an extra measure of security, especially when the signature 1676 of the payload does not encompass the entire payload. 1678 Because of the fact that the plain text payload is protected only by 1679 the transport layer security, practical implementation must ensure 1680 protection against man-in-the-middle attacks [Schneier]. Validating 1681 the secure channel end-points is critically important for eliminating 1682 intruders that may compromise the confidentiality of the payload. 1684 8.2. Payload integrity 1686 The portable symmetric key container provides a mean to guarantee the 1687 integrity of the information it contains through digital signatures. 1688 For best security practices, the digital signature of the container 1689 should encompass the entire payload. This provides assurances for 1690 the integrity of all attributes. It also allows verification of the 1691 integrity of a given payload even after the container is delivered 1692 through the communication channel to the target perimeter and channel 1693 message integrity check is no longer possible. 1695 8.3. Payload authenticity 1697 The digital signature of the payload is the primary way of showing 1698 its authenticity. The recipient of the container may use the public 1699 key associated with the signature to assert the authenticity of the 1700 sender by tracing it back to a preloaded public key or certificate. 1701 Note that the digital signature of the payload can be checked even 1702 after the container has been delivered through the secure channel of 1703 communication. 1705 A weaker payload authenticity guarantee may be provided by the 1706 transport layer if it is configured to digest each message it 1707 transports. However, no authenticity verification is possible once 1708 the container is delivered at the recipient end. This approach may 1709 be useful in cases where the digital signature of the container does 1710 not encompass the entire payload. 1712 9. Acknowledgements 1714 The authors of this draft would like to thank the following people 1715 for their contributions and support to make this a better 1716 specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu 1717 Veath, Kevin Lewis, and Andrea Doherty. 1719 10. Appendix A - Example Symmetric Key Containers 1721 All examples are syntactically correct and compatible with the XML 1722 schema in section 7. However, , Key and Key 1723 data values are fictitious 1725 10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 1726 Key 1728 1729 1736 1737 1738 1739 1740 Token Manufacturer 1741 98765432187 1742 01/01/2008 1743 1744 1745 Credential Issuer 1746 1747 1748 1749 MyFirstToken 1750 1751 WldjTHZwRm9YTkhBRytseDMrUnc= 1752 WldjTHZwRm9YTkhBRytseDM= 1753 1754 1755 WldjTHZwRm9YTkhBRytseDMrUnc= 1756 WldjTHZwRm9YTkhBRytseDM= 1757 1758 1759 1760 1762 10.2. Symmetric Key Container with a single Password-based Encrypted 1763 HOTP Secret Key 1765 1766 1773 1774 y6TzckeLRQw= 1775 999 1776 1777 1778 1779 1780 Token Manufacturer 1781 98765432187 1782 01/01/2008 1783 1784 1785 Credential Issuer 1786 1787 1788 1789 MySecondToken 1790 1791 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1792 WldjTHZwRm9YTkhBRytseDMrUnc= 1793 1794 1795 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== 1796 WldjTHZwRm9YTkhBRytseDMrUnc= 1797 1798 1799 1800 1802 11. Normative References 1804 [CAP] MasterCard International, "Chip Authentication Program 1805 Functional Architecture", September 2004. 1807 [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet 1808 Draft Informational, URL: http://tools.ietf.org/wg/ 1809 keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007. 1811 [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password 1812 Algorithm", RFC 4226, 1813 URL: http://rfc.sunsite.dk/rfc/rfc4226.html, 1814 December 2005. 1816 [OATH] "Initiative for Open AuTHentication", 1817 URL: http://www.openauthentication.org. 1819 [OATHRefArch] 1820 OATH, "Reference Architecture", 1821 URL: http://www.openauthentication.org, Version 1.0, 2005. 1823 [OCRA] MRaihi, D., "OCRA: OATH Challenge Response Algorithm", 1824 Internet Draft Informational, URL: http://www.ietf.org/ 1825 internet-drafts/ 1826 draft-mraihi-mutual-oath-hotp-variants-01.txt, 1827 December 2005. 1829 [PKCS1] Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography 1830 Specifications Version 2.0.", 1831 URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0, 1832 October 1998. 1834 [PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange 1835 Syntax Standard", Version 1.0, 1836 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/. 1838 [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography 1839 Standard", Version 2.0, 1840 URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/, 1841 March 1999. 1843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1844 Requirement Levels", BCP 14, RFC 2119, March 1997. 1846 [Schneier] 1847 Schneier, B., "Secrets and Lies: Digitial Security in a 1848 Networked World", Wiley Computer Publishing, ISBN 0-8493- 1849 8253-7, 2000. 1851 [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", 1852 URL: http://www.w3.org/TR/xmlenc-core/, December 2002. 1854 [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing", 1855 URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, 1856 W3C Recommendation, February 2002. 1858 Authors' Addresses 1860 Philip Hoyer 1861 ActivIdenity, Inc. 1862 109 Borough High Street 1863 London, SE1 1NL 1864 UK 1866 Phone: +44 (0) 20 7744 6455 1867 Email: Philip.Hoyer@actividentity.com 1869 Mingliang Pei 1870 VeriSign, Inc. 1871 487 E. Middlefield Road 1872 Mountain View, CA 94043 1873 USA 1875 Phone: +1 650 426 5173 1876 Email: mpei@verisign.com 1878 Salah Machani 1879 Diversinet, Inc. 1880 2225 Sheppard Avenue East 1881 Suite 1801 1882 Toronto, Ontario M2J 5C2 1883 Canada 1885 Phone: +1 416 756 2324 Ext. 321 1886 Email: smachani@diversinet.com 1888 Shuh Chang 1889 Gemalto Inc. 1891 Email: shuh.chang@gemalto.com 1893 Full Copyright Statement 1895 Copyright (C) The IETF Trust (2007). 1897 This document is subject to the rights, licenses and restrictions 1898 contained in BCP 78, and except as set forth therein, the authors 1899 retain all their rights. 1901 This document and the information contained herein are provided on an 1902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1904 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1905 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1906 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1909 Intellectual Property 1911 The IETF takes no position regarding the validity or scope of any 1912 Intellectual Property Rights or other rights that might be claimed to 1913 pertain to the implementation or use of the technology described in 1914 this document or the extent to which any license under such rights 1915 might or might not be available; nor does it represent that it has 1916 made any independent effort to identify any such rights. Information 1917 on the procedures with respect to rights in RFC documents can be 1918 found in BCP 78 and BCP 79. 1920 Copies of IPR disclosures made to the IETF Secretariat and any 1921 assurances of licenses to be made available, or the result of an 1922 attempt made to obtain a general license or permission for the use of 1923 such proprietary rights by implementers or users of this 1924 specification can be obtained from the IETF on-line IPR repository at 1925 http://www.ietf.org/ipr. 1927 The IETF invites any interested party to bring to its attention any 1928 copyrights, patents or patent applications, or other proprietary 1929 rights that may cover technology that may be required to implement 1930 this standard. Please address the information to the IETF at 1931 ietf-ipr@ietf.org. 1933 Acknowledgment 1935 Funding for the RFC Editor function is provided by the IETF 1936 Administrative Support Activity (IASA).