idnits 2.17.1 

draft-ietf-keyprov-portable-symmetric-key-container-03.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 18.

  -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
     line 1785.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1796.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1803.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1809.


  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

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     o  <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not
     be possible to use this key after this date

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     o  <StartDate (OPTIONAL)>, the start date of the key, it MUST not
     be possible to use this key before this date

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     o  <WrongPINtry>, the number of times the PIN can be entered
     wrongly before it MUST not be possible to use the key anymore

  -- 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 (February 22, 2008) is 5907 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 1698, but no explicit
     reference was found in the text

  == Unused Reference: 'OATHRefArch' is defined on line 1701, but no explicit
     reference was found in the text

  == Unused Reference: 'OCRA' is defined on line 1705, but no explicit
     reference was found in the text

  == Unused Reference: 'PKCS1' is defined on line 1711, but no explicit
     reference was found in the text

  == Unused Reference: 'XMLENC' is defined on line 1734, 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 (~~), 10 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: August 25, 2008                                        VeriSign
6	                                                              S. Machani
7	                                                              Diversinet
8	                                                       February 22, 2008

10	                    Portable Symmetric Key Container
11	       draft-ietf-keyprov-portable-symmetric-key-container-03.txt

13	Status of this Memo

15	   By submitting this Internet-Draft, each author represents that any
16	   applicable patent or other IPR claims of which he or she is aware
17	   have been or will be disclosed, and any of which he or she becomes
18	   aware will be disclosed, in accordance with Section 6 of BCP 79.

20	   Internet-Drafts are working documents of the Internet Engineering
21	   Task Force (IETF), its areas, and its working groups.  Note that
22	   other groups may also distribute working documents as Internet-
23	   Drafts.

25	   Internet-Drafts are draft documents valid for a maximum of six months
26	   and may be updated, replaced, or obsoleted by other documents at any
27	   time.  It is inappropriate to use Internet-Drafts as reference
28	   material or to cite them other than as "work in progress."

30	   The list of current Internet-Drafts can be accessed at
31	   http://www.ietf.org/ietf/1id-abstracts.txt.

33	   The list of Internet-Draft Shadow Directories can be accessed at
34	   http://www.ietf.org/shadow.html.

36	   This Internet-Draft will expire on August 25, 2008.

38	Copyright Notice

40	   Copyright (C) The IETF Trust (2008).

42	Abstract

44	   This document specifies a symmetric key format for transport and
45	   provisioning of symmetric keys (One Time Password (OTP) shared
46	   secrets or symmetric cryptographic keys) to different types of strong
47	   authentication devices.  The standard token format enables
48	   enterprises to deploy best-of-breed solutions combining components
49	   from different vendors into the same infrastructure.

51	   This work is a joint effort by the members of OATH (Initiative for
52	   Open AuTHentication) to specify a format that can be freely
53	   distributed to the technical community.  The authors believe that a
54	   common and shared specification will facilitate adoption of two-
55	   factor authentication on the Internet by enabling interoperability
56	   between commercial and open-source implementations.

58	Table of Contents

60	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
61	   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
62	   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
63	     3.1.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . .  6
64	       3.1.1.  Key migration by end-user  . . . . . . . . . . . . . .  6
65	       3.1.2.  Bulk import of new keys  . . . . . . . . . . . . . . .  6
66	       3.1.3.  Bulk migration of existing keys  . . . . . . . . . . .  7
67	       3.1.4.  Key upload case  . . . . . . . . . . . . . . . . . . .  7
68	     3.2.  Online Use Cases . . . . . . . . . . . . . . . . . . . . .  7
69	       3.2.1.  Online provisioning a key to end-user's
70	               authentication token . . . . . . . . . . . . . . . . .  7
71	       3.2.2.  Server to server provisioning of keys  . . . . . . . .  8
72	       3.2.3.  Online update of an existing authentication token
73	               key  . . . . . . . . . . . . . . . . . . . . . . . . .  8
74	   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
75	   5.  Portable Key container definition  . . . . . . . . . . . . . . 11
76	     5.1.  KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 11
77	     5.2.  Device . . . . . . . . . . . . . . . . . . . . . . . . . . 13
78	       5.2.1.  DeviceId . . . . . . . . . . . . . . . . . . . . . . . 13
79	     5.3.  Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
80	       5.3.1.  Data (OPTIONAL)  . . . . . . . . . . . . . . . . . . . 17
81	       5.3.2.  Usage (MANDATORY)  . . . . . . . . . . . . . . . . . . 17
82	       5.3.3.  ValueFormat  . . . . . . . . . . . . . . . . . . . . . 21
83	       5.3.4.  PINPolicy  . . . . . . . . . . . . . . . . . . . . . . 22
84	   6.  Usage and profile of algorithms for the portable symmetric
85	       key container  . . . . . . . . . . . . . . . . . . . . . . . . 24
86	     6.1.  Usage of EncryptionKey to protect keys in transit  . . . . 24
87	       6.1.1.  Protecting keys using a pre-shared key via
88	               symmetric algorithms . . . . . . . . . . . . . . . . . 24

90	       6.1.2.  Protecting keys using passphrase based encryption
91	               keys . . . . . . . . . . . . . . . . . . . . . . . . . 25
92	     6.2.  Protecting keys using asymmetric algorithms  . . . . . . . 27
93	     6.3.  Profile of Key Algorithm . . . . . . . . . . . . . . . . . 28
94	       6.3.1.  OTP Key Algorithm Identifiers  . . . . . . . . . . . . 28
95	       6.3.2.  PIN key value compare algorithm identifier . . . . . . 28
96	   7.  Reserved data attribute names  . . . . . . . . . . . . . . . . 30
97	   8.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 31
98	   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
99	     9.1.  Payload confidentiality  . . . . . . . . . . . . . . . . . 35
100	     9.2.  Payload integrity  . . . . . . . . . . . . . . . . . . . . 36
101	     9.3.  Payload authenticity . . . . . . . . . . . . . . . . . . . 36
102	   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
103	   11. Appendix A - Example Symmetric Key Containers  . . . . . . . . 38
104	     11.1. Symmetric Key Container with a single Non-Encrypted
105	           HOTP Secret Key  . . . . . . . . . . . . . . . . . . . . . 38
106	     11.2. Symmetric Key Container with a single PIN protected
107	           Non-Encrypted HOTP Secret Key  . . . . . . . . . . . . . . 38
108	     11.3. Symmetric Key Container with a single AES-256-CBC
109	           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 39
110	     11.4. Symmetric Key Container with signature and a single
111	           Password-based Encrypted HOTP Secret Key . . . . . . . . . 40
112	     11.5. Symmetric Key Container with a single RSA 1.5
113	           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 42
114	   12. Normative References . . . . . . . . . . . . . . . . . . . . . 44
115	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
116	   Intellectual Property and Copyright Statements . . . . . . . . . . 47

118	1.  Introduction

120	   With increasing use of symmetric key based authentication systems
121	   such as systems based one time password (OTP) and challenge response
122	   mechanisms, there is a need for vendor interoperability and a
123	   standard format for importing, exporting or provisioning symmetric
124	   keys from one system to another.  Traditionally authentication server
125	   vendors and service providers have used proprietary formats for
126	   importing, exporting and provisioning these keys into their systems
127	   making it hard to use tokens from vendor A with a server from vendor
128	   B.

130	   This Internet draft describes a standard format for serializing
131	   symmetric keys such as OTP shared secrets for system import, export
132	   or network/protocol transport.  The goal is that the format will
133	   facilitate dynamic provisioning and transfer of a symmetric keys such
134	   as an OTP shared secret or an encryption key of different types.  In
135	   the case of OTP shared secrets, the format will facilitate dynamic
136	   provisioning using an online provisioning protocol to different
137	   flavors of embedded tokens or allow customers to import new or
138	   existing tokens in batch or single instances into a compliant system.

140	   This draft also specifies the key attributes required for computation
141	   such as the initial event counter used in the HOTP algorithm [HOTP].
142	   It is also applicable for other time-based or proprietary algorithms.

144	   To provide an analogy, in public key environments the PKCS#12 format
145	   [PKCS12] is commonly used for importing and exporting private keys
146	   and certificates between systems.  In the environments outlined in
147	   this document where OTP keys may be transported directly down to
148	   smartcards or devices with limited computing capabilities, a format
149	   with small (size in bytes) and explicit shared secret configuration
150	   attribute information is desirable, avoiding complexity of PKCS#12.
151	   For example, one would have to use opaque data within PKCS#12 to
152	   carry shared secret attributes used for OTP calculations, whereas a
153	   more explicit attribute schema definition is better for
154	   interoperability and efficiency.

156	2.  Conventions used in this document

158	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
159	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
160	   document are to be interpreted as described in [RFC2119].

162	   In examples, "C:" and "S:" indicate lines sent by the client and
163	   server respectively.

165	   In the text below, OTP refers to one time password.

167	3.  Use Cases

169	   This section describes a comprehensive list of use cases that
170	   inspired the development of this specification.  These requirements
171	   were used to derive the primary requirement that drove the design.
172	   These requirements are covered in the next section.

174	   These use cases also help in understanding the applicability of this
175	   specification to real world situations.

177	3.1.  Offline Use Cases

179	   This section describes the use cases relating to offline transport of
180	   keys from one system to another, using some form of export and import
181	   model.

183	3.1.1.  Key migration by end-user

185	   A user wants to migrate a key from one authentication token
186	   (container) to a different authentication token.  For example, the
187	   authentication tokens may be soft tokens on two different systems
188	   (computers or mobile phones).  The user can export the key and
189	   related data in a standard format for import into the other
190	   authentication token.

192	   The key protection mechanism may rely on password-based encryption
193	   for soft tokens, a pre-placed hardware-protected transfer key shared
194	   between the two systems or may also rely on asymmetric keys/ PKI if
195	   available.

197	3.1.2.  Bulk import of new keys

199	   Tokens are manufactured in bulk and associated keys and algorithm
200	   data need to be loaded into the validation system through a file on
201	   portable media.  The manufacturer provides the keys and related data
202	   in the form of a file containing records in standard format,
203	   typically on a CD.  Note that the token manufacturer and the vendor
204	   for the validation system may be the same or different.

206	   In this case the file usually is protected by a symmetric transport
207	   key which was communicated separately outside of the file between the
208	   two parties.

210	   Some devices will allow local PIN management (the device will have a
211	   PIN pad) hence random initial PINs set at manufacturing should be
212	   transmitted together with the respective keys they protect.

214	3.1.3.  Bulk migration of existing keys

216	   An enterprise wants to port keys and related data from an existing
217	   validation system A into a different validation system B. The
218	   existing validation system provides the enterprise with a
219	   functionality that enables export of keys and related data (e.g. for
220	   OTP tokens) in a standard format.  Since the OTP tokens are in the
221	   standard format, the enterprise can import the token records into the
222	   new validation system B and start using the existing tokens.  Note
223	   that the vendors for the two validation systems may be the same or
224	   different.

226	   In this case the file usually is protected by a symmetric transport
227	   key which was communicated separately outside of the file between the
228	   two validation systems.

230	   In this case it is also important to be able to communicate the
231	   existing assignment (binding) of a device to a specific user.

233	3.1.4.  Key upload case

235	   User wants to activate and use a new key and related data against a
236	   validation system that is not aware of this key.  This key may be
237	   embedded in the authentication token (e.g.  SD card, USB drive) that
238	   the user has purchased at the local electronics retailer.  Along with
239	   the authentication token, the user may get the key on a CD or a
240	   floppy in a standard format.  The user can now upload via a secure
241	   online channel or import this key and related data into the new
242	   validation system and start using the key.

244	   The key protection mechanism may rely on password-based encryption,
245	   or a pre-placed hardware-protected transfer key shared between the
246	   token manufacturer and the validation system(s) if available.

248	3.2.  Online Use Cases

250	   This section describes the use cases related to provisioning the keys
251	   using some form of a online provisioning protocol.

253	3.2.1.  Online provisioning a key to end-user's authentication token

255	   A mobile device user wants to obtain an OTP key for use with an OTP
256	   soft token on the device.  The soft token client from vendor A
257	   initiates the provisioning process against a provisioning system from
258	   vendor B using a standards-based provisioning protocol such as
259	   [DSKPP].  The provisioning system delivers one or more keys in a
260	   standard format that can be processed by the mobile device.  The user
261	   can download a payload that contains more than one key.

263	   In a variation of the above, instead of the user's mobile phone, a
264	   key is provisioned in the user's soft token application on a laptop
265	   using a network-based online protocol.  As before, the provisioning
266	   system delivers an OTP key in a standard format that can be processed
267	   by the soft token on the PC.

269	3.2.2.  Server to server provisioning of keys

271	   Sometimes, instead of importing keys from a manufacturer using a
272	   file, an OTP validation server may download the keys using an online
273	   protocol.  The keys can be downloaded in a standard format that can
274	   be processed by a validation system.

276	   In another scenario, an OTA (over-the-air) key provisioning gateway
277	   that provisions keys to mobile phones may obtain key material from a
278	   key issuer using an online protocol.  The keys are delivered in a
279	   standard format that can be processed by the OTA key provisioning
280	   gateway and subsequently sent to the end-user's mobile phone.

282	3.2.3.  Online update of an existing authentication token key

284	   The end-user or the key issuer wants to update or configure an
285	   existing key in the authentication token and requests a replacement
286	   key container.  The container may or may not include a new key and
287	   may include new or updated key attributes such as a new counter value
288	   in HOTP key case, a modified response format or length, a new
289	   friendly name, etc.

291	4.  Requirements

293	   This section outlines the most relevant requirements that are the
294	   basis of this work.  Several of the requirements were derived from
295	   use cases described above.

297	   R1:   The format MUST support transport of multiple types of
298	         symmetric keys and related attributes for algorithms including
299	         HOTP, other OTP, challenge-response, etc.

301	   R2:   The format MUST handle the symmetric key itself as well of
302	         attributes that are typically associated with symmetric keys.
303	         Some of these attributes may be

305	         *  Unique Key Identifier

307	         *  Issuer information

309	         *  Algorithm ID

311	         *  Algorithm mode

313	         *  Issuer Name

315	         *  Key friendly name

317	         *  Event counter value (moving factor for OTP algorithms)

319	         *  Time value

321	   R3:   The format SHOULD support both offline and online scenarios.
322	         That is it should be serializable to a file as well as it
323	         should be possible to use this format in online provisioning
324	         protocols

326	   R4:   The format SHOULD allow bulk representation of symmetric keys

328	   R5:   The format SHOULD allow bulk representation of PINs related to
329	         specific keys

331	   R6:   The format SHOULD be portable to various platforms.
332	         Furthermore, it SHOULD be computationally efficient to process.

334	   R7:   The format MUST provide appropriate level of security in terms
335	         of data encryption and data integrity.

337	   R8:   For online scenarios the format SHOULD NOT rely on transport
338	         level security (e.g., SSL/TLS) for core security requirements.

340	   R9:   The format SHOULD be extensible.  It SHOULD enable extension
341	         points allowing vendors to specify additional attributes in the
342	         future.

344	   R10:  The format SHOULD allow for distribution of key derivation data
345	         without the actual symmetric key itself.  This is to support
346	         symmetric key management schemes that rely on key derivation
347	         algorithms based on a pre-placed master key.  The key
348	         derivation data typically consists of a reference to the key,
349	         rather than the key value itself.

351	   R11:  The format SHOULD allow for additional lifecycle management
352	         operations such as counter resynchronization.  Such processes
353	         require confidentiality between client and server, thus could
354	         use a common secure container format, without the transfer of
355	         key material.

357	   R12:  The format MUST support the use of pre-shared symmetric keys to
358	         ensure confidentiality of sensitive data elements.

360	   R13:  The format MUST support a password-based encryption (PBE)
361	         [PKCS5] scheme to ensure security of sensitive data elements.
362	         This is a widely used method for various provisioning
363	         scenarios.

365	   R14:  The format SHOULD support asymmetric encryption algorithms such
366	         as RSA to ensure end-to-end security of sensitive data
367	         elements.  This is to support scenarios where a pre-set shared
368	         encryption key is difficult to use.

370	5.  Portable Key container definition

372	   The portable key container is based on an XML schema definition and
373	   contains the following main entities:

375	   1.  KeyContainer entity as defined in Section 5.1

377	   2.  Device entity as defined in Section 5.2

379	   3.  Key entity as defined in Section 5.3

381	   Additionally other XML schema types have been defined and are
382	   detailed in the relevant subsections of this document

384	   A KeyContainer MAY contain one or more Device entities.  A Device MAY
385	   contain one or more Key entities

387	   The figure below indicates a possible relationship diagram of a
388	   container.

390	   --------------------------------------------
391	   | KeyContainer                             |
392	   |                                          |
393	   |  ------------------   -----------------  |
394	   |  | Device 1       |   | Device n      |  |
395	   |  |                |   |               |  |
396	   |  |  ------------  |   | ------------  |  |
397	   |  |  | Key 1    |  |   | | Key n    |  |  |
398	   |  |  ------------  |   | ------------  |  |
399	   |  |                |   |               |  |
400	   |  |                |   |               |  |
401	   |  |  ------------  |   | ------------  |  |
402	   |  |  | Key m    |  |   | | Key p    |  |  |
403	   |  |  ------------  |   | ------------  |  |
404	   |  ------------------   -----------------  |
405	   |                                          |
406	   --------------------------------------------

408	   The following section describe in detail all the entities and related
409	   XML schema elements and attributes:

411	5.1.  KeyContainer

413	   The KeyContainer represents the key container entity.  A Container
414	   MAY contain more than one Device entity; each Device entity MAY
415	   contain more than one Key entity.

417	   The KeyContainer is defined as follows:

419	 <xs:complexType name="KeyContainerType">
420	         <xs:sequence>
421	                 <xs:element name="EncryptionKey"
422	                         type="ds:KeyInfoType" minOccurs="0"/>
423	                         <xs:element name="MACAlgorithm"
424	                         type="pskc:KeyAlgorithmType" minOccurs="0"/>
425	                         <xs:element name="Device"
426	                         type="pskc:DeviceType" maxOccurs="unbounded"/>
427	                 <xs:element name="Signature"
428	                         type="ds:SignatureType" minOccurs="0"/>
429	         </xs:sequence>
430	   <xs:attribute name="Version" type="pskc:VersionType" use="required"/>
431	 </xs:complexType>

433	   The elements of the KeyContainer have the following meanings:

435	   o  <EncryptionKey (OPTIONAL)>, Identifies the encryption key,
436	      algorithm and possible parameters used to protect the Secret Key
437	      data in the container, for profile and usage please see
438	      Section 6.1

440	   o  <MACAlgorithm (OPTIONAL)>, Identifies the algorithm used to
441	      generate a keyed digest of the the Secret Key data values when
442	      protection algorithms are used that do not have integrity checks.
443	      The digest guarantees the integrity and the authenticity of the
444	      key data. for profile and usage please see Section 6.1.1

446	   o  <Device>, the host Device for one or more Keys as defined in
447	      Section 5.2 The KeyContainer MAY contain multiple Device data
448	      elements, allowing for bulk provisioning of keys.

450	   o  <Signature (OPTIONAL)>, the signature value of the Container.
451	      When the signature is applied to the entire container, it MUST use
452	      XML Signature methods as defined in [XMLSIG].  It MAY be omitted
453	      when application layer provisioning or transport layer
454	      provisioning protocols provide the integrity and authenticity of
455	      the payload between the sender and the recipient of the container.
456	      When required, this specification recommends using a symmetric key
457	      based signature with the same key used in the encryption of the
458	      secret key data.  The signature is enveloped.

460	   o  <Version (MANDATORY)>, the version number for the portable key
461	      container format (the XML schema defined in this document).

463	5.2.  Device

465	   The Device represents the Device entity in the Container.  A Device
466	   MAY be bound to a user and MAY contain more than one keys.  It is
467	   recommended that a key is bound to one and only one Device.

469	   The Device is defined as follows:

471	<xs:complexType name="DeviceType">
472	  <xs:sequence>
473	    <xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>
474	    <xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>
475	    <xs:element name="UserId" type="xs:string" minOccurs="0"/>
476	  </xs:sequence>
477	</xs:complexType>

479	   The elements of the Device have the following meanings:

481	   o  <DeviceId>, a unique identifier for the device, defined in
482	      Section 5.2.1

484	   o  <Key>, represents the key entity as defined in Section 5.3

486	   o  <UserId>, optionally identifies the owner or the user of the
487	      Device TODO

489	5.2.1.  DeviceId

491	   The DeviceId represents the identifying criteria to uniquely identify
492	   the device that contains the associated keys.  Since devices can come
493	   in different form factors such as hardware tokens, smartcards, soft
494	   tokens in a mobile phone or PC etc this type allows different
495	   criteria to be used.  Combined though the criteria MUST uniquely
496	   identify the device.  For example for hardware tokens the combination
497	   of SerialNo and Manufacturer will uniquely identify a device but not
498	   SerialNo alone since two different token manufacturers might issue
499	   devices with the same serial number (similar to the IssuerDN and
500	   serial number of a certificate).  For keys hold on banking cards the
501	   identification of the device is often done via the Primary Account
502	   Number (PAN, the big number printed on the front of the card) and an
503	   expiry date of the card.  DeviceId is an extensible type that allows
504	   all these different ways to uniquely identify a specific key
505	   containing device.

507	   The DeviceId is defined as follows:

509	   <xs:complexType name="DeviceIdType">
510	   <xs:sequence>
511	       <xs:element name="Manufacturer" type="xs:string"/>
512	       <xs:element name="SerialNo" type="xs:string"/>
513	       <xs:element name="Model" type="xs:string" minOccurs="0"/>
514	       <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
515	       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
516	       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
517	   </xs:sequence>
518	   </xs:complexType>

520	   The elements of DeviceId have the following meanings:

522	   o  <Manufacturer>, the manufacturer of the device.

524	   o  <SerialNo>, the serial number of the device or the PAN (primary
525	      account number) in case of EMV (Europay-MasterCard-Visa) smart
526	      cards.

528	   o  <Model>, the model of the device (e.g one-button-HOTP-token-V1)

530	   o  <IssueNo>, the issue number in case of smart cards with the same
531	      PAN, equivalent to a PSN (PAN Sequence Number).

533	   o  <ExpiryDate>, the expiry date of a device (such as the one on an
534	      EMV card,used when issue numbers are not printed on cards).

536	   o  <StartDate>, the start date of a device (such as the one on an EMV
537	      card,used when issue numbers are not printed on cards).

539	5.3.  Key

541	   The Key represents the key entity in the KeyContainer.  The Key is
542	   defined as follows:

544	   <xs:complexType name="KeyType">
545	     <xs:sequence>
546	       <xs:element name="Issuer" type="xs:string" minOccurs="0"/>
547	       <xs:element name="Usage" type="pskc:UsageType"/>
548	       <xs:element name="CardAppPersoProfileId" type="xs:string"
549	         minOccurs="0"/>
550	       <xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>
551	       <xs:element name="Data" type="pskc:DataType" minOccurs="0"
552	         maxOccurs="unbounded"/>
553	       <xs:element name="PINPolicy" type="pskc:PINPolicyType"
554	         minOccurs="0"/>
555	       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
556	       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
557	     </xs:sequence>
558	     <xs:attribute name="KeyId" type="xs:string" use="required"/>
559	     <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
560	       use="required"/>
561	   </xs:complexType>

563	   The attributes of the Key entity have the following meanings:

565	   o  KeyId (MANDATORY), a unique and global identifier of the symmetric
566	      key.  The identifier is defined as a string of alphanumeric
567	      characters.

569	   o  <KeyAlgorithm (MANDATORY)>, the unique URI of the type of
570	      algorithm to use with the secret key, for profiles are described
571	      in Section 6.3

573	   The elements of the Key entity have the following meanings:

575	   o  <Issuer (OPTIONAL)>, The key issuer name, this is normally the
576	      name of the organization that issues the key to the end user of
577	      the key.  For example MyBank issuing hardware tokens to their
578	      retail banking users 'MyBank' would be the issuer.  The Issuer is
579	      defined as a String.

581	   o  <Usage (MANDATORY)>, defines the intended usage of the key and
582	      related metadata as defined in Section 5.3.2

584	   o  <CardAppPersoProfileId (OPTIONAL)>, A uniquie identifier used
585	      between the sending and receiving party of the container to
586	      establish a set of constant values related to a key that are not
587	      transmitted via the container.  For example a smart card
588	      application personalisation profile id related to attributes
589	      present on a smart card application that have influence when
590	      computing a response.  An example could be an EMV MasterCard CAP
591	      [CAP] application on a card personalised with data for a specific
592	      batch of cards such as:

594	         IAF Internet authentication flag

596	         CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
597	         VISA 13, VISA14)

599	         AIP (Application Interchange Profile), 2 bytes

601	         TVR Terminal Verification Result, 5 bytes

603	         CVR The card verification result

605	         AmountOther

607	         TransactionDate

609	         TerminalCountryCode

611	         TransactionCurrencyCode

613	         AmountAuthorised

615	         IIPB

617	      These values are not contained within attributes in the container
618	      but are shared between the manufacturing and the validation
619	      service through this unique CardAppPersoProfileId.  The
620	      CardAppPersoProfileId is defined as a String.

622	   o  <FriendlyName (OPTIONAL)>, The user friendly name that is assigned
623	      to the secret key for easy reference.  The FriendlyName is defined
624	      as a String.

626	   o  <Data (OPTIONAL)>, the element carrying the data related to the
627	      key as defined in Section 5.3.1

629	   o  <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the
630	      usage of this key as defined in Section 5.3.4

632	   o  <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not
633	      be possible to use this key after this date

635	   o  <StartDate (OPTIONAL)>, the start date of the key, it MUST not be
636	      possible to use this key before this date

638	5.3.1.  Data (OPTIONAL)

640	   Defines the data attributes of the symmetric key.  Each is a name
641	   value pair which has either a plain value (in case of no encryption)
642	   or an encrypted value as defined in EncryptedDataType in XML
643	   Encryption.

645	   This is also where the key value is transported, Section 7 defines a
646	   list of reserved attribute names.

648	   Data element is defined as follows:

650	<xs:complexType name="DataType">
651	    <xs:sequence>
652	    <xs:choice>
653	       <xs:element name="PlainValue" type="xs:base64Binary"/>
654	       <xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>
655	    </xs:choice>
656	    <xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>
657	    </xs:sequence>
658	    <xs:attribute name="Name" type="xs:string" use="required"/>
659	</xs:complexType>

661	   The attributes of the Data element have the following meanings:

663	   o  Name, defines the name of the name-value pair, Section 7 defines a
664	      list of reserved attribute names

666	   The elements of the Data element have the following meanings:

668	   o  The <PlainValue> conveys an unencrypted value of the name-value
669	      pair in base 64 encoding.

671	   o  The <EncryptedValue> element in the DataType conveys an encrypted
672	      value of the name-value pair inside an EncryptedDataType as
673	      defined in XML Encryption.

675	   o  The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed
676	      MAC value of the unencrypted data for the cases where the key
677	      protection algorithm does not support integrity checks

679	5.3.2.  Usage (MANDATORY)

681	   The Usage element defines the usage attribute(s) of the key entity.
682	   Usage is defined as follows:

684	  <xs:complexType name="UsageType">
685	      <xs:sequence>
686	              <xs:element name="ResponseFormat">
687	                      <xs:complexType>
688	                          <xs:attribute name="Format"
689	                          type="pskc:ValueFormatType" use="required"/>
690	                          <xs:attribute name="Length"
691	                          type="xs:unsignedInt" use="required"/>
692	                          <xs:attribute name="CheckDigits"
693	                          type="xs:boolean" default="false"/>
694	                      </xs:complexType>
695	              </xs:element>
696	              <xs:element name="ChallengeFormat" minOccurs="0">
697	                      <xs:complexType>
698	                          <xs:attribute name="Format"
699	                          type="pskc:ValueFormatType" use="required"/>
700	                          <xs:attribute name="Min"
701	                          type="xs:unsignedInt" use="required"/>
702	                          <xs:attribute name="Max"
703	                          type="xs:unsignedInt" use="required"/>
704	                          <xs:attribute name="CheckDigits"
705	                          type="xs:boolean" default="false"/>
706	                      </xs:complexType>
707	              </xs:element>
708	      </xs:sequence>
709	      <xs:attribute name="OTP" type="xs:boolean" default="false"/>
710	      <xs:attribute name="CR" type="xs:boolean" default="false"/>
711	      <xs:attribute name="Integrity" type="xs:boolean" default="false"/>
712	      <xs:attribute name="Encrypt" type="xs:boolean" default="false"/>
713	      <xs:attribute name="Unlock" type="xs:boolean" default="false"/>
714	  </xs:complexType>

716	   The attributes of the Usage element define the intended usage of the
717	   key and are a combination of one or more of the following (set to
718	   true):

720	   o  OTP, the key will be used for OTP generation

722	   o  CR, the key will be used for Challenge/Response purposes

724	   o  Encrypt, the key will be used for data encryption purposes

726	   o  Integrity, the key will be used to generate a keyed message digest
727	      for data integrity or authentication purposes.

729	   o  Unlock, the key will be used for an inverse challenge response in
730	      the case a user has locked the device by entering a wrong PIN too
731	      many times (for devices with PIN-input capability)

733	5.3.2.1.  OTP and CR specific Usage elements (OPTIONAL)

735	   When the key usage is set to OTP or CR, additional attributes MUST be
736	   provided to support the OTP and/or the response computation as
737	   required by the underlying algorithm and to customize or configure
738	   the outcome of the computation (format, length and usage modes).

740	5.3.2.1.1.  ChallengeFormat element (MANDATORY)

742	   The ChallengeFormat element defines the characteristics of the
743	   challenge in a CR usage scenario.  The Challenge element is defined
744	   by the following attributes:

746	   o  Format (MANDATORY)

748	         Defines the format of the challenge accepted by the device and
749	         MUST be one of the values defined in Section 5.3.3

751	   o  CheckDigit (OPTIONAL)

753	         Defines if the device needs to check the appended Luhn check
754	         digit contained in a provided challenge.  This is only valid if
755	         the Format attribute is 'DECIMAL'.  Value MUST be:

757	            TRUE device will check the appended Luhn check digit in a
758	            provided challenge

760	            FALSE device will not check appended Luhn check digit in
761	            challenge

763	   o  Min (MANDATORY)

765	         Defines the minimum size of the challenge accepted by the
766	         device for CR mode.

768	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
769	         'ALPHANUMERIC' this value indicates the minimum number of
770	         digits/characters.

772	         If the Format attribute is 'BASE64' or 'BINARY', this value
773	         indicates the minimum number of bytes of the unencoded value.

775	         Value MUST be:

777	            Unsigned integer.

779	   o  Max (MANDATORY)

781	         Defines the maximum size of the challenge accepted by the
782	         device for CR mode.

784	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
785	         'ALPHANUMERIC' this value indicates the maximum number of
786	         digits/characters.

788	         If the Format attribute is 'BASE64' or 'BINARY', this value
789	         indicates the maximum number of bytes of the unencoded value.

791	         Value MUST be:

793	            Unsigned integer.

795	5.3.2.1.2.  ResponseFormat element (MANDATORY)

797	   The ResponseFormat element defines the characteristics of the result
798	   of a computation.  This defines the format of the OTP or of the
799	   response to a challenge.  The Response attribute is defined by the
800	   following attributes:

802	   o  Format (MANDATORY)

804	         Defines the format of the response generated by the device and
805	         MUST be one of the values defined in Section 5.3.3

807	   o  CheckDigit (OPTIONAL)

809	         Defines if the device needs to append a Luhn check digit to the
810	         response.  This is only valid if the Format attribute is
811	         'DECIMAL'.  Value MUST be:

813	            TRUE device will append a Luhn check digit to the response.

815	            FALSE device will not append a Luhn check digit to the
816	            response.

818	   o  Length (MANDATORY)
819	         Defines the length of the response generated by the device.

821	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
822	         'ALPHANUMERIC' this value indicates the number of digits/
823	         characters.

825	         If the Format attribute is 'BASE64' or 'BINARY', this value
826	         indicates the number of bytes of the unencoded value.

828	         Value MUST be:

830	            Unsigned integer.

832	5.3.3.  ValueFormat

834	   The ValueFormat element defines allowed formats for challenges or
835	   responses in OTP algorithms.

837	   ValueFormat is defined as follows:

839	   <simpleType name="ValueFormat">
840	     <restriction base="string">
841	       <enumeration value="DECIMAL"/>
842	       <enumeration value="HEXADECIMAL"/>
843	       <enumeration value="ALPHANUMERIC"/>
844	       <enumeration value="BASE64"/>
845	       <enumeration value="BINARY"/>
846	     </restriction>
847	   </simpleType>

849	      DECIMAL Only numerical digits

851	      HEXADECIMAL Hexadecimal response

853	      ALPHANUMERIC All letters and numbers (case sensitive)

855	      BASE64 Base 64 encoded

857	      BINARY Binary data, this is mainly used in case of connected
858	      devices

860	5.3.4.  PINPolicy

862	   The PINPolicy element defines a mean to define how the usage of a
863	   specific key is protected by a PIN.  The PIN itself can be
864	   transmitted using the container as another Key

866	   PINPolicy is defined as follows:

868	  <xs:complexType name="PINPolicyType">
869	      <xs:sequence>
870	          <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
871	          <xs:element name="WrongPINtry" type="xs:unsignedInt"
872	            minOccurs="0"/>
873	      </xs:sequence>
874	      <xs:attribute name="PINKeyId" type="xs:string" use="required"/>
875	  </xs:complexType>

877	   The attributes of PINPolicy have the following meaning

879	   o  PINKeyId, the unique key Id within this container that contains
880	      the value of the PIN that protects the key

882	   The elements of PINPolicy have the following meaning

884	   o  <PINUsageMode>, the way the PIN is used during the usage of the
885	      key as defined in Section 5.3.4.1

887	   o  <WrongPINtry>, the number of times the PIN can be entered wrongly
888	      before it MUST not be possible to use the key anymore

890	5.3.4.1.  PINUsageMode

892	   The PINUsageMode element defines how the PIN is used with a specific
893	   key

895	   PINUsageMode is defined as follows:

897	   <xs:complexType name="PINUsageModeType">
898	       <xs:choice maxOccurs="unbounded">
899	           <xs:element name="Local"/>
900	           <xs:element name="Prepend"/>
901	           <xs:element name="InAlgo"/>
902	       </xs:choice>
903	   </xs:complexType>

905	   The elements of PINPolicy have the following meaning

907	   o  <Local>, the PIN is checked locally on the device before allowing
908	      the key to be used in executing the algorithm

910	   o  <Prepend>, the PIN is prepended to the OTP or response hance it
911	      MUST be chacked by the validation server

913	   o  <InAlgo>, the PIN is used as part of the algorithm computation

915	6.  Usage and profile of algorithms for the portable symmetric key
916	    container

918	   This section details the use of the XML encryption and XML signature
919	   elements to protect the keys transported in the cotainer.  It also
920	   profiles the number of algorithms supported by XML encryption and XML
921	   signature to a mandatory subset for interoperability.

923	   When no algorithm is provided the values within the container are
924	   unencrypted, implementations SHALL ensure the privacy of the key data
925	   through other standard mechanisms e.g. transport level encryption.

927	6.1.  Usage of EncryptionKey to protect keys in transit

929	   The EncryptionKey element in the KeyContainer defines the key,
930	   algorithm and parameters used to encrypt the Secret Key data
931	   attributes in the Container.  The encryption is applied on each
932	   individual Secret Key data in the Container.  The encryption method
933	   MUST be the same for all Secret Key data in the container.

935	   The following sections define specifically the different supported
936	   means to protect the keys:

938	6.1.1.  Protecting keys using a pre-shared key via symmetric algorithms

940	   When protecting the payload with pre-shared keys implementations
941	   SHOULD set the name of the specific pre-shared key in the KeyName
942	   element of the EncryptionKey of the KeyContainer.  For example:

944	   <KeyContainer Version="1.0"
945	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
946	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
947	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
948	       <EncryptionKey>
949	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
950	       </EncryptionKey>
951	       ....

953	   The following is the list of symmetric key encryption algorithm and
954	   possible parameters used to protect the Secret Key data in the
955	   container.  Systems implementing PSKC MUST support the MANDATORY
956	   algorithms detailed below.

958	   The encryption algorithm URI can be one of the following.

960	   o  http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY
961	   o  http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY

963	   o  http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL

965	   o  http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY

967	   o  http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY

969	   o  http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY

971	   o  http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY

973	   o  http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL

975	   When algorithms without integrity checks are used (e.g.
976	   http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value using
977	   the same key as the encryption key SHOULD be placed in the ValueMAC
978	   element of the Data element.  In this case the MAC algorithm type
979	   MUST be set in the MACAlgorithm element in the key container entity
980	   as defined in Section 5.1.  Implementations of PSKC MUST support the
981	   MANDATORY MAC algorithms detailed below.  The MACAlgorithm URI can be
982	   one of the following:

984	   o  http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY

986	   For example:

988	   <KeyContainer Version="1.0"
989	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
990	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
991	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
992	       <EncryptionKey>
993	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
994	       </EncryptionKey>
995	       <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
996	       </MACAlgorithm>
997	       .....

999	6.1.2.  Protecting keys using passphrase based encryption keys

1001	   To be able to support passphrase based encryption keys as defined in
1002	   PKCS#5 the following XML representation of the PBE relates parameters
1003	   have been introduced in the schema.  Although the approach is
1004	   extensible implementations of PSKC MUST support the
1005	   KeyDerivationMethod algorithm URI of
1006	   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2.

1008	   <xs:complexType name="DerivedKeyType">
1009	       <xs:sequence>
1010	           <xs:element name="KeyDerivationMethod"
1011	             type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1012	           <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1013	           <xs:element name="CarriedKeyName" type="xs:string"
1014	             minOccurs="0"/>
1015	       </xs:sequence>
1016	       <xs:attribute name="Id" type="xs:ID" use="optional"/>
1017	       <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1018	       </xs:complexType>
1019	       <xs:complexType name="KeyDerivationMethodType">
1020	       <xs:sequence>
1021	               <xs:any namespace="##other" minOccurs="0"
1022	                 maxOccurs="unbounded"/>
1023	       </xs:sequence>
1024	       <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
1025	   </xs:complexType>

1027	   The attributes of the DerivedKey have the following meanings:

1029	   o  ID (OPTIONAL), the unique ID for this key

1031	   o  Type (OPTIONAL), TODO

1033	   The elements of the DerivedKey have the following meanings:

1035	   o  <KeyDerivationMethod>: URI of the algorithms used to derive the
1036	      key e.g.
1037	      (http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)

1039	   o  <ReferenceList (OPTIONAL)>: a list of IDs of the elements that
1040	      have been encrypted by this key

1042	   o  <CarriedKeyName (OPTIONAL)>: friendly name of the key

1044	   When using the PKCS5 PBE algorithm
1045	   (URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
1046	   and related parameters, the DerivedKey element MUST be used within
1047	   the EncryptionKey element of the KeyContainer in exactly the form as
1048	   shown below:

1050	<?xml version="1.0" encoding="UTF-8"?>
1051	<KeyContainer
1052	  xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
1053	  xmlns:pkcs-5=
1054	    "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
1055	  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1056	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1057	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1058	  Version="1.0">
1059	    <EncryptionKey>
1060	      <DerivedKey Id="#Passphrase1">
1061	        <CarriedKeyName>Passphrase1</CarriedKeyName>
1062	        <KeyDerivationMethod
1063	          Algorithm=
1064	        "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
1065	          <Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
1066	            <Salt>
1067	              <Specified>Df3dRAhjGh8=</Specified>
1068	            </Salt>
1069	            <IterationCount>2000</IterationCount>
1070	            <KeyLength>16</KeyLength>
1071	            <PRF/>
1072	          </Parameters>
1073	        </KeyDerivationMethod>
1074	      </DerivedKey>
1075	    </EncryptionKey>
1076	....

1078	6.2.  Protecting keys using asymmetric algorithms

1080	   The following is the list of asymmetric key encryption algorithm and
1081	   possible parameters used to protect the Secret Key data in the
1082	   container.  Systems implementing PSKC MUST support the MANDATORY
1083	   algorithms detailed below.  The encryption algorithm URI can be one
1084	   of the following.

1086	   o  http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY

1088	   o  http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL

1090	   For example:

1092	   TODO

1094	6.3.  Profile of Key Algorithm

1096	   This section profiles the type(s) of algorithm of that can be used by
1097	   the key(s) transported in the container.  The following algorithm
1098	   URIs are among the default support list.

1100	   o  http://www.w3.org/2001/04/xmlenc#tripledes-cbc

1102	   o  http://www.w3.org/2001/04/xmlenc#aes128-cbc

1104	   o  http://www.w3.org/2001/04/xmlenc#aes192-cbc

1106	   o  http://www.w3.org/2001/04/xmlenc#aes256-cbc

1108	   o  http://www.ietf.org/keyprov/pskc#hotp

1110	   o  http://www.ietf.org/keyprov/pskc#valuecompare

1112	6.3.1.  OTP Key Algorithm Identifiers

1114	   OTP key algorithm URIs have not been defined in a commonly available
1115	   standard specification.  This document defines the following URIs for
1116	   the known open standard OTP algorithms.

1118	6.3.1.1.  HOTP

1120	   Standard document: RFC4226

1122	   Identifier: http://www.ietf.org/keyprov/pskc#hotp

1124	   Note that the actual URL will be finalized once a URL for this
1125	   document is determined.

1127	6.3.1.2.  Other OTP Algorithms

1129	   An implementation should refer to vendor supplied OTP key algorithm
1130	   URIs for proprietary algorithms.

1132	6.3.2.  PIN key value compare algorithm identifier

1134	   PIN key algorithm URIs have not been defined in a commonly available
1135	   standard specification.  This document defines the following URIs for
1136	   a straight value comaprison of the transported secret key data as
1137	   when required to compare a PIN.

1139	   Identifier: http://www.ietf.org/keyprov/pskc#valuecompare

1141	   Note that the actual URL will be finalized once a URL for this
1142	   document is determined.

1144	7.  Reserved data attribute names

1146	   The following key data attribute names have been reserved:

1148	      SECRET: the shared secret key value in binary, base64 encoded

1150	      COUNTER: the event counter for event based OTP algorithms. 8 bytes
1151	      unsigned integer in big endian (i.e. network byte order) form
1152	      base64 encoded

1154	      TIME: the time for time based OTP algorithms. 8 bytes unsigned
1155	      integer in big endian (i.e. network byte order) form base64
1156	      encoded (Number of seconds since 1970)

1158	      TIME_INTERVAL: the time interval value for time based OTP
1159	      algorithms. 8 bytes unsigned integer in big endian (i.e. network
1160	      byte order) form base64 encoded.

1162	      TIME_DRIFT: the device clock drift value for time based OTP
1163	      algorithms.  The value indicates number of seconds that the device
1164	      clock may drift each day. 2 bytes unsigned integer in big endian
1165	      (i.e. network byte order) form base64 encoded.

1167	8.  Formal Syntax

1169	   The following syntax specification uses the widely adopted XML schema
1170	   format as defined by a W3C recommendation
1171	   (http://www.w3.org/TR/xmlschema-0/).  It is a complete syntax
1172	   definition in the XML Schema Definition format (XSD)

1174	   All implementations of this standard must comply with the schema
1175	   below.

1177	<?xml version="1.0" encoding="UTF-8"?>
1178	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
1179	  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
1180	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1181	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1182	  targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0"
1183	  elementFormDefault="qualified" attributeFormDefault="unqualified"
1184	  version="1.0">
1185	    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
1186	      schemaLocation=
1187	      "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
1188	      xmldsig-core-schema.xsd"/>
1189	    <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
1190	      schemaLocation="http://www.w3.org/TR/2002/
1191	      REC-xmlenc-core-20021210/xenc-schema.xsd"/>

1193	    <xs:complexType name="KeyContainerType">
1194	    <xs:sequence>
1195	        <xs:element name="EncryptionKey" type="ds:KeyInfoType"
1196	          minOccurs="0"/>
1197	        <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
1198	          minOccurs="0"/>
1199	        <xs:element name="Device" type="pskc:DeviceType"
1200	          maxOccurs="unbounded"/>
1201	        <xs:element name="Signature" type="ds:SignatureType"
1202	          minOccurs="0"/>
1203	    </xs:sequence>
1204	    <xs:attribute name="Version" type="pskc:VersionType"
1205	      use="required"/>
1206	    </xs:complexType>
1207	    <xs:simpleType name="VersionType" final="restriction">
1208	            <xs:restriction base="xs:string">
1209	                    <xs:pattern value="\d{1,2}\.\d{1,3}"/>
1210	            </xs:restriction>
1211	    </xs:simpleType>
1212	    <xs:complexType name="KeyType">
1213	        <xs:sequence>
1214	            <xs:element name="Issuer" type="xs:string" minOccurs="0"/>
1215	            <xs:element name="Usage" type="pskc:UsageType"/>
1216	            <xs:element name="CardAppPersoProfileId" type="xs:string"
1217	              minOccurs="0"/>
1218	            <xs:element name="FriendlyName" type="xs:string"
1219	              minOccurs="0"/>
1220	            <xs:element name="Data" type="pskc:DataType" minOccurs="0"
1221	              maxOccurs="unbounded"/>
1222	            <xs:element name="PINPolicy" type="pskc:PINPolicyType"
1223	              minOccurs="0"/>
1224	            <xs:element name="ExpiryDate" type="xs:dateTime"
1225	              minOccurs="0"/>
1226	            <xs:element name="StartDate" type="xs:dateTime"
1227	              minOccurs="0"/>
1228	        </xs:sequence>
1229	        <xs:attribute name="KeyId" type="xs:string" use="required"/>
1230	        <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
1231	          use="required"/>
1232	    </xs:complexType>
1233	    <xs:complexType name="DerivedKeyType">
1234	        <xs:sequence>
1235	            <xs:element name="KeyDerivationMethod"
1236	              type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1237	            <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1238	            <xs:element name="CarriedKeyName" type="xs:string"
1239	              minOccurs="0"/>
1240	        </xs:sequence>
1241	        <xs:attribute name="Id" type="xs:ID" use="optional"/>
1242	        <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1243	    </xs:complexType>
1244	    <xs:complexType name="KeyDerivationMethodType">
1245	        <xs:sequence>
1246	            <xs:any namespace="##other" minOccurs="0"
1247	            maxOccurs="unbounded"/>
1248	        </xs:sequence>
1249	        <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
1250	    </xs:complexType>
1251	    <xs:complexType name="PINPolicyType">
1252	        <xs:sequence>
1253	            <xs:element name="PINUsageMode"
1254	              type="pskc:PINUsageModeType"/>
1255	            <xs:element name="WrongPINtry" type="xs:unsignedInt"
1256	              minOccurs="0"/>
1257	        </xs:sequence>
1258	        <xs:attribute name="PINKeyId" type="xs:string"
1259	          use="required"/>
1260	    </xs:complexType>
1261	    <xs:complexType name="PINUsageModeType">
1262	            <xs:choice maxOccurs="unbounded">
1263	                    <xs:element name="Local"/>
1264	                    <xs:element name="Prepend"/>
1265	                    <xs:element name="Embed"/>
1266	            </xs:choice>
1267	    </xs:complexType>
1268	    <xs:complexType name="DeviceIdType">
1269	        <xs:sequence>
1270	        <xs:element name="Manufacturer" type="xs:string"/>
1271	        <xs:element name="SerialNo" type="xs:string"/>
1272	        <xs:element name="Model" type="xs:string" minOccurs="0"/>
1273	        <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
1274	        <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
1275	        <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
1276	        </xs:sequence>
1277	    </xs:complexType>
1278	    <xs:complexType name="DeviceType">
1279	      <xs:sequence>
1280	        <xs:element name="DeviceId" type="pskc:DeviceIdType"
1281	          minOccurs="0"/>
1282	        <xs:element name="Key" type="pskc:KeyType"
1283	          maxOccurs="unbounded"/>
1284	        <xs:element name="UserId" type="xs:string" minOccurs="0"/>
1285	      </xs:sequence>
1286	    </xs:complexType>
1287	    <xs:complexType name="UsageType">
1288	        <xs:sequence>
1289	            <xs:element name="ResponseFormat">
1290	                <xs:complexType>
1291	                    <xs:attribute name="Format"
1292	                      type="pskc:ValueFormatType" use="required"/>
1293	                    <xs:attribute name="Length" type="xs:unsignedInt"
1294	                      use="required"/>
1295	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1296	                      default="false"/>
1297	                </xs:complexType>
1298	            </xs:element>
1299	            <xs:element name="ChallengeFormat" minOccurs="0">
1300	                <xs:complexType>
1301	                    <xs:attribute name="Format"
1302	                      type="pskc:ValueFormatType" use="required"/>
1303	                    <xs:attribute name="Min" type="xs:unsignedInt"
1304	                      use="required"/>
1305	                    <xs:attribute name="Max" type="xs:unsignedInt"
1306	                      use="required"/>
1307	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1308	                      default="false"/>
1309	                </xs:complexType>

1311	            </xs:element>
1312	            </xs:sequence>
1313	            <xs:attribute name="OTP" type="xs:boolean" default="false"/>
1314	            <xs:attribute name="CR" type="xs:boolean" default="false"/>
1315	            <xs:attribute name="Integrity" type="xs:boolean"
1316	              default="false"/>
1317	            <xs:attribute name="Encrypt" type="xs:boolean"
1318	              default="false"/>
1319	            <xs:attribute name="Unlock" type="xs:boolean"
1320	              default="false"/>
1321	    </xs:complexType>
1322	    <xs:complexType name="DataType">
1323	        <xs:sequence>
1324	            <xs:choice>
1325	                <xs:element name="PlainValue" type="xs:base64Binary"/>
1326	                <xs:element name="EncryptedValue"
1327	                  type="xenc:EncryptedDataType"/>
1328	            </xs:choice>
1329	            <xs:element name="ValueMAC" type="xs:base64Binary"
1330	              minOccurs="0"/>
1331	        </xs:sequence>
1332	        <xs:attribute name="Name" type="xs:string" use="required"/>
1333	    </xs:complexType>
1334	    <xs:simpleType name="KeyAlgorithmType">
1335	        <xs:restriction base="xs:anyURI"/>
1336	    </xs:simpleType>
1337	    <xs:simpleType name="ValueFormatType">
1338	        <xs:restriction base="xs:string">
1339	            <xs:enumeration value="DECIMAL"/>
1340	            <xs:enumeration value="HEXADECIMAL"/>
1341	            <xs:enumeration value="ALPHANUMERIC"/>
1342	            <xs:enumeration value="BASE64"/>
1343	            <xs:enumeration value="BINARY"/>
1344	        </xs:restriction>
1345	    </xs:simpleType>
1346	    <xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
1347	</xs:schema>
1348	9.  Security Considerations

1350	   The portable key container carries sensitive information (e.g.,
1351	   cryptographic keys) and may be transported across the boundaries of
1352	   one secure perimeter to another.  For example, a container residing
1353	   within the secure perimeter of a back-end provisioning server in a
1354	   secure room may be transported across the internet to an end-user
1355	   device attached to a personal computer.  This means that special care
1356	   must be taken to ensure the confidentiality, integrity, and
1357	   authenticity of the information contained within.

1359	9.1.  Payload confidentiality

1361	   By design, the container allows two main approaches to guaranteeing
1362	   the confidentiality of the information it contains while transported.

1364	   First, the container key data payload may be encrypted.

1366	   In this case no transport layer security is required.  However,
1367	   standard security best practices apply when selecting the strength of
1368	   the cryptographic algorithm for payload encryption.  Symmetric
1369	   cryptographic cipher should be used - the longer the cryptographic
1370	   key, the stronger the protection.  At the time of this writing both
1371	   3DES and AES are recommended algorithms but 3DES may be dropped in
1372	   the relatively near future.  Applications concerned with algorithm
1373	   longevity are advised to use AES.  In cases where the exchange of
1374	   encryption keys between the sender and the receiver is not possible,
1375	   asymmetric encryption of the secret key payload may be employed.
1376	   Similarly to symmetric key cryptography, the stronger the asymmetric
1377	   key, the more secure the protection is.

1379	   If the payload is encrypted with a method that uses one of the
1380	   password-based encryption methods provided above, the payload may be
1381	   subjected to password dictionary attacks to break the encryption
1382	   password and recover the information.  Standard security best
1383	   practices for selection of strong encryption passwords apply
1384	   [Schneier].

1386	   Practical implementations should use PBESalt and PBEIterationCount
1387	   when PBE encryption is used.  Different PBESalt value per key
1388	   container should be used for best protection.

1390	   The second approach to protecting the confidentiality of the payload
1391	   is based on using transport layer security.  The secure channel
1392	   established between the source secure perimeter (the provisioning
1393	   server from the example above) and the target perimeter (the device
1394	   attached to the end-user computer) utilizes encryption to transport
1395	   the messages that travel across.  No payload encryption is required
1396	   in this mode.  Secure channels that encrypt and digest each message
1397	   provide an extra measure of security, especially when the signature
1398	   of the payload does not encompass the entire payload.

1400	   Because of the fact that the plain text payload is protected only by
1401	   the transport layer security, practical implementation must ensure
1402	   protection against man-in-the-middle attacks [Schneier].  Validating
1403	   the secure channel end-points is critically important for eliminating
1404	   intruders that may compromise the confidentiality of the payload.

1406	9.2.  Payload integrity

1408	   The portable symmetric key container provides a mean to guarantee the
1409	   integrity of the information it contains through digital signatures.
1410	   For best security practices, the digital signature of the container
1411	   should encompass the entire payload.  This provides assurances for
1412	   the integrity of all attributes.  It also allows verification of the
1413	   integrity of a given payload even after the container is delivered
1414	   through the communication channel to the target perimeter and channel
1415	   message integrity check is no longer possible.

1417	9.3.  Payload authenticity

1419	   The digital signature of the payload is the primary way of showing
1420	   its authenticity.  The recipient of the container may use the public
1421	   key associated with the signature to assert the authenticity of the
1422	   sender by tracing it back to a preloaded public key or certificate.
1423	   Note that the digital signature of the payload can be checked even
1424	   after the container has been delivered through the secure channel of
1425	   communication.

1427	   A weaker payload authenticity guarantee may be provided by the
1428	   transport layer if it is configured to digest each message it
1429	   transports.  However, no authenticity verification is possible once
1430	   the container is delivered at the recipient end.  This approach may
1431	   be useful in cases where the digital signature of the container does
1432	   not encompass the entire payload.

1434	10.  Acknowledgements

1436	   The authors of this draft would like to thank the following people
1437	   for their contributions and support to make this a better
1438	   specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
1439	   Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
1440	   Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders
1441	   Rundgren.

1443	11.  Appendix A - Example Symmetric Key Containers

1445	   All examples are syntactically correct and compatible with the XML
1446	   schema in section 7.

1448	11.1.  Symmetric Key Container with a single Non-Encrypted HOTP Secret
1449	       Key

1451	   <?xml version="1.0" encoding="UTF-8"?>
1452	   <KeyContainer Version="1.0"
1453	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
1454	       <Device>
1455	           <DeviceId>
1456	               <Manufacturer>ACME</Manufacturer>
1457	               <SerialNo>0755225266</SerialNo>
1458	           </DeviceId>
1459	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1460	             KeyId="0755225266">
1461	               <Issuer>AnIssuer</Issuer>
1462	               <Usage OTP="true">
1463	                   <ResponseFormat Length="6" Format="DECIMAL"/>
1464	               </Usage>
1465	               <Data Name="COUNTER">
1466	                   <PlainValue>AprkuA==</PlainValue>
1467	               </Data>
1468	               <Data Name="SECRET">
1469	                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
1470	               </Data>
1471	               <ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
1472	           </Key>
1473	       </Device>
1474	   </KeyContainer>

1476	11.2.  Symmetric Key Container with a single PIN protected Non-Encrypted
1477	       HOTP Secret Key

1479	   <?xml version="1.0" encoding="UTF-8"?>
1480	   <KeyContainer Version="1.0"
1481	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
1482	       <Device>
1483	           <DeviceId>
1484	               <Manufacturer>ACME</Manufacturer>
1485	               <SerialNo>0755225266</SerialNo>
1486	           </DeviceId>
1487	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1488	             KeyId="0755225266">
1489	               <Issuer>AnIssuer</Issuer>
1490	               <Usage OTP="true">
1491	                   <ResponseFormat Length="6" Format="DECIMAL"/>
1492	               </Usage>
1493	               <Data Name="COUNTER">
1494	                   <PlainValue>AprkuA==</PlainValue>
1495	               </Data>
1496	               <Data Name="SECRET">
1497	                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
1498	               </Data>
1499	               <PINPolicy PINKeyId="07552252661">
1500	                   <PINUsageMode>
1501	                       <Local/>
1502	                   </PINUsageMode>
1503	               </PINPolicy>
1504	           </Key>
1505	           <Key KeyId="07552252661"
1506	             KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
1507	               <Usage>
1508	                   <ResponseFormat Length="4" Format="DECIMAL"/>
1509	               </Usage>
1510	               <Data Name="SECRET">
1511	                   <PlainValue>MTIzNA==</PlainValue>
1512	               </Data>
1513	           </Key>
1514	       </Device>
1515	   </KeyContainer>

1517	11.3.  Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
1518	       Secret Key

1520	<?xml version="1.0" encoding="UTF-8"?>
1521	<KeyContainer Version="1.0"
1522	  xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
1523	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1524	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1525	    <EncryptionKey>
1526	        <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
1527	    </EncryptionKey>
1528	    <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
1529	    </MACAlgorithm>
1530	    <Device>
1531	        <DeviceId>
1532	            <Manufacturer>ACME</Manufacturer>
1533	            <SerialNo>0755225266</SerialNo>
1534	        </DeviceId>
1535	        <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1536	          KeyId="0755225266">
1537	            <Issuer>AnIssuer</Issuer>
1538	            <Usage OTP="true">
1539	                <ResponseFormat Length="8" Format="DECIMAL"/>
1540	            </Usage>
1541	            <Data Name="COUNTER">
1542	                <PlainValue>AprkuA==</PlainValue>
1543	            </Data>
1544	            <Data Name="SECRET">
1545	                <EncryptedValue>
1546	                    <xenc:EncryptionMethod
1547	               Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
1548	                    <xenc:CipherData>
1549	                      <xenc:CipherValue>
1550	                        kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
1551	                      </xenc:CipherValue>
1552	                    </xenc:CipherData>
1553	                </EncryptedValue>
1554	                <ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>
1555	            </Data>
1556	        </Key>
1557	    </Device>
1558	</KeyContainer>

1560	11.4.  Symmetric Key Container with signature and a single Password-
1561	       based Encrypted HOTP Secret Key

1563	 <?xml version="1.0" encoding="UTF-8"?>
1564	 <pskc:KeyContainer
1565	   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
1566	   xmlns:pkcs-5=
1567	     "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
1568	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1569	   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1570	   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1571	   Version="1.0">
1572	     <pskc:EncryptionKey>
1573	       <pskc:DerivedKey Id="#Passphrase1">
1574	         <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
1575	         <pskc:KeyDerivationMethod
1576	           Algorithm=
1577	      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
1578	           <pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
1579	             <Salt>
1580	               <Specified>Df3dRAhjGh8=</Specified>
1581	             </Salt>
1582	             <IterationCount>2000</IterationCount>
1583	             <KeyLength>16</KeyLength>
1584	             <PRF/>
1585	           </pkcs-5:Parameters>
1586	         </pskc:KeyDerivationMethod>
1587	         <xenc:ReferenceList>
1588	           <xenc:DataReference URI="#ED"/>
1589	         </xenc:ReferenceList>
1590	       </pskc:DerivedKey>
1591	     </pskc:EncryptionKey>
1592	   <pskc:Device>
1593	     <pskc:DeviceId>
1594	       <pskc:Manufacturer>ACME</pskc:Manufacturer>
1595	       <pskc:SerialNo>0755225266</pskc:SerialNo>
1596	     </pskc:DeviceId>
1597	         <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1598	           KeyId="0755225266">
1599	             <pskc:Issuer>AnIssuer</pskc:Issuer>
1600	             <pskc:Usage OTP="true">
1601	                 <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
1602	             </pskc:Usage>
1603	             <pskc:Data Name="COUNTER">
1604	                 <pskc:PlainValue>AprkuA==</pskc:PlainValue>
1605	             </pskc:Data>
1606	             <pskc:Data Name="SECRET">
1607	                 <pskc:EncryptedValue Id="ED">
1608	                   <xenc:EncryptionMethod Algorithm=
1609	                   "http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
1610	                   <xenc:CipherData>
1611	                     <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
1612	                     </xenc:CipherValue>
1613	                   </xenc:CipherData>
1614	                 </pskc:EncryptedValue>

1616	             </pskc:Data>
1617	         </pskc:Key>
1618	   </pskc:Device>
1619	   <pskc:Signature>
1620	     <ds:SignedInfo>
1621	       <ds:CanonicalizationMethod
1622	         Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
1623	       <ds:SignatureMethod
1624	         Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
1625	       <ds:Reference URI="">
1626	         <ds:DigestMethod Algorithm=
1627	           "http://www.w3.org/2000/09/xmldsig#sha1"/>
1628	         <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
1629	       </ds:Reference>
1630	     </ds:SignedInfo>
1631	     <ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue>
1632	     <ds:KeyInfo>
1633	       <ds:X509Data>
1634	         <ds:X509IssuerSerial>
1635	           <ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US
1636	           </ds:X509IssuerName>
1637	           <ds:X509SerialNumber>12345678</ds:X509SerialNumber>
1638	         </ds:X509IssuerSerial>
1639	       </ds:X509Data>
1640	     </ds:KeyInfo>
1641	   </pskc:Signature>
1642	 </pskc:KeyContainer>

1644	11.5.  Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
1645	       Secret Key

1647	<?xml version="1.0" encoding="UTF-8"?>
1648	<pskc:KeyContainer Version="1.0"
1649	  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
1650	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1651	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1652	    <pskc:EncryptionKey>
1653	        <ds:X509Data>
1654	            <ds:X509Certificate>miib</ds:X509Certificate>
1655	        </ds:X509Data>
1656	    </pskc:EncryptionKey>
1657	    <pskc:Device>
1658	        <pskc:DeviceId>
1659	            <pskc:Manufacturer>ACME</pskc:Manufacturer>
1660	            <pskc:SerialNo>0755225266</pskc:SerialNo>
1661	        </pskc:DeviceId>
1662	        <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1663	                  KeyId="0755225266">
1664	            <pskc:Issuer>AnIssuer</pskc:Issuer>
1665	            <pskc:Usage OTP="true">
1666	                <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
1667	            </pskc:Usage>
1668	            <pskc:Data Name="COUNTER">
1669	                <pskc:PlainValue>AprkuA==</pskc:PlainValue>
1670	            </pskc:Data>
1671	            <pskc:Data Name="SECRET">
1672	              <pskc:EncryptedValue Id="ED">
1673	                <xenc:EncryptionMethod
1674	                  Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
1675	                <xenc:CipherData>
1676	                  <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
1677	                  </xenc:CipherValue>
1678	                </xenc:CipherData>
1679	              </pskc:EncryptedValue>
1680	            </pskc:Data>
1681	        </pskc:Key>
1682	    </pskc:Device>
1683	</pskc:KeyContainer>
1684	12.  Normative References

1686	   [CAP]      MasterCard International, "Chip Authentication Program
1687	              Functional Architecture", September 2004.

1689	   [DSKPP]    "Dynamic Symmetric Key Provisioning Protocol", Internet
1690	              Draft Informational, URL: http://tools.ietf.org/wg/
1691	              keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.

1693	   [HOTP]     MRaihi, D., "HOTP: An HMAC-Based One Time Password
1694	              Algorithm", RFC 4226,
1695	              URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
1696	              December 2005.

1698	   [OATH]     "Initiative for Open AuTHentication",
1699	              URL: http://www.openauthentication.org.

1701	   [OATHRefArch]
1702	              OATH, "Reference Architecture",
1703	              URL: http://www.openauthentication.org, Version 1.0, 2005.

1705	   [OCRA]     MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
1706	              Internet Draft Informational, URL: http://www.ietf.org/
1707	              internet-drafts/
1708	              draft-mraihi-mutual-oath-hotp-variants-01.txt,
1709	              December 2005.

1711	   [PKCS1]    Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
1712	              Specifications Version 2.0.",
1713	              URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
1714	              October 1998.

1716	   [PKCS12]   RSA Laboratories, "PKCS #12: Personal Information Exchange
1717	              Syntax Standard", Version 1.0,
1718	              URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.

1720	   [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
1721	              Standard", Version 2.0,
1722	              URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
1723	              March 1999.

1725	   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
1726	              Levels", BCP 14, RFC 2119, March 1997,
1727	              <http://www.ietf.org/rfc/rfc2119.txt>.

1729	   [Schneier]
1730	              Schneier, B., "Secrets and Lies: Digitial Security in a
1731	              Networked World",  Wiley Computer Publishing, ISBN 0-8493-
1732	              8253-7, 2000.

1734	   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
1735	              URL: http://www.w3.org/TR/xmlenc-core/, December 2002.

1737	   [XMLSIG]   Eastlake, D., "XML-Signature Syntax and Processing",
1738	              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
1739	              W3C Recommendation, February 2002.

1741	Authors' Addresses

1743	   Philip Hoyer
1744	   ActivIdentity, Inc.
1745	   109 Borough High Street
1746	   London, SE1  1NL
1747	   UK

1749	   Phone: +44 (0) 20 7744 6455
1750	   Email: Philip.Hoyer@actividentity.com

1752	   Mingliang Pei
1753	   VeriSign, Inc.
1754	   487 E. Middlefield Road
1755	   Mountain View, CA  94043
1756	   USA

1758	   Phone: +1 650 426 5173
1759	   Email: mpei@verisign.com

1761	   Salah Machani
1762	   Diversinet, Inc.
1763	   2225 Sheppard Avenue East
1764	   Suite 1801
1765	   Toronto, Ontario  M2J 5C2
1766	   Canada

1768	   Phone: +1 416 756 2324 Ext. 321
1769	   Email: smachani@diversinet.com

1771	Full Copyright Statement

1773	   Copyright (C) The IETF Trust (2008).

1775	   This document is subject to the rights, licenses and restrictions
1776	   contained in BCP 78, and except as set forth therein, the authors
1777	   retain all their rights.

1779	   This document and the information contained herein are provided on an
1780	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1781	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1782	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1783	   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1784	   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1785	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1787	Intellectual Property

1789	   The IETF takes no position regarding the validity or scope of any
1790	   Intellectual Property Rights or other rights that might be claimed to
1791	   pertain to the implementation or use of the technology described in
1792	   this document or the extent to which any license under such rights
1793	   might or might not be available; nor does it represent that it has
1794	   made any independent effort to identify any such rights.  Information
1795	   on the procedures with respect to rights in RFC documents can be
1796	   found in BCP 78 and BCP 79.

1798	   Copies of IPR disclosures made to the IETF Secretariat and any
1799	   assurances of licenses to be made available, or the result of an
1800	   attempt made to obtain a general license or permission for the use of
1801	   such proprietary rights by implementers or users of this
1802	   specification can be obtained from the IETF on-line IPR repository at
1803	   http://www.ietf.org/ipr.

1805	   The IETF invites any interested party to bring to its attention any
1806	   copyrights, patents or patent applications, or other proprietary
1807	   rights that may cover technology that may be required to implement
1808	   this standard.  Please address the information to the IETF at
1809	   ietf-ipr@ietf.org.

1811	Acknowledgment

1813	   Funding for the RFC Editor function is provided by the IETF
1814	   Administrative Support Activity (IASA).