idnits 2.17.1 

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

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

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

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


  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 :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  == Line 1924 has weird spacing: '...inition  http:...'

  == Line 1940 has weird spacing: '...inition  http:...'

  == Line 1956 has weird spacing: '...inition  http:...'

  == Line 1974 has weird spacing: '...inition  http:...'

  == Line 1992 has weird spacing: '...inition  http:...'

  == (3 more instances...)

  == 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 (OPTIONAL)>, 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 (April 21, 2008) is 5846 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: 'PKCS1' is defined on line 2490, but no explicit
     reference was found in the text

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

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

  ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1') (Obsoleted by RFC
     3447)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5'

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

  ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)

  ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC'

  == Outdated reference: A later version (-14) exists of
     draft-mraihi-mutual-oath-hotp-variants-06


     Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 10 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: October 23, 2008                                       VeriSign
6	                                                              S. Machani
7	                                                              Diversinet
8	                                                          April 21, 2008

10	                    Portable Symmetric Key Container
11	       draft-ietf-keyprov-portable-symmetric-key-container-04.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 October 23, 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 (for example One Time Password (OTP)
46	   shared secrets or symmetric cryptographic keys) to different types of
47	   crypto modules such as a strong authentication device.  The standard
48	   key transport format enables enterprises to deploy best-of-breed
49	   solutions combining components from different vendors into the same
50	   infrastructure.

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

59	Table of Contents

61	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
62	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
63	     2.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  6
64	     2.2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
65	   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
66	     3.1.  Online Use Cases . . . . . . . . . . . . . . . . . . . . .  8
67	       3.1.1.  Transport of keys from Server to Crypto Module . . . .  8
68	       3.1.2.  Transport of keys from Crypto Module to Crypto
69	               Module . . . . . . . . . . . . . . . . . . . . . . . .  8
70	       3.1.3.  Transport of keys from Crypto Module to Server . . . .  9
71	       3.1.4.  Server to server Bulk import/export of keys  . . . . .  9
72	     3.2.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . .  9
73	       3.2.1.  Server to server Bulk import/export of keys  . . . . .  9
74	   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
75	   5.  Portable Key container definition  . . . . . . . . . . . . . . 13
76	     5.1.  KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 13
77	     5.2.  Device . . . . . . . . . . . . . . . . . . . . . . . . . . 15
78	       5.2.1.  DeviceId . . . . . . . . . . . . . . . . . . . . . . . 15
79	     5.3.  KeyProperties  . . . . . . . . . . . . . . . . . . . . . . 16
80	     5.4.  Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
81	       5.4.1.  Data (OPTIONAL)  . . . . . . . . . . . . . . . . . . . 20
82	       5.4.2.  Usage (MANDATORY)  . . . . . . . . . . . . . . . . . . 21
83	       5.4.3.  ValueFormat  . . . . . . . . . . . . . . . . . . . . . 25
84	       5.4.4.  PINPolicy  . . . . . . . . . . . . . . . . . . . . . . 26
85	   6.  Usage and profile of algorithms for the portable symmetric
86	       key container  . . . . . . . . . . . . . . . . . . . . . . . . 28
87	     6.1.  Usage of EncryptionKey to protect keys in transit  . . . . 28
88	       6.1.1.  Protecting keys using a pre-shared key via
89	               symmetric algorithms . . . . . . . . . . . . . . . . . 28
90	       6.1.2.  Protecting keys using passphrase based encryption
91	               keys . . . . . . . . . . . . . . . . . . . . . . . . . 29
92	     6.2.  Protecting keys using asymmetric algorithms  . . . . . . . 31
93	     6.3.  Profile of Key Algorithm . . . . . . . . . . . . . . . . . 32
94	       6.3.1.  OTP Key Algorithm Identifiers  . . . . . . . . . . . . 33
95	       6.3.2.  PIN key value compare algorithm identifier . . . . . . 33
96	   7.  Reserved data attribute names  . . . . . . . . . . . . . . . . 34
97	   8.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 35
98	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 40
99	     9.1.  Content-type registration for 'application/pskc+xml' . . . 40
100	     9.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 41
101	     9.3.  URN Sub-Namespace Registration for
102	           urn:ietf:params:xml:ns:keyprov:container:1.0 . . . . . . . 41
103	     9.4.  Symmetric Key Algorithm Identifier Registry  . . . . . . . 42
104	       9.4.1.  Applicability  . . . . . . . . . . . . . . . . . . . . 42
105	       9.4.2.  Registerable Algorithms  . . . . . . . . . . . . . . . 43
106	       9.4.3.  Registration Procedures  . . . . . . . . . . . . . . . 44
107	       9.4.4.  Initial Values . . . . . . . . . . . . . . . . . . . . 46
108	     9.5.  XML Data Tag Identifier Registry . . . . . . . . . . . . . 49
109	       9.5.1.  Applicability  . . . . . . . . . . . . . . . . . . . . 49
110	       9.5.2.  Registerable Data Tags . . . . . . . . . . . . . . . . 50
111	       9.5.3.  Registration Procedures  . . . . . . . . . . . . . . . 50
112	       9.5.4.  Initial Values . . . . . . . . . . . . . . . . . . . . 51
113	   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 53
114	     10.1. Payload confidentiality  . . . . . . . . . . . . . . . . . 53
115	     10.2. Payload integrity  . . . . . . . . . . . . . . . . . . . . 54
116	     10.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 54
117	   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
118	   12. Appendix A - Example Symmetric Key Containers  . . . . . . . . 56
119	     12.1. Symmetric Key Container with a single Non-Encrypted
120	           HOTP Secret Key  . . . . . . . . . . . . . . . . . . . . . 56
121	     12.2. Symmetric Key Container with a single PIN protected
122	           Non-Encrypted HOTP Secret Key  . . . . . . . . . . . . . . 56
123	     12.3. Symmetric Key Container with a single AES-256-CBC
124	           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 57
125	     12.4. Symmetric Key Container with signature and a single
126	           Password-based Encrypted HOTP Secret Key . . . . . . . . . 58
127	     12.5. Symmetric Key Container with a single RSA 1.5
128	           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 60
129	   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
130	     13.1. Normative References . . . . . . . . . . . . . . . . . . . 62
131	     13.2. Informative References . . . . . . . . . . . . . . . . . . 62
132	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
133	   Intellectual Property and Copyright Statements . . . . . . . . . . 65

135	1.  Introduction

137	   With increasing use of symmetric key based authentication systems
138	   such as systems based one time password (OTP) and challenge response
139	   mechanisms, there is a need for vendor interoperability and a
140	   standard format for importing, exporting or provisioning symmetric
141	   keys from one system to another.  Traditionally authentication server
142	   vendors and service providers have used proprietary formats for
143	   importing, exporting and provisioning these keys into their systems
144	   making it hard to use tokens from vendor A with a server from vendor
145	   B.

147	   This Internet draft describes a standard format for serializing
148	   symmetric keys such as OTP shared secrets for system import, export
149	   or network/protocol transport.  The goal is that the format will
150	   facilitate dynamic provisioning and transfer of a symmetric keys such
151	   as an OTP shared secret or an encryption key of different types.  In
152	   the case of OTP shared secrets, the format will facilitate dynamic
153	   provisioning using an online provisioning protocol to different
154	   flavors of embedded tokens or allow customers to import new or
155	   existing tokens in batch or single instances into a compliant system.

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

161	   To provide an analogy, in public key environments the PKCS#12 format
162	   [PKCS12] is commonly used for importing and exporting private keys
163	   and certificates between systems.  In the environments outlined in
164	   this document where OTP keys may be transported directly down to
165	   smartcards or devices with limited computing capabilities, a format
166	   with small (size in bytes) and explicit shared secret configuration
167	   attribute information is desirable, avoiding complexity of PKCS#12.
168	   For example, one would have to use opaque data within PKCS#12 to
169	   carry shared secret attributes used for OTP calculations, whereas a
170	   more explicit attribute schema definition is better for
171	   interoperability and efficiency.

173	2.  Terminology

175	2.1.  Key Words

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

181	2.2.  Definitions

183	   This section defines terms used in this document.  The same terms may
184	   be defined differently in other documents.

186	   Authentication Token:  A physical device that an authorized user of
187	      computer services is given to aid in authentication.  The term may
188	      also refer to software tokens.

190	   Bulk Provisioning:  Transferring multiple keys linked to multiple
191	      devices in a single execution step within one single PSKC
192	      KeyContainer

194	   Cryptographic Module:  A component of an application, which enables
195	      symmetric key cryptographic functionality

197	   Cryptographic Key:  A parameter used in conjunction with a
198	      cryptographic algorithm that determines its operation in such a
199	      way that an entity with knowledge of the key can reproduce or
200	      reverse the operation, while an entity without knowledge of the
201	      key cannot (see [NIST-SP800-57])

203	   Cryptographic Token:  See Authentication Token

205	   Device:  A physical piece of hardware, or a software framework, that
206	      hosts symmetric keys

208	   Device ID (DeviceId):  A unique identifier for the device,
209	      representing the identifying criteria to uniquely identify a
210	      device

212	   Dynamic Provisioning:  Usage of a protocol, such as DSKPP, to make a
213	      key container available to a recipient

215	   Encryption Key:  A key used to encrypt key

217	   Key:  See Cryptographic Key
218	   Hardware Token:  See Authentication Token

220	   Key Algorithm:  A well-defined computational procedure that takes
221	      variable inputs including a cryptographic key and produces an
222	      output.

224	   Key Container:  An object that encapsulates symmetric keys and their
225	      attributes for set of devices

227	   Key ID (KeyID):  A unique identifier for the symmetric key

229	   Key Issuer:  An organization that issues symmetric keys to end-users

231	   Key Type:  The type of symmetric key cryptographic methods for which
232	      the key will be used (e.g., OATH HOTP or RSA SecurID
233	      authentication, AES encryption, etc.)

235	   Secret Key:  The symmetric key data

237	   Software Token:  A type of authentication token that is stored on a
238	      general-purpose electronic device such as a desktop computer,
239	      laptop, PDA, or mobile phone

241	   Token:  See Authentication Token

243	   User:  The person or client to whom devices are issued

245	   User ID:  A unique identifier for the user or client

247	3.  Use Cases

249	   This section describes a comprehensive list of use cases that
250	   inspired the development of this specification.  These requirements
251	   were used to derive the primary requirement that drove the design.
252	   These requirements are covered in the next section.

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

257	3.1.  Online Use Cases

259	   This section describes the use cases related to provisioning the keys
260	   using an online provisioning protocol such as [DSKPP]

262	3.1.1.  Transport of keys from Server to Crypto Module

264	   For example, a mobile device user wants to obtain a symmetric key for
265	   use with a cryptomodule on the device.  The cryptomodule client from
266	   vendor A initiates the provisioning process against a provisioning
267	   system from vendor B using a standards-based provisioning protocol
268	   such as [DSKPP].  The provisioning entity delivers one or more keys
269	   in a standard format that can be processed by the mobile device.

271	   For example, in a variation of the above, instead of the user's
272	   mobile phone, a key is provisioned in the user's soft token
273	   application on a laptop using a network-based online protocol.  As
274	   before, the provisioning system delivers a key in a standard format
275	   that can be processed by the soft token on the PC.

277	   For example, the end-user or the key issuer wants to update or
278	   configure an existing key in the cryptomodule and requests a
279	   replacement key container.  The container may or may not include a
280	   new key and may include new or updated key attributes such as a new
281	   counter value in HOTP key case, a modified response format or length,
282	   a new friendly name, etc.

284	3.1.2.  Transport of keys from Crypto Module to Crypto Module

286	   For example, a user wants to transport a key from one cryptomodule to
287	   another.  There may be two cryptographic modules, one on a computer
288	   one on a mobile phone, and the user wants to transport a key from the
289	   computer to the mobile phone.  The user can export the key and
290	   related data in a standard format for input into the other
291	   cryptomodule.

293	3.1.3.  Transport of keys from Crypto Module to Server

295	   For example, a user wants to activate and use a new key and related
296	   data against a validation system that is not aware of this key.  This
297	   key may be embedded in the cryptomodule (e.g.  SD card, USB drive)
298	   that the user has purchased at the local electronics retailer.  Along
299	   with the cryptomodule, the user may get the key on a CD or a floppy
300	   in a standard format.  The user can now upload via a secure online
301	   channel or import this key and related data into the new validation
302	   system and start using the key.

304	3.1.4.  Server to server Bulk import/export of keys

306	   From time to time, a key management system may be required to import
307	   or export keys in bulk from one entity to another.

309	   For example, instead of importing keys from a manufacturer using a
310	   file, a validation server may download the keys using an online
311	   protocol.  The keys can be downloaded in a standard format that can
312	   be processed by a validation system.

314	   For example, in a variation of the above, an OTA key provisioning
315	   gateway that provisions keys to mobile phones may obtain key material
316	   from a key issuer using an online protocol.  The keys are delivered
317	   in a standard format that can be processed by the key provisioning
318	   gateway and subsequently sent to the end-user's mobile phone.

320	3.2.  Offline Use Cases

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

326	3.2.1.  Server to server Bulk import/export of keys

328	   For example, crypto modules such as OTP authentication tokens, may
329	   have their symmetric keys initialized during the manufacturing
330	   process in bulk, requiring copies of the keys and algorithm data to
331	   be loaded into the authentication system through a file on portable
332	   media.  The manufacturer provides the keys and related data in the
333	   form of a file containing records in standard format, typically on a
334	   CD.  Note that the token manufacturer and the vendor for the
335	   validation system may be the same or different.  Some crypto modules
336	   will allow local PIN management (the device will have a PIN pad)
337	   hence random initial PINs set at manufacturing should be transmitted
338	   together with the respective keys they protect.

340	   For example, an enterprise wants to port keys and related data from
341	   an existing validation system A into a different validation system B.
342	   The existing validation system provides the enterprise with a
343	   functionality that enables export of keys and related data (e.g. for
344	   OTP authentication tokens) in a standard format.  Since the OTP
345	   tokens are in the standard format, the enterprise can import the
346	   token records into the new validation system B and start using the
347	   existing tokens.  Note that the vendors for the two validation
348	   systems may be the same or different.

350	4.  Requirements

352	   This section outlines the most relevant requirements that are the
353	   basis of this work.  Several of the requirements were derived from
354	   use cases described above.

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

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

364	         *  Unique Key Identifier

366	         *  Issuer information

368	         *  Algorithm ID

370	         *  Algorithm mode

372	         *  Issuer Name

374	         *  Key friendly name

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

378	         *  Time value

380	   R3:   The format SHOULD support both offline and online scenarios.
381	         That is it should be serializable to a file as well as it
382	         should be possible to use this format in online provisioning
383	         protocols such as [DSKPP]

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

387	   R5:   The format SHOULD allow bulk representation of PINs related to
388	         specific keys

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

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

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

399	   R9:   The format SHOULD be extensible.  It SHOULD enable extension
400	         points allowing vendors to specify additional attributes in the
401	         future.

403	   R10:  The format SHOULD allow for distribution of key derivation data
404	         without the actual symmetric key itself.  This is to support
405	         symmetric key management schemes that rely on key derivation
406	         algorithms based on a pre-placed master key.  The key
407	         derivation data typically consists of a reference to the key,
408	         rather than the key value itself.

410	   R11:  The format SHOULD allow for additional lifecycle management
411	         operations such as counter resynchronization.  Such processes
412	         require confidentiality between client and server, thus could
413	         use a common secure container format, without the transfer of
414	         key material.

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

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

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

429	5.  Portable Key container definition

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

434	   1.  KeyContainer entity as defined in Section 5.1

436	   2.  Device entity as defined in Section 5.2

438	   3.  Key entity as defined in Section 5.4

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

443	   A KeyContainer MAY contain one or more Device entities.  A Device MAY
444	   contain one or more Key entities

446	   The figure below indicates a possible relationship diagram of a
447	   container.

449	   --------------------------------------------
450	   | KeyContainer                             |
451	   |                                          |
452	   |  ------------------   -----------------  |
453	   |  | Device 1       |   | Device n      |  |
454	   |  |                |   |               |  |
455	   |  |  ------------  |   | ------------  |  |
456	   |  |  | Key 1    |  |   | | Key n    |  |  |
457	   |  |  ------------  |   | ------------  |  |
458	   |  |                |   |               |  |
459	   |  |                |   |               |  |
460	   |  |  ------------  |   | ------------  |  |
461	   |  |  | Key m    |  |   | | Key p    |  |  |
462	   |  |  ------------  |   | ------------  |  |
463	   |  ------------------   -----------------  |
464	   |                                          |
465	   --------------------------------------------

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

470	5.1.  KeyContainer

472	   The KeyContainer represents the key container entity.  A Container
473	   MAY contain more than one Device entity; each Device entity MAY
474	   contain more than one Key entity.

476	   The KeyContainer is defined as follows:

478	 <xs:complexType name="KeyContainerType">
479	         <xs:sequence>
480	                 <xs:element name="EncryptionKey"
481	                         type="ds:KeyInfoType" minOccurs="0"/>
482	                         <xs:element name="MACAlgorithm"
483	                         type="pskc:KeyAlgorithmType" minOccurs="0"/>
484	                         <xs:element name="Device"
485	                         type="pskc:DeviceType" maxOccurs="unbounded"/>
486	                 <xs:element name="Signature"
487	                         type="ds:SignatureType" minOccurs="0"/>
488	         </xs:sequence>
489	   <xs:attribute name="Version" type="pskc:VersionType" use="required"/>
490	 </xs:complexType>

492	   The elements of the KeyContainer have the following meanings:

494	   o  <EncryptionKey (OPTIONAL)>, Identifies the encryption key,
495	      algorithm and possible parameters used to protect the Secret Key
496	      data in the container.  Please see Section 6.1 for detailed
497	      description of how to protect key data in transit and the usage of
498	      this element.

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

506	   o  <Device>, the host Device for one or more Keys as defined in
507	      Section 5.2 The KeyContainer MAY contain multiple Device data
508	      elements, allowing for bulk provisioning of multiple devices each
509	      containing multiple keys.

511	   o  <Signature (OPTIONAL)>, the signature value of the Container.
512	      When the signature is applied to the entire container, it MUST use
513	      XML Signature methods as defined in [XMLDSIG].  It MAY be omitted
514	      when application layer provisioning or transport layer
515	      provisioning protocols provide the integrity and authenticity of
516	      the payload between the sender and the recipient of the container.
517	      When required, this specification recommends using a symmetric key
518	      based signature with the same key used in the encryption of the
519	      secret key data.  The signature is enveloped.

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

524	5.2.  Device

526	   The Device represents the Device entity in the Container.  A Device
527	   MAY be bound to a user and MAY contain more than one keys.  A key
528	   SHOULD be bound to only one Device.

530	   The Device is defined as follows:

532	<xs:complexType name="DeviceType">
533	  <xs:sequence>
534	    <xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>
535	    <xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>
536	    <xs:element name="UserId" type="xs:string" minOccurs="0"/>
537	  </xs:sequence>
538	</xs:complexType>

540	   The elements of the Device have the following meanings:

542	   o  <DeviceId>, a unique identifier for the device, defined in
543	      Section 5.2.1

545	   o  <Key>, represents the key entity as defined in Section 5.4

547	   o  <UserId>, optionally identifies the owner or the user of the
548	      Device, a string representation of a Distinguished Name as defined
549	      in [RFC4514].  For example UID=jsmith,DC=example,DC=net.  In
550	      systems where unique user Ids are used the string representation
551	      'UID=[uniqueId]' MUST be used.

553	5.2.1.  DeviceId

555	   The DeviceId represents the identifying criteria to uniquely identify
556	   the device that contains the associated keys.  Since devices can come
557	   in different form factors such as hardware tokens, smart-cards, soft
558	   tokens in a mobile phone or PC etc this element allows different
559	   criteria to be used.  Combined though the criteria MUST uniquely
560	   identify the device.  For example for hardware tokens the combination
561	   of SerialNo and Manufacturer will uniquely identify a device but not
562	   SerialNo alone since two different token manufacturers might issue
563	   devices with the same serial number (similar to the IssuerDN and
564	   serial number of a certificate).  Symmetric Keys used in the payment
565	   industry are usually stored on Integrated Circuit Smart Cards.  These
566	   cards are uniquely identified via the Primary Account Number (PAN,
567	   the long number printed on the front of the card) and an expiry date
568	   of the card.  DeviceId is an extensible type that allows all these
569	   different ways to uniquely identify a specific key containing device.

571	   The DeviceId is defined as follows:

573	   <xs:complexType name="DeviceIdType">
574	   <xs:sequence>
575	       <xs:element name="Manufacturer" type="xs:string"/>
576	       <xs:element name="SerialNo" type="xs:string"/>
577	       <xs:element name="Model" type="xs:string" minOccurs="0"/>
578	       <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
579	       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
580	       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
581	   </xs:sequence>
582	   </xs:complexType>

584	   The elements of DeviceId have the following meanings:

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

588	   o  <SerialNo>, the serial number of the device or the PAN (primary
589	      account number) in case of payment smart cards.

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

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

596	   o  <ExpiryDate>, the expiry date of a device (such as the one on a
597	      payment card,used when issue numbers are not printed on cards).

599	   o  <StartDate>, the start date of a device (such as the one on a
600	      payment card,used when issue numbers are not printed on cards).

602	5.3.  KeyProperties

604	   The KeyProperties represents common properties shared by more than
605	   one key held in the container.  If a value is set in the properties
606	   the Key element can refer to it via KeyPropertiesId attribute.
607	   Values that are present in the Key element itself MUST take
608	   precendence over values set in KeyProperties.  The KeyProperties is
609	   defined as follows:

611	   <xs:complexType name="KeyPropertiesType">
612	           <xs:sequence>
613	                   <xs:element name="Issuer" type="xs:string"
614	                   minOccurs="0"/>
615	                   <xs:element name="Usage" type="pskc:UsageType"
616	                   minOccurs="0"/>
617	                   <xs:element name="KeyProfileId" type="xs:string"
618	                   minOccurs="0"/>
619	                   <xs:element name="MasterKeyId" type="xs:string"
620	                   minOccurs="0"/>
621	                   <xs:element name="Data" type="pskc:DataType"
622	                   minOccurs="0" maxOccurs="unbounded"/>
623	                   <xs:element name="PINPolicy"
624	                   type="pskc:PINPolicyType" minOccurs="0"/>
625	                   <xs:element name="ExpiryDate"
626	                   type="xs:dateTime" minOccurs="0"/>
627	                   <xs:element name="StartDate" type="xs:dateTime"
628	                   minOccurs="0"/>
629	           </xs:sequence>
630	           <xs:attribute name="KeyPropertiesId" type="xs:string"
631	           use="required"/>
632	           <xs:attribute name="KeyAlgorithm"
633	           type="pskc:KeyAlgorithmType" use="optional"/>
634	   </xs:complexType>

636	   The attributes of the KeyProperties entity have the following
637	   meanings:

639	   o  KeyPropertiesId (MANDATORY), a unique and global identifier of set
640	      of KeyProperties.  The identifier is defined as a string of
641	      alphanumeric characters.

643	   o  <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm
644	      to use with the secret key, for profiles are described in
645	      Section 6.3

647	   Since KeyProperties are a method to commonalise the elements in Key
648	   please refer to section Section 5.4 for detailed description of all
649	   elements.

651	5.4.  Key

653	   The Key represents the key entity in the KeyContainer.  The Key is
654	   defined as follows:

656	   <xs:complexType name="KeyType">
657	           <xs:sequence>
658	                   <xs:element name="Issuer" type="xs:string"
659	                   minOccurs="0"/>
660	                   <xs:element name="Usage" type="pskc:UsageType"
661	                   minOccurs="0"/>
662	                   <xs:element name="KeyProfileId" type="xs:string"
663	                   minOccurs="0"/>
664	                   <xs:element name="MasterKeyId" type="xs:string"
665	                   minOccurs="0"/>
666	                   <xs:element name="FriendlyName" type="xs:string"
667	                   minOccurs="0"/>
668	                   <xs:element name="Data" type="pskc:DataType"
669	                   minOccurs="0" maxOccurs="unbounded"/>
670	                   <xs:element name="PINPolicy"
671	                   type="pskc:PINPolicyType" minOccurs="0"/>
672	                   <xs:element name="ExpiryDate" type="xs:dateTime"
673	                   minOccurs="0"/>
674	                   <xs:element name="StartDate" type="xs:dateTime"
675	                   minOccurs="0"/>
676	           </xs:sequence>
677	           <xs:attribute name="KeyId" type="xs:string"
678	           use="required"/>
679	           <xs:attribute name="KeyAlgorithm"
680	           type="pskc:KeyAlgorithmType" use="optional"/>
681	           <xs:attribute name="KeyPropertiesId" type="xs:string"
682	           use="optional"/>
683	   </xs:complexType>

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

687	   o  KeyId (MANDATORY), a unique and global identifier of the symmetric
688	      key.  The identifier is defined as a string of alphanumeric
689	      characters.

691	   o  <KeyAlgorithm (OPTIONAL)>, the unique URI of the type of algorithm
692	      to use with the secret key, for profiles are described in
693	      Section 6.3

695	   o  <KeyPropertiesId (OPTIONAL)>, the unique id of the KeyProperties
696	      whose value the instance of this key inherits.  If this value is
697	      set implementation MUST lookup the Keyproperties element referred
698	      to by this unique Id and this instance of key will inherit all
699	      values from the KeyProperties.  Values held in the key instance it
700	      MUST take precedence over values inherited from KeyProperties."/>

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

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

710	   o  <Usage (MANDATORY)>, defines the intended usage of the key and
711	      related metadata as defined in Section 5.4.2

713	   o  <KeyProfileId (OPTIONAL)>, A unique identifier used between the
714	      sending and receiving party of the container to establish a set of
715	      constant values related to a key that are not transmitted via the
716	      container.  For example a smart card application personalisation
717	      profile id related to attributes present on a smart card
718	      application that have influence when computing a response.  An
719	      example could be an EMV MasterCard CAP [CAP] application on a card
720	      personalised with data for a specific batch of cards such as:

722	         IAF Internet authentication flag

724	         CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
725	         VISA 13, VISA14)

727	         AIP (Application Interchange Profile), 2 bytes

729	         TVR Terminal Verification Result, 5 bytes

731	         CVR The card verification result

733	         AmountOther

735	         TransactionDate

737	         TerminalCountryCode

739	         TransactionCurrencyCode

741	         AmountAuthorised

743	         IIPB

745	      These values are not contained within attributes in the container
746	      but are shared between the manufacturing and the validation
747	      service through this unique KeyProfileId.  The KeyProfileId is
748	      defined as a String.

750	   o  <MasterKeyId (OPTIONAL)>, The unique reference to a master key
751	      when key derivation schemes are used and no specific key is
752	      transported but only the reference to the master key used to
753	      derive a specific key and some derivation data.

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

759	   o  <Data (OPTIONAL)>, the element carrying the data related to the
760	      key as defined in Section 5.4.1

762	   o  <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the
763	      usage of this key as defined in Section 5.4.4

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

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

771	5.4.1.  Data (OPTIONAL)

773	   Defines the data attributes of the symmetric key.  Each is a name
774	   value pair which has either a plain value (in case of no encryption)
775	   or a encrypted value as defined in EncryptedDataType in XML
776	   Encryption.

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

781	   Data element is defined as follows:

783	<xs:complexType name="DataType">
784	    <xs:sequence>
785	    <xs:choice>
786	       <xs:element name="PlainValue" type="xs:base64Binary"/>
787	       <xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>
788	    </xs:choice>
789	    <xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>
790	    </xs:sequence>
791	    <xs:attribute name="Name" type="xs:string" use="required"/>
792	</xs:complexType>

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

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

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

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

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

808	   o  The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed
809	      MAC value of the unencrypted data for the cases where the
810	      algorithm to protect key data in transit, as described in section
811	      Section 6.1.1 ,does not support integrity checks.

813	5.4.2.  Usage (MANDATORY)

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

818	   <xs:complexType name="UsageType">
819	           <xs:sequence>
820	                   <xs:element name="ChallengeFormat" minOccurs="0">
821	                           <xs:complexType>
822	                             <xs:attribute name="Format"
823	                             type="pskc:ValueFormatType"
824	                             use="required"/>
825	                             <xs:attribute name="Min"
826	                             type="xs:unsignedInt" use="required"/>
827	                             <xs:attribute name="Max"
828	                             type="xs:unsignedInt" use="required"/>
829	                             <xs:attribute name="CheckDigits"
830	                             type="xs:boolean" default="false"/>
831	                           </xs:complexType>
832	                   </xs:element>
833	                   <xs:element name="ResponseFormat">
834	                           <xs:complexType>
835	                             <xs:attribute name="Format"
836	                             type="pskc:ValueFormatType"
837	                             use="required"/>
838	                             <xs:attribute name="Length"
839	                             type="xs:unsignedInt" use="required"/>
840	                             <xs:attribute name="CheckDigits"
841	                             type="xs:boolean" default="false"/>
842	                           </xs:complexType>
843	                   </xs:element>
844	           </xs:sequence>
845	           <xs:attribute name="OTP" type="xs:boolean"
846	           default="false"/>
847	           <xs:attribute name="CR" type="xs:boolean"
848	           default="false"/>
849	           <xs:attribute name="Integrity" type="xs:boolean"
850	           default="false"/>
851	           <xs:attribute name="Encrypt" type="xs:boolean"
852	           default="false"/>
853	           <xs:attribute name="Unlock" type="xs:boolean"
854	           default="false"/>
855	   </xs:complexType>

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

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

863	   o  CR, the key will be used for Challenge/Response purposes
864	   o  Encrypt, the key will be used for data encryption purposes

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

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

873	5.4.2.1.  OTP and CR specific Usage elements (OPTIONAL)

875	   When the intended usage of a key usage is OTP and/or CR, the
876	   following additional elements MUST be provided within the Usage
877	   element to support the OTP and/or the response computation as
878	   required by the underlying algorithm.  These elements also allow to
879	   customize or configure the result of the computation (e.g. format,
880	   length).

882	5.4.2.1.1.  ChallengeFormat element (MANDATORY)

884	   The ChallengeFormat element defines the characteristics of the
885	   challenge in a CR usage scenario.  The Challenge element is defined
886	   by the following attributes:

888	   o  Format (MANDATORY)

890	         Defines the format of the challenge accepted by the device and
891	         MUST be one of the values defined in Section 5.4.3

893	   o  CheckDigit (OPTIONAL)

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

899	            TRUE device will check the appended Luhn check digit in a
900	            provided challenge

902	            FALSE device will not check appended Luhn check digit in
903	            challenge

905	   o  Min (MANDATORY)

907	         Defines the minimum size of the challenge accepted by the
908	         device for CR mode.

910	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
911	         'ALPHANUMERIC' this value indicates the minimum number of
912	         digits/characters.

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

917	         Value MUST be:

919	            Unsigned integer.

921	   o  Max (MANDATORY)

923	         Defines the maximum size of the challenge accepted by the
924	         device for CR mode.

926	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
927	         'ALPHANUMERIC' this value indicates the maximum number of
928	         digits/characters.

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

933	         Value MUST be:

935	            Unsigned integer.

937	5.4.2.1.2.  ResponseFormat element (MANDATORY)

939	   The ResponseFormat element defines the characteristics of the result
940	   of a computation.  This defines the format of the OTP or of the
941	   response to a challenge.  The Response attribute is defined by the
942	   following attributes:

944	   o  Format (MANDATORY)

946	         Defines the format of the response generated by the device and
947	         MUST be one of the values defined in Section 5.4.3

949	   o  CheckDigit (OPTIONAL)
950	         Defines if the device needs to append a Luhn check digit to the
951	         response.  This is only valid if the Format attribute is
952	         'DECIMAL'.  Value MUST be:

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

956	            FALSE device will not append a Luhn check digit to the
957	            response.

959	   o  Length (MANDATORY)

961	         Defines the length of the response generated by the device.

963	         If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
964	         'ALPHANUMERIC' this value indicates the number of digits/
965	         characters.

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

970	         Value MUST be:

972	            Unsigned integer.

974	5.4.3.  ValueFormat

976	   The ValueFormat element defines allowed formats for challenges or
977	   responses in OTP algorithms.

979	   ValueFormat is defined as follows:

981	   <simpleType name="ValueFormat">
982	     <restriction base="string">
983	       <enumeration value="DECIMAL"/>
984	       <enumeration value="HEXADECIMAL"/>
985	       <enumeration value="ALPHANUMERIC"/>
986	       <enumeration value="BASE64"/>
987	       <enumeration value="BINARY"/>
988	     </restriction>
989	   </simpleType>
990	      DECIMAL Only numerical digits

992	      HEXADECIMAL Hexadecimal response

994	      ALPHANUMERIC All letters and numbers (case sensitive)

996	      BASE64 Base 64 encoded

998	      BINARY Binary data, this is mainly used in case of connected
999	      devices

1001	5.4.4.  PINPolicy

1003	   The PINPolicy element provides a mean to define how the usage of a
1004	   specific key is protected by a PIN.  The PIN itself can be
1005	   transmitted as a key using the container.

1007	   If the PINPolicy element is present in the Key element then the key
1008	   is protected with a PIN as defined within the PINPolicy element.

1010	   PINPolicy is defined as follows:

1012	  <xs:complexType name="PINPolicyType">
1013	      <xs:sequence>
1014	          <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
1015	          <xs:element name="WrongPINtry" type="xs:unsignedInt"
1016	            minOccurs="0"/>
1017	      </xs:sequence>
1018	      <xs:attribute name="PINKeyId" type="xs:string" use="required"/>
1019	  </xs:complexType>

1021	   The attributes of PINPolicy have the following meaning

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

1026	   The elements of PINPolicy have the following meaning

1028	   o  <PINUsageMode (MANDATORY)> , the way the PIN is used during the
1029	      usage of the key as defined in Section 5.4.4.1

1031	   o  <WrongPINtry (OPTIONAL)>, the number of times the PIN can be
1032	      entered wrongly before it MUST not be possible to use the key
1033	      anymore

1035	5.4.4.1.  PINUsageMode

1037	   The PINUsageMode element defines how the PIN is used with a specific
1038	   key

1040	   PINUsageMode is defined as follows:

1042	   <xs:complexType name="PINUsageModeType">
1043	       <xs:choice maxOccurs="unbounded">
1044	           <xs:element name="Local"/>
1045	           <xs:element name="Prepend"/>
1046	           <xs:element name="InAlgo"/>
1047	       </xs:choice>
1048	   </xs:complexType>

1050	   The elements of PINPolicy have the following meaning

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

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

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

1060	6.  Usage and profile of algorithms for the portable symmetric key
1061	    container

1063	   This section details the use of the XML encryption and XML signature
1064	   elements to protect the keys transported in the cotainer.  It also
1065	   profiles the number of algorithms supported by XML encryption and XML
1066	   signature to a mandatory subset for interoperability.

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

1072	6.1.  Usage of EncryptionKey to protect keys in transit

1074	   The EncryptionKey element in the KeyContainer defines the key,
1075	   algorithm and parameters used to encrypt the Secret Key data
1076	   attributes in the Container.  The standard schema [XMLENC] is adopted
1077	   in carry such information and an encrypted value.  The encryption is
1078	   applied on each individual Secret Key data in the Container.  The
1079	   encryption method MUST be the same for all Secret Key data in the
1080	   container.

1082	   The following sections define specifically the different supported
1083	   means to protect the keys:

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

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

1091	   <KeyContainer Version="1.0"
1092	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
1093	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1094	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1095	       <EncryptionKey>
1096	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
1097	       </EncryptionKey>
1098	       ....

1100	   The following is the list of symmetric key encryption algorithm and
1101	   possible parameters used to protect the Secret Key data in the
1102	   container.  Systems implementing PSKC MUST support the MANDATORY
1103	   algorithms detailed below.

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

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

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

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

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

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

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

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

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

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

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

1134	   For example:

1136	   <KeyContainer Version="1.0"
1137	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
1138	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1139	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1140	       <EncryptionKey>
1141	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
1142	       </EncryptionKey>
1143	       <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
1144	       </MACAlgorithm>
1145	       .....

1147	6.1.2.  Protecting keys using passphrase based encryption keys

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

1156	   <xs:complexType name="DerivedKeyType">
1157	       <xs:sequence>
1158	           <xs:element name="KeyDerivationMethod"
1159	             type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1160	           <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1161	           <xs:element name="CarriedKeyName" type="xs:string"
1162	             minOccurs="0"/>
1163	       </xs:sequence>
1164	       <xs:attribute name="Id" type="xs:ID" use="optional"/>
1165	       <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1166	       </xs:complexType>
1167	       <xs:complexType name="KeyDerivationMethodType">
1168	       <xs:sequence>
1169	               <xs:any namespace="##other" minOccurs="0"
1170	                 maxOccurs="unbounded"/>
1171	       </xs:sequence>
1172	       <xs:attribute name="Algorithm" type="xs:anyURI"
1173	       use="required"/>
1174	   </xs:complexType>

1176	   The attributes of the DerivedKey have the following meanings:

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

1180	   o  Type (OPTIONAL), This attribute was included for conformance with
1181	      xml encryption, it is an optional attribute identifying type
1182	      information about the plaintext form of the encrypted content.
1183	      Please see [XMLENC] section 3.1 Type for more details.

1185	   The elements of the DerivedKey have the following meanings:

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

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

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

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

1202	   <?xml version="1.0" encoding="UTF-8"?>
1203	   <KeyContainer
1204	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
1205	     xmlns:pkcs-5=
1206	       "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
1207	     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1208	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1209	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1210	     Version="1.0">
1211	       <EncryptionKey>
1212	         <DerivedKey Id="#Passphrase1">
1213	           <CarriedKeyName>Passphrase1</CarriedKeyName>
1214	           <KeyDerivationMethod
1215	             Algorithm=
1216	        "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
1217	             <Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
1218	               <Salt>
1219	                 <Specified>Df3dRAhjGh8=</Specified>
1220	               </Salt>
1221	               <IterationCount>2000</IterationCount>
1222	               <KeyLength>16</KeyLength>
1223	               <PRF/>
1224	             </Parameters>
1225	           </KeyDerivationMethod>
1226	         </DerivedKey>
1227	       </EncryptionKey>
1228	   ....

1230	6.2.  Protecting keys using asymmetric algorithms

1232	   The following is the list of asymmetric key encryption algorithm and
1233	   possible parameters used to protect the Secret Key data in the
1234	   container.  Systems implementing PSKC MUST support the MANDATORY
1235	   algorithms detailed below.  The encryption algorithm URI can be one
1236	   of the following.

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

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

1242	   For example:

1244	   <?xml version="1.0" encoding="UTF-8"?>

1246	   <pskc:KeyContainer Version="1.0"
1247	     xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
1248	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1249	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1250	       <pskc:EncryptionKey>
1251	           <ds:X509Data>
1252	               <ds:X509Certificate>miib</ds:X509Certificate>
1253	           </ds:X509Data>
1254	       </pskc:EncryptionKey>
1255	       <pskc:Device>
1256	           <pskc:DeviceId>
1257	               <pskc:Manufacturer>ACME</pskc:Manufacturer>
1258	               <pskc:SerialNo>0755225266</pskc:SerialNo>
1259	           </pskc:DeviceId>
1260	           <pskc:Key KeyAlgorithm=
1261	            "http://www.ietf.org/keyprov/pskc#hotp"
1262	            KeyId="0755225266">
1263	               <pskc:Issuer>AnIssuer</pskc:Issuer>
1264	               <pskc:Usage OTP="true">
1265	                   <pskc:ResponseFormat Length="8"
1266	                   Format="DECIMAL"/>
1267	               </pskc:Usage>
1268	               <pskc:Data Name="COUNTER">
1269	                   <pskc:PlainValue>AprkuA==</pskc:PlainValue>
1270	               </pskc:Data>
1271	               <pskc:Data Name="SECRET">
1272	                 <pskc:EncryptedValue Id="ED">
1273	                   <xenc:EncryptionMethod
1274	                     Algorithm=
1275	                     "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
1276	                   <xenc:CipherData>
1277	                     <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
1278	                     </xenc:CipherValue>
1279	                   </xenc:CipherData>
1280	                 </pskc:EncryptedValue>
1281	               </pskc:Data>
1282	           </pskc:Key>
1283	       </pskc:Device>
1284	   </pskc:KeyContainer>

1286	6.3.  Profile of Key Algorithm

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

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

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

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

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

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

1302	   o  http://www.ietf.org/keyprov/pskc#pin

1304	6.3.1.  OTP Key Algorithm Identifiers

1306	   OTP key algorithm URIs have not been defined in a commonly available
1307	   standard specification.  This document defines the following URIs for
1308	   the standard OTP algorithms defined in [HOTP].

1310	6.3.1.1.  HOTP

1312	   Standard document: RFC4226

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

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

1319	6.3.1.2.  Other OTP Algorithms

1321	   An implementation should refer to vendor registered OTP key algorithm
1322	   URIs for other existing OTP algorithms, for example, the RSA SecurID
1323	   OTP algorithm as follows.

1325	   o  http://www.rsa.com/rsalabs/otps/schemas/2005/09/
1326	      otps-wst#SecurID-AES

1328	6.3.2.  PIN key value compare algorithm identifier

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

1335	   Identifier: http://www.ietf.org/keyprov/pskc#pin

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

1340	7.  Reserved data attribute names

1342	   The following key data attribute names have been reserved:

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

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

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

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

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

1363	8.  Formal Syntax

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

1370	   All implementations of this standard must comply with the schema
1371	   below.

1373	<?xml version="1.0" encoding="UTF-8"?>
1374	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
1375	  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
1376	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1377	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1378	  targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0"
1379	  elementFormDefault="qualified" attributeFormDefault="unqualified"
1380	  version="1.0">
1381	    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
1382	      schemaLocation=
1383	      "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
1384	      xmldsig-core-schema.xsd"/>
1385	    <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
1386	      schemaLocation="http://www.w3.org/TR/2002/
1387	      REC-xmlenc-core-20021210/xenc-schema.xsd"/>

1389	    <xs:complexType name="KeyContainerType">
1390	    <xs:sequence>
1391	        <xs:element name="EncryptionKey" type="ds:KeyInfoType"
1392	          minOccurs="0"/>
1393	        <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
1394	          minOccurs="0"/>
1395	        <xs:element name="Device" type="pskc:DeviceType"
1396	          maxOccurs="unbounded"/>
1397	        <xs:element name="Signature" type="ds:SignatureType"
1398	          minOccurs="0"/>
1399	    </xs:sequence>
1400	    <xs:attribute name="Version" type="pskc:VersionType"
1401	      use="required"/>
1402	    </xs:complexType>
1403	    <xs:simpleType name="VersionType" final="restriction">
1404	            <xs:restriction base="xs:string">
1405	                    <xs:pattern value="\d{1,2}\.\d{1,3}"/>
1406	            </xs:restriction>
1407	    </xs:simpleType>
1408	        <xs:complexType name="KeyPropertiesType">
1409	                <xs:sequence>
1410	                        <xs:element name="Issuer"
1411	                        type="xs:string" minOccurs="0"/>
1412	                        <xs:element name="Usage"
1413	                        type="pskc:UsageType" minOccurs="0"/>
1414	                        <xs:element name="KeyProfileId"
1415	                        type="xs:string" minOccurs="0"/>
1416	                        <xs:element name="MasterKeyId"
1417	                        type="xs:string" minOccurs="0"/>
1418	                        <xs:element name="Data" type="pskc:DataType"
1419	                        minOccurs="0" maxOccurs="unbounded"/>
1420	                        <xs:element name="PINPolicy"
1421	                        type="pskc:PINPolicyType" minOccurs="0"/>
1422	                        <xs:element name="ExpiryDate"
1423	                        type="xs:dateTime" minOccurs="0"/>
1424	                        <xs:element name="StartDate"
1425	                        type="xs:dateTime" minOccurs="0"/>
1426	                </xs:sequence>
1427	                <xs:attribute name="KeyPropertiesId"
1428	                type="xs:string" use="required"/>
1429	                <xs:attribute name="KeyAlgorithm"
1430	                type="pskc:KeyAlgorithmType"
1431	                use="optional"/>
1432	        </xs:complexType>
1433	    <xs:complexType name="KeyType">
1434	        <xs:sequence>
1435	            <xs:element name="Issuer"
1436	            type="xs:string" minOccurs="0"/>
1437	            <xs:element name="Usage"
1438	            type="pskc:UsageType"/>
1439	                        <xs:element name="KeyProfileId"
1440	                        type="xs:string" minOccurs="0"/>
1441	                        <xs:element name="MasterKeyId"
1442	                        type="xs:string" minOccurs="0"/>
1443	            <xs:element name="FriendlyName"
1444	            type="xs:string" minOccurs="0"/>
1445	            <xs:element name="Data" type="pskc:DataType"
1446	            minOccurs="0" maxOccurs="unbounded"/>
1447	            <xs:element name="PINPolicy"
1448	            type="pskc:PINPolicyType" minOccurs="0"/>
1449	            <xs:element name="ExpiryDate"
1450	            type="xs:dateTime" minOccurs="0"/>
1451	            <xs:element name="StartDate"
1452	            type="xs:dateTime" minOccurs="0"/>
1453	        </xs:sequence>
1454	        <xs:attribute name="KeyId"
1455	        type="xs:string" use="required"/>
1456	        <xs:attribute name="KeyAlgorithm"
1457	        type="pskc:KeyAlgorithmType"
1458	          use="required"/>
1459	    </xs:complexType>
1460	    <xs:complexType name="DerivedKeyType">
1461	        <xs:sequence>
1462	            <xs:element name="KeyDerivationMethod"
1463	              type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1464	            <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1465	            <xs:element name="CarriedKeyName" type="xs:string"
1466	              minOccurs="0"/>
1467	        </xs:sequence>
1468	        <xs:attribute name="Id" type="xs:ID" use="optional"/>
1469	        <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1470	    </xs:complexType>
1471	    <xs:complexType name="KeyDerivationMethodType">
1472	        <xs:sequence>
1473	            <xs:any namespace="##other" minOccurs="0"
1474	            maxOccurs="unbounded"/>
1475	        </xs:sequence>
1476	        <xs:attribute name="Algorithm" type="xs:anyURI"
1477	        use="required"/>
1478	    </xs:complexType>
1479	    <xs:complexType name="PINPolicyType">
1480	        <xs:sequence>
1481	            <xs:element name="PINUsageMode"
1482	              type="pskc:PINUsageModeType"/>
1483	            <xs:element name="WrongPINtry" type="xs:unsignedInt"
1484	              minOccurs="0"/>
1485	        </xs:sequence>
1486	        <xs:attribute name="PINKeyId" type="xs:string"
1487	          use="required"/>
1488	    </xs:complexType>
1489	    <xs:complexType name="PINUsageModeType">
1490	            <xs:choice maxOccurs="unbounded">
1491	                    <xs:element name="Local"/>
1492	                    <xs:element name="Prepend"/>
1493	                    <xs:element name="Embed"/>
1494	            </xs:choice>
1495	    </xs:complexType>
1496	    <xs:complexType name="DeviceIdType">
1497	        <xs:sequence>
1498	        <xs:element name="Manufacturer" type="xs:string"/>
1499	        <xs:element name="SerialNo" type="xs:string"/>
1500	        <xs:element name="Model" type="xs:string"
1501	        minOccurs="0"/>
1502	        <xs:element name="IssueNo" type="xs:string"
1503	        minOccurs="0"/>
1504	        <xs:element name="ExpiryDate" type="xs:dateTime"
1505	        minOccurs="0"/>
1506	        <xs:element name="StartDate" type="xs:dateTime"
1507	        minOccurs="0"/>
1508	        </xs:sequence>
1509	    </xs:complexType>
1510	    <xs:complexType name="DeviceType">
1511	      <xs:sequence>
1512	        <xs:element name="DeviceId" type="pskc:DeviceIdType"
1513	          minOccurs="0"/>
1514	        <xs:element name="Key" type="pskc:KeyType"
1515	          maxOccurs="unbounded"/>
1516	        <xs:element name="UserId" type="xs:string"
1517	        minOccurs="0"/>
1518	      </xs:sequence>
1519	    </xs:complexType>
1520	    <xs:complexType name="UsageType">
1521	        <xs:sequence>
1522	            <xs:element name="ChallengeFormat" minOccurs="0">
1523	                <xs:complexType>
1524	                    <xs:attribute name="Format"
1525	                      type="pskc:ValueFormatType" use="required"/>
1526	                    <xs:attribute name="Min" type="xs:unsignedInt"
1527	                      use="required"/>
1528	                    <xs:attribute name="Max" type="xs:unsignedInt"
1529	                      use="required"/>
1530	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1531	                      default="false"/>
1532	                </xs:complexType>
1533	            </xs:element>
1534	            <xs:element name="ResponseFormat">
1535	                <xs:complexType>
1536	                    <xs:attribute name="Format"
1537	                      type="pskc:ValueFormatType" use="required"/>
1538	                    <xs:attribute name="Length" type="xs:unsignedInt"
1539	                      use="required"/>
1540	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1541	                      default="false"/>
1542	                </xs:complexType>
1543	            </xs:element>
1544	            </xs:sequence>
1545	            <xs:attribute name="OTP" type="xs:boolean" default="false"/>
1546	            <xs:attribute name="CR" type="xs:boolean" default="false"/>
1547	            <xs:attribute name="Integrity" type="xs:boolean"
1548	              default="false"/>
1549	            <xs:attribute name="Encrypt" type="xs:boolean"
1550	              default="false"/>
1551	            <xs:attribute name="Unlock" type="xs:boolean"
1552	              default="false"/>
1553	    </xs:complexType>
1554	    <xs:complexType name="DataType">
1555	        <xs:sequence>
1556	            <xs:choice>
1557	                <xs:element name="PlainValue" type="xs:base64Binary"/>
1558	                <xs:element name="EncryptedValue"
1559	                  type="xenc:EncryptedDataType"/>
1560	            </xs:choice>
1561	            <xs:element name="ValueMAC" type="xs:base64Binary"
1562	              minOccurs="0"/>
1563	        </xs:sequence>
1564	        <xs:attribute name="Name" type="xs:string" use="required"/>
1565	    </xs:complexType>
1566	    <xs:simpleType name="KeyAlgorithmType">
1567	        <xs:restriction base="xs:anyURI"/>
1568	    </xs:simpleType>
1569	    <xs:simpleType name="ValueFormatType">
1570	        <xs:restriction base="xs:string">
1571	            <xs:enumeration value="DECIMAL"/>
1572	            <xs:enumeration value="HEXADECIMAL"/>
1573	            <xs:enumeration value="ALPHANUMERIC"/>
1574	            <xs:enumeration value="BASE64"/>
1575	            <xs:enumeration value="BINARY"/>
1576	        </xs:restriction>
1577	    </xs:simpleType>
1578	    <xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
1579	</xs:schema>
1580	9.  IANA Considerations

1582	9.1.  Content-type registration for 'application/pskc+xml'

1584	   This specification requests the registration of a new MIME type
1585	   according to the procedures of RFC 4288 [RFC4288] and guidelines in
1586	   RFC 3023 [RFC3023].

1588	   MIME media type name:  application

1590	   MIME subtype name:  pskc+xml

1592	   Mandatory parameters:  none

1594	   Optional parameters:  charset

1596	      Indicates the character encoding of enclosed XML.

1598	   Encoding considerations:  Uses XML, which can employ 8-bit
1599	      characters, depending on the character encoding used.  See RFC
1600	      3023 [RFC3023], Section 3.2.

1602	   Security considerations:  This content type is designed to carry PSKC
1603	      protocol payloads.

1605	   Interoperability considerations:  None

1607	   Published specification:  RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
1608	      replace XXXX with the RFC number of this specification.]

1610	   Applications which use this media type:  This MIME type is being used
1611	      as a symmetric key container format for transport and provisioning
1612	      of symmetric keys (One Time Password (OTP) shared secrets or
1613	      symmetric cryptographic keys) to different types of strong
1614	      authentication devices.  As such, it is used for key provisioning
1615	      systems.

1617	   Additional information:

1619	      Magic Number:  None

1621	      File Extension:  .pskcxml

1623	      Macintosh file type code:  'TEXT'

1625	   Personal and email address for further information:  Philip Hoyer,
1626	      Philip.Hoyer@actividentity.com

1628	   Intended usage:  LIMITED USE

1630	   Author:  This specification is a work item of the IETF KEYPROV
1631	      working group, with mailing list address <keyprov@ietf.org>.

1633	   Change controller:  The IESG <iesg@ietf.org>

1635	9.2.  XML Schema Registration

1637	   This section registers an XML schema as per the guidelines in
1638	   [RFC3688].

1640	   URI:  urn:ietf:params:xml:ns:keyprov:container:1.0

1642	   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
1643	      (Philip.Hoyer@actividentity.com).

1645	   XML Schema:  The XML schema to be registered is contained in
1646	      Section 8.  Its first line is

1648	   <?xml version="1.0" encoding="UTF-8"?>

1650	      and its last line is

1652	   </xs:schema>

1654	9.3.  URN Sub-Namespace Registration for
1655	      urn:ietf:params:xml:ns:keyprov:container:1.0

1657	   This section registers a new XML namespace,
1658	   "urn:ietf:params:xml:ns:keyprov:container:1.0", per the guidelines in
1659	   [RFC3688].

1661	   URI:  urn:ietf:params:xml:ns:keyprov:container:1.0

1663	   Registrant Contact:  IETF KEYPROV Working Group, Philip Hoyer
1664	      (Philip.Hoyer@actividentity.com).

1666	   XML:

1668	   BEGIN
1669	   <?xml version="1.0"?>
1670	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1671	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1672	   <html xmlns="http://www.w3.org/1999/xhtml">
1673	   <head>
1674	     <meta http-equiv="content-type"
1675	           content="text/html;charset=iso-8859-1"/>
1676	     <title>PSKC Namespace</title>
1677	   </head>
1678	   <body>
1679	     <h1>Namespace for PSKC</h1>
1680	     <h2>urn:ietf:params:xml:ns:keyprov:container:1.0</h2>
1681	   <p>See <a href="[URL of published RFC]">RFCXXXX
1682	       [NOTE TO IANA/RFC-EDITOR:
1683	        Please replace XXXX with the RFC number of this
1684	       specification.]</a>.</p>
1685	   </body>
1686	   </html>
1687	   END

1689	9.4.  Symmetric Key Algorithm Identifier Registry

1691	   This specification requests the creation of a new IANA registry for
1692	   symmetric key cryptographic algorithm identifiers in accordance with
1693	   the principles set out in RFC 2434 [RFC2434]as follows:

1695	9.4.1.  Applicability

1697	   The use of URIs as algorithm identifiers provides an effectively
1698	   unlimited namespace.  While this eliminates the possibility of
1699	   namespace exhaustion it creates a new concern, that divergent
1700	   identifiers will be employed for the same purpose in different
1701	   contexts.

1703	   The key algorithm registry is intended to provide a means of
1704	   specifying the canonical identifier to be used for a given algorithm.
1705	   If an algorithm has an identifier specified in the registry a
1706	   application that is conformant to a protocol specification that
1707	   specifies use of that registry to define identifiers SHOULD always
1708	   use that particular form of the identifier when originating data.  A
1709	   conformant application MAY accept other identifiers in data that is
1710	   received.

1712	   For the sake of expediency, the initial registry only defines
1713	   algorithm classes for symmetric algorithms plus cryptographic message
1714	   digest functions (one-way hash).  While the same principles may be
1715	   extended to asymmetric algorithms, doing so would require much
1716	   greater consideration of issues such as key length and treatment of
1717	   parameters, particularly where eliptic curve cryptography algorithms
1718	   are concerned.

1720	   As part of this registry the IANA will maintain the following
1721	   information:

1723	   Common Name  The name by which the algorithm is generally referred.

1725	   Class  The type of algorithm, encryption, Message Authentication Code
1726	      (MAC), One Time Pawword (OTP), Digest, etc.

1728	   Cannonical URI  The cannonical URI to be used to identify the
1729	      algorithm.

1731	   Algorithm Definition  A reference to the document in which the
1732	      algorithm described by the identifier is defined.

1734	   Identifier Definition  A reference to the document in which the use
1735	      of the identifier to refer to the algorithm is described.  This
1736	      would ideally be the document in which the algorithm is defined.

1738	      In the case where the registrant does not request a particular
1739	      URI, the IANA will assign it a Uniform Resource Name (URN) that
1740	      follows RFC 3553 [RFC3553].

1742	   Note that where a single algorithm has different forms distinguished
1743	   by paremeters such as key length, the algorithm class and each
1744	   combination of algorithm parameters may be considered a distinct
1745	   algorithm for the purpose of assigning identifiers.

1747	9.4.2.  Registerable Algorithms

1749	9.4.2.1.  Assigned URIs

1751	   If the registrant wishes to have a URI assigned, then a URN of the
1752	   form

1754	   urn:ietf:params:xml:<class>:<id>

1756	   will be assigned where <class> is the type of the algorithm being
1757	   identified (see below). <id> is a unique id specified by the party
1758	   making the request and will normally be either the common name of the
1759	   algorithm or an abbreviation thereof.

1761	   NOTE: in order for a URN of this type to be assigned, the item being
1762	   registered MUST have been through the IETF consensus process.
1763	   Basically, this means that it must be documented in a RFC.

1765	   NOTE: Expert Review is sufficient in cases where the request does not
1766	   require a URN assignment inthe IETF namespace.  IETF consensus is not
1767	   required.

1769	9.4.2.2.  Assigned Classes

1771	   Each algorithm MUST belong to an assigned algorithm class.  In the
1772	   case that additional classes are required these are to be specified
1773	   by IETF Consensus action.

1775	   The initial assigned classes are:

1777	   Digest  A cryptographic Digest algorithm.

1779	   MAC  A Message Authentication Code algorithm.

1781	   Symmetric  A symmetric encryption algorithm.

1783	   OTP  A one time password (OTP) algorithm.

1785	9.4.3.  Registration Procedures

1787	9.4.3.1.  Review

1789	   Algorithm identifier registrations are to be subject to Expert Review
1790	   as per RFC 2434 [RFC2434].

1792	   The need for supporting documentation for the registration depends on
1793	   the nature of the request.  In the case of a cryptographic algorithm
1794	   that is being described for publication as an RFC, the request for a
1795	   URI allocation would normally appear within the RFC itself.  In the
1796	   case of a cryptographic algorithm that is fully and comprehensively
1797	   defined in another form, it would not be necessary to duplicate the
1798	   information for the sake of issuing the information in the RFC
1799	   series.  In other cases an RFC may be required in order to ensure
1800	   that certain algorithm parameters are sufficiently and unambiguously
1801	   defined.

1803	   The scope of such expert review is to be strictly limited to
1804	   identifying possible ambiguity and/or duplication of existing
1805	   identifiers.  The expert review MUST NOT consider the cryptographic
1806	   properties, intellectual property considerations or any other factor
1807	   not related to the use of the identifier.

1809	   In reviewing a request, the expert should consider whether other URI
1810	   identifiers are already defined for a given algorithm.  In such cases
1811	   it is the duty of the expert to bring the potential duplication to
1812	   the notice of the proposers of the registration and the Security Area
1813	   Directors.  If the proposers are not willing to accept registration
1814	   of the existing identifier the IETF Consensus policy is to apply.

1816	   In reviewing a request, the expert should consider whether the
1817	   algorithm is sufficiently defined to allow successful interoperation.
1818	   In particular the expert should consider whether issues such as key
1819	   sizes and byte order are sufficiently defined to allow for
1820	   interoperation.

1822	   While the defintion requirement MAY be satisifed by a comprehensive
1823	   specification of the algorithm, disclosure of the algorithm is not
1824	   mandatory.

1826	9.4.3.2.  Canonical URI

1828	   Until the IANA requests or implements an automated process for the
1829	   registration of these elements, any specifications must make that
1830	   request part of the IANA considerations section of their respective
1831	   documents.  That request must be in the form of the following
1832	   template:

1834	   Common Name  The name by which the algorithm is generally referred.

1836	   Class  The type of algorithm, encryption, Message Authentication Code
1837	      (MAC), One Time Pawword (OTP), Digest, etc.  As specified by a
1838	      defined algorithm class.

1840	   URI  The cannonical URI to be used to identify the algorithm.

1842	   Algorithm Definition  A reference to the document in which the
1843	      algorithm described by the identifier is defined.

1845	   Identifier Definition  A reference to the document in which the use
1846	      of the identifier to refer to the algorithm is described.  This
1847	      would ideally be the document in which the algorithm is defined.

1849	   Registrant Contact  A reference to the document in which the use of
1850	      the identifier to refer to the algorithm is described.  This would
1851	      ideally be the document in which the algorithm is defined.

1853	9.4.3.3.  Alias URI

1855	   In the case that multiple identifiers have been assigned to the same
1856	   identifiers, additional identifiers MAY be registered as aliases.  An
1857	   entry for an alias contains all the entries for a canonical URI with
1858	   the addition of a reference to the canonical URI to be used:

1860	   Alias for URI  The cannonical URI that identifies the algorithm.  The
1861	      URI referenced MUST be a canonical URI.

1863	   In the case of dispute as to which URI is to be considered canonical
1864	   the matter is to be settled by IESG action.

1866	9.4.4.  Initial Values

1868	   The following initial values are defined.  Note that these values are
1869	   limited to identifiers that are required by KEYPROV but not specified
1870	   elsewhere:

1872	9.4.4.1.  HOTP

1874	   Common Name:  HOTP

1876	   Class:  OTP

1878	   URI:  http://www.ietf.org/keyprov/pskc#hotp

1880	   Algorithm Definition:  http://www.ietf.org/rfc/rfc4226.txt

1882	   Identifier Definition  (this RFC)

1884	   Registrant Contact:  IESG

1886	9.4.4.2.  HOTP-HMAC-SHA-1

1888	   Common Name:  HOTP-HMAC-SHA-1

1890	   Class:  OTP

1892	   URI:  http://www.ietf.org/rfc/rfc4226.txt#HOTP-HMAC-SHA-1

1894	   Algorithm Definition:  http://www.ietf.org/rfc/rfc4226.txt

1896	   Identifier Definition  (this RFC)

1898	   Registrant Contact:  IESG

1900	9.4.4.3.  KEYPROV-PIN

1902	   Common Name:  KEYPROV-PIN

1904	   Class:  Symmetric static credential comparison
1905	   URI:  http://www.ietf.org/keyprov/pskc#pin

1907	   Algorithm Definition:  (this document)

1909	   Identifier Definition  (this document)

1911	   Registrant Contact:  IESG

1913	9.4.4.4.  SecurID-AES

1915	   Common Name:  SecurID-AES

1917	   Class:  OTP

1919	   URI:  http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
1920	      otps-wst#SecurID-AES

1922	   Algorithm Definition:  http://www.rsa.com/rsalabs/node.asp?id=2821

1924	   Identifier Definition  http://www.rsa.com/rsalabs/node.asp?id=2821

1926	   Registrant Contact:  Andrea Doherty, RSA the Security Division of
1927	      EMC, <andrea.doherty@rsa.com>

1929	9.4.4.5.  SecurID-ALGOR

1931	   Common Name:  SecurID-ALGOR

1933	   Class:  OTP

1935	   URI:  http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
1936	      otps-wst#SecurID-ALGOR

1938	   Algorithm Definition:  http://www.rsa.com/rsalabs/node.asp?id=2821

1940	   Identifier Definition  http://www.rsa.com/rsalabs/node.asp?id=2821

1942	   Registrant Contact:  Andrea Doherty, RSA the Security Division of
1943	      EMC, <andrea.doherty@rsa.com>

1945	9.4.4.6.  ActivIdentity-3DES

1947	   Common Name:  ActivIdentity-3DES

1949	   Class:  OTP
1950	   URI:  http://www.actividentity.com/2008/04/algorithms/
1951	      algorithms#ActivIdentity-3DES

1953	   Algorithm Definition:  http://www.actividentity.com/2008/04/
1954	      algorithms/algorithms#ActivIdentity-3DES

1956	   Identifier Definition  http://www.actividentity.com/2008/04/
1957	      algorithms/algorithms#ActivIdentity-3DES

1959	   Registrant Contact:  Philip Hoyer, ActivIdentity Inc,
1960	      <philip.hoyer@actividentity.com>

1962	9.4.4.7.  ActivIdentity-AES

1964	   Common Name:  ActivIdentity-AES

1966	   Class:  OTP

1968	   URI:  http://www.actividentity.com/2008/04/algorithms/
1969	      algorithms#ActivIdentity-AES

1971	   Algorithm Definition:  http://www.actividentity.com/2008/04/
1972	      algorithms/algorithms#ActivIdentity-AES

1974	   Identifier Definition  http://www.actividentity.com/2008/04/
1975	      algorithms/algorithms#ActivIdentity-AES

1977	   Registrant Contact:  Philip Hoyer, ActivIdentity Inc,
1978	      <philip.hoyer@actividentity.com>

1980	9.4.4.8.  ActivIdentity-DES

1982	   Common Name:  ActivIdentity-DES

1984	   Class:  OTP

1986	   URI:  http://www.actividentity.com/2008/04/algorithms/
1987	      algorithms#ActivIdentity-DES

1989	   Algorithm Definition:  http://www.actividentity.com/2008/04/
1990	      algorithms/algorithms#ActivIdentity-DES

1992	   Identifier Definition  http://www.actividentity.com/2008/04/
1993	      algorithms/algorithms#ActivIdentity-DES

1995	   Registrant Contact:  Philip Hoyer, ActivIdentity Inc,
1996	      <philip.hoyer@actividentity.com>

1998	9.4.4.9.  ActivIdentity-EVENT

2000	   Common Name:  ActivIdentity-EVENT

2002	   Class:  OTP

2004	   URI:  http://www.actividentity.com/2008/04/algorithms/
2005	      algorithms#ActivIdentity-EVENT

2007	   Algorithm Definition:  http://www.actividentity.com/2008/04/
2008	      algorithms/algorithms#ActivIdentity-EVENT

2010	   Identifier Definition  http://www.actividentity.com/2008/04/
2011	      algorithms/algorithms#ActivIdentity-EVENT

2013	   Registrant Contact:  Philip Hoyer, ActivIdentity Inc,
2014	      <philip.hoyer@actividentity.com>

2016	9.5.  XML Data Tag Identifier Registry

2018	   This specification requests the creation of a new IANA registry for
2019	   XML Data Tag identifiers in accordance with the principles set out in
2020	   RFC 2434 [RFC2434]as follows:

2022	   [More explanation of why an escape to tag value lists is desirable
2023	   when inserting unstructured data into an XML schema]

2025	9.5.1.  Applicability

2027	   As part of this registry the IANA will maintain the following
2028	   information:

2030	   Common Name  Common name for by which the tag is referred to

2032	   Cannonical URI  The cannonical URI to be employed when citing the
2033	      tag.

2035	   Data Type  The data type of the data that is bound to the tag.

2037	    Definition  A reference to the document in which the data tag
2038	      defined by the identifier is defined.

2040	   In the case where the registrant does not request a particular URI,
2041	   the IANA will assign it a Uniform Resource Name (URN) that follows
2042	   RFC 3553 [RFC3553].

2044	9.5.2.  Registerable Data Tags

2046	9.5.2.1.  Assigned URIs

2048	   If the registrant wishes to have a URI assigned, then a URN of the
2049	   form

2051	   urn:ietf:params:xml:datatag:<tag>

2053	   will be assigned where <tag> is a unique id specified by the party
2054	   making the request and will normally be either the common name of the
2055	   tag or an abbreviation thereof.

2057	   NOTE: in order for a URN of this type to be assigned, the item being
2058	   registered MUST have been through the IETF consensus process.
2059	   Basically, this means that it must be documented in a RFC.

2061	   NOTE: Expert Review is sufficient in cases where the request does not
2062	   require a URN assignment inthe IETF namespace.  IETF consensus is not
2063	   required.

2065	9.5.3.  Registration Procedures

2067	9.5.3.1.  Review

2069	   Data tag registrations are to be subject to Expert Review as per RFC
2070	   2434 [RFC2434].

2072	9.5.3.2.  Data Tag Entry

2074	   Until the IANA requests or implements an automated process for the
2075	   registration of these elements, any specifications must make that
2076	   request part of the IANA considerations section of their respective
2077	   documents.  That request must be in the form of the following
2078	   template:

2080	   Common Name  Common name for by which the tag is referred to

2082	   Cannonical URI  The cannonical URI to be employed when citing the
2083	      tag.

2085	   Data Type  The data type of the data that is bound to the tag.

2087	    Definition  A reference to the document in which the data tag
2088	      defined by the identifier is defined.

2090	9.5.4.  Initial Values

2092	   The following initial values are defined.  Note that these values are
2093	   limited to identifiers that are required by KEYPROV but not specified
2094	   elsewhere:

2096	9.5.4.1.  Secret

2098	   Common Name  Secret

2100	   Cannonical URI  urn:ietf:params:xml:datatag:secret

2102	   Data Type  binary, base64 encoded

2104	   Defined in  (this document)

2106	9.5.4.2.  Counter

2108	   Common Name  Counter

2110	   Cannonical URI  urn:ietf:params:xml:datatag:counter

2112	   Data Type  8 bytes unsigned integer in big endian (i.e. network byte
2113	      order) form base64 encoded

2115	   Defined in  (this document)

2117	9.5.4.3.  Time

2119	   Common Name  Time

2121	   Cannonical URI  urn:ietf:params:xml:datatag:time

2123	   Data Type  8 bytes unsigned integer in big endian (i.e. network byte
2124	      order) form base64 encoded (Number of seconds since 1970)

2126	   Defined in  (this document)

2128	9.5.4.4.  Time Interval

2130	   Common Name  Time Interval

2132	   Cannonical URI  urn:ietf:params:xml:datatag:time_interval

2134	   Data Type  8 bytes unsigned integer in big endian (i.e. network byte
2135	      order) form base64 encoded.

2137	   Defined in  (this document)

2139	9.5.4.5.  Time Drift

2141	   Common Name  urn:ietf:params:xml:datatag:time_drift

2143	   Cannonical URI  Time Drift

2145	   Data Type  2 bytes unsigned integer in big endian (i.e. network byte
2146	      order) form base64 encoded.

2148	   Defined in  (this document)

2150	10.  Security Considerations

2152	   The portable key container carries sensitive information (e.g.,
2153	   cryptographic keys) and may be transported across the boundaries of
2154	   one secure perimeter to another.  For example, a container residing
2155	   within the secure perimeter of a back-end provisioning server in a
2156	   secure room may be transported across the internet to an end-user
2157	   device attached to a personal computer.  This means that special care
2158	   must be taken to ensure the confidentiality, integrity, and
2159	   authenticity of the information contained within.

2161	10.1.  Payload confidentiality

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

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

2168	   In this case no transport layer security is required.  However,
2169	   standard security best practices apply when selecting the strength of
2170	   the cryptographic algorithm for payload encryption.  Symmetric
2171	   cryptographic cipher should be used - the longer the cryptographic
2172	   key, the stronger the protection.  At the time of this writing both
2173	   3DES and AES are mandatory algorithms but 3DES may be dropped in the
2174	   relatively near future.  Applications concerned with algorithm
2175	   longevity are advised to use AES-256-CBC.  In cases where the
2176	   exchange of encryption keys between the sender and the receiver is
2177	   not possible, asymmetric encryption of the secret key payload may be
2178	   employed.  Similarly to symmetric key cryptography, the stronger the
2179	   asymmetric key, the more secure the protection is.

2181	   If the payload is encrypted with a method that uses one of the
2182	   password-based encryption methods provided above, the payload may be
2183	   subjected to password dictionary attacks to break the encryption
2184	   password and recover the information.  Standard security best
2185	   practices for selection of strong encryption passwords apply
2186	   [Schneier].

2188	   Practical implementations should use PBESalt and PBEIterationCount
2189	   when PBE encryption is used.  Different PBESalt value per key
2190	   container should be used for best protection.

2192	   The second approach to protecting the confidentiality of the payload
2193	   is based on using transport layer security.  The secure channel
2194	   established between the source secure perimeter (the provisioning
2195	   server from the example above) and the target perimeter (the device
2196	   attached to the end-user computer) utilizes encryption to transport
2197	   the messages that travel across.  No payload encryption is required
2198	   in this mode.  Secure channels that encrypt and digest each message
2199	   provide an extra measure of security, especially when the signature
2200	   of the payload does not encompass the entire payload.

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

2208	10.2.  Payload integrity

2210	   The portable symmetric key container provides a mean to guarantee the
2211	   integrity of the information it contains through digital signatures.
2212	   For best security practices, the digital signature of the container
2213	   should encompass the entire payload.  This provides assurances for
2214	   the integrity of all attributes.  It also allows verification of the
2215	   integrity of a given payload even after the container is delivered
2216	   through the communication channel to the target perimeter and channel
2217	   message integrity check is no longer possible.

2219	10.3.  Payload authenticity

2221	   The digital signature of the payload is the primary way of showing
2222	   its authenticity.  The recipient of the container may use the public
2223	   key associated with the signature to assert the authenticity of the
2224	   sender by tracing it back to a preloaded public key or certificate.
2225	   Note that the digital signature of the payload can be checked even
2226	   after the container has been delivered through the secure channel of
2227	   communication.

2229	   A weaker payload authenticity guarantee may be provided by the
2230	   transport layer if it is configured to digest each message it
2231	   transports.  However, no authenticity verification is possible once
2232	   the container is delivered at the recipient end.  This approach may
2233	   be useful in cases where the digital signature of the container does
2234	   not encompass the entire payload.

2236	11.  Acknowledgements

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

2245	12.  Appendix A - Example Symmetric Key Containers

2247	   All examples are syntactically correct and compatible with the XML
2248	   schema in section 7.

2250	12.1.  Symmetric Key Container with a single Non-Encrypted HOTP Secret
2251	       Key

2253	   <?xml version="1.0" encoding="UTF-8"?>
2254	   <KeyContainer Version="1.0"
2255	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
2256	       <Device>
2257	           <DeviceId>
2258	               <Manufacturer>ACME</Manufacturer>
2259	               <SerialNo>0755225266</SerialNo>
2260	           </DeviceId>
2261	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2262	             KeyId="0755225266">
2263	               <Issuer>AnIssuer</Issuer>
2264	               <Usage OTP="true">
2265	                   <ResponseFormat Length="6" Format="DECIMAL"/>
2266	               </Usage>
2267	               <Data Name="COUNTER">
2268	                   <PlainValue>AprkuA==</PlainValue>
2269	               </Data>
2270	               <Data Name="SECRET">
2271	                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
2272	               </Data>
2273	               <ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
2274	           </Key>
2275	       </Device>
2276	   </KeyContainer>

2278	12.2.  Symmetric Key Container with a single PIN protected Non-Encrypted
2279	       HOTP Secret Key

2281	   <?xml version="1.0" encoding="UTF-8"?>
2282	   <KeyContainer Version="1.0"
2283	     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
2284	       <Device>
2285	           <DeviceId>
2286	               <Manufacturer>ACME</Manufacturer>
2287	               <SerialNo>0755225266</SerialNo>
2288	           </DeviceId>
2289	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2290	             KeyId="0755225266">
2291	               <Issuer>AnIssuer</Issuer>
2292	               <Usage OTP="true">
2293	                   <ResponseFormat Length="6" Format="DECIMAL"/>
2294	               </Usage>
2295	               <Data Name="COUNTER">
2296	                   <PlainValue>AprkuA==</PlainValue>
2297	               </Data>
2298	               <Data Name="SECRET">
2299	                   <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
2300	               </Data>
2301	               <PINPolicy PINKeyId="07552252661">
2302	                   <PINUsageMode>
2303	                       <Local/>
2304	                   </PINUsageMode>
2305	               </PINPolicy>
2306	           </Key>
2307	           <Key KeyId="07552252661"
2308	             KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
2309	               <Usage>
2310	                   <ResponseFormat Length="4" Format="DECIMAL"/>
2311	               </Usage>
2312	               <Data Name="SECRET">
2313	                   <PlainValue>MTIzNA==</PlainValue>
2314	               </Data>
2315	           </Key>
2316	       </Device>
2317	   </KeyContainer>

2319	12.3.  Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
2320	       Secret Key

2322	<?xml version="1.0" encoding="UTF-8"?>
2323	<KeyContainer Version="1.0"
2324	  xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
2325	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
2326	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
2327	    <EncryptionKey>
2328	        <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
2329	    </EncryptionKey>
2330	    <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
2331	    </MACAlgorithm>
2332	    <Device>
2333	        <DeviceId>
2334	            <Manufacturer>ACME</Manufacturer>
2335	            <SerialNo>0755225266</SerialNo>
2336	        </DeviceId>
2337	        <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2338	          KeyId="0755225266">
2339	            <Issuer>AnIssuer</Issuer>
2340	            <Usage OTP="true">
2341	                <ResponseFormat Length="8" Format="DECIMAL"/>
2342	            </Usage>
2343	            <Data Name="COUNTER">
2344	                <PlainValue>AprkuA==</PlainValue>
2345	            </Data>
2346	            <Data Name="SECRET">
2347	                <EncryptedValue>
2348	                    <xenc:EncryptionMethod
2349	               Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
2350	                    <xenc:CipherData>
2351	                      <xenc:CipherValue>
2352	                        kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
2353	                      </xenc:CipherValue>
2354	                    </xenc:CipherData>
2355	                </EncryptedValue>
2356	                <ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>
2357	            </Data>
2358	        </Key>
2359	    </Device>
2360	</KeyContainer>

2362	12.4.  Symmetric Key Container with signature and a single Password-
2363	       based Encrypted HOTP Secret Key

2365	 <?xml version="1.0" encoding="UTF-8"?>
2366	 <pskc:KeyContainer
2367	   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
2368	   xmlns:pkcs-5=
2369	     "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
2370	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2371	   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
2372	   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
2373	   Version="1.0">
2374	     <pskc:EncryptionKey>
2375	       <pskc:DerivedKey Id="#Passphrase1">
2376	         <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
2377	         <pskc:KeyDerivationMethod
2378	           Algorithm=
2379	      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
2380	           <pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
2381	             <Salt>
2382	               <Specified>Df3dRAhjGh8=</Specified>
2383	             </Salt>
2384	             <IterationCount>2000</IterationCount>
2385	             <KeyLength>16</KeyLength>
2386	             <PRF/>
2387	           </pkcs-5:Parameters>
2388	         </pskc:KeyDerivationMethod>
2389	         <xenc:ReferenceList>
2390	           <xenc:DataReference URI="#ED"/>
2391	         </xenc:ReferenceList>
2392	       </pskc:DerivedKey>
2393	     </pskc:EncryptionKey>
2394	   <pskc:Device>
2395	     <pskc:DeviceId>
2396	       <pskc:Manufacturer>ACME</pskc:Manufacturer>
2397	       <pskc:SerialNo>0755225266</pskc:SerialNo>
2398	     </pskc:DeviceId>
2399	         <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2400	           KeyId="0755225266">
2401	             <pskc:Issuer>AnIssuer</pskc:Issuer>
2402	             <pskc:Usage OTP="true">
2403	                 <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
2404	             </pskc:Usage>
2405	             <pskc:Data Name="COUNTER">
2406	                 <pskc:PlainValue>AprkuA==</pskc:PlainValue>
2407	             </pskc:Data>
2408	             <pskc:Data Name="SECRET">
2409	                 <pskc:EncryptedValue Id="ED">
2410	                   <xenc:EncryptionMethod Algorithm=
2411	                   "http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
2412	                   <xenc:CipherData>
2413	                     <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
2414	                     </xenc:CipherValue>
2415	                   </xenc:CipherData>
2416	                 </pskc:EncryptedValue>

2418	             </pskc:Data>
2419	         </pskc:Key>
2420	   </pskc:Device>
2421	   <pskc:Signature>
2422	     <ds:SignedInfo>
2423	       <ds:CanonicalizationMethod
2424	         Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
2425	       <ds:SignatureMethod
2426	         Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
2427	       <ds:Reference URI="">
2428	         <ds:DigestMethod Algorithm=
2429	           "http://www.w3.org/2000/09/xmldsig#sha1"/>
2430	         <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
2431	       </ds:Reference>
2432	     </ds:SignedInfo>
2433	     <ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue>
2434	     <ds:KeyInfo>
2435	       <ds:X509Data>
2436	         <ds:X509IssuerSerial>
2437	           <ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US
2438	           </ds:X509IssuerName>
2439	           <ds:X509SerialNumber>12345678</ds:X509SerialNumber>
2440	         </ds:X509IssuerSerial>
2441	       </ds:X509Data>
2442	     </ds:KeyInfo>
2443	   </pskc:Signature>
2444	 </pskc:KeyContainer>

2446	12.5.  Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
2447	       Secret Key

2449	<?xml version="1.0" encoding="UTF-8"?>
2450	<pskc:KeyContainer Version="1.0"
2451	  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
2452	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
2453	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
2454	    <pskc:EncryptionKey>
2455	        <ds:X509Data>
2456	            <ds:X509Certificate>miib</ds:X509Certificate>
2457	        </ds:X509Data>
2458	    </pskc:EncryptionKey>
2459	    <pskc:Device>
2460	        <pskc:DeviceId>
2461	            <pskc:Manufacturer>ACME</pskc:Manufacturer>
2462	            <pskc:SerialNo>0755225266</pskc:SerialNo>
2463	        </pskc:DeviceId>
2464	        <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2465	                  KeyId="0755225266">
2466	            <pskc:Issuer>AnIssuer</pskc:Issuer>
2467	            <pskc:Usage OTP="true">
2468	                <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
2469	            </pskc:Usage>
2470	            <pskc:Data Name="COUNTER">
2471	                <pskc:PlainValue>AprkuA==</pskc:PlainValue>
2472	            </pskc:Data>
2473	            <pskc:Data Name="SECRET">
2474	              <pskc:EncryptedValue Id="ED">
2475	                <xenc:EncryptionMethod
2476	                  Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
2477	                <xenc:CipherData>
2478	                  <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
2479	                  </xenc:CipherValue>
2480	                </xenc:CipherData>
2481	              </pskc:EncryptedValue>
2482	            </pskc:Data>
2483	        </pskc:Key>
2484	    </pskc:Device>
2485	</pskc:KeyContainer>
2486	13.  References

2488	13.1.  Normative References

2490	   [PKCS1]    Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
2491	              Specifications Version 2.0.",
2492	              URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
2493	              October 1998.

2495	   [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
2496	              Standard", Version 2.0,
2497	              URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.

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

2503	   [RFC2434]  Narten, T., "Guidelines for Writing an IANA Considerations
2504	              Section in RFCs", RFC 2434, October 1998.

2506	   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
2507	              Types", RFC 3023, January 2001.

2509	   [RFC3553]  Mealling, M., "An IETF URN Sub-namespace for Registered
2510	              Protocol Parameters", RFC 3553, June 2003.

2512	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2513	              January 2004.

2515	   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
2516	              Registration Procedures", BCP 13, RFC 4288, December 2005.

2518	   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol
2519	              (LDAP): String Representation of Distinguished Names",
2520	              RFC 4514, June 2006.

2522	   [XMLDSIG]  Eastlake, D., "XML-Signature Syntax and Processing",
2523	              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
2524	              W3C Recommendation, February 2002.

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

2529	13.2.  Informative References

2531	   [CAP]      MasterCard International, "Chip Authentication Program
2532	              Functional Architecture", September 2004.

2534	   [DSKPP]    Doherty, A., Pei, M., Machani, S., and M. Nystrom,
2535	              "Dynamic Symmetric Key Provisioning Protocol", Internet
2536	              Draft Informational, URL: http://www.ietf.org/
2537	              internet-drafts/draft-ietf-keyprov-dskpp-03.txt,
2538	              February 2008.

2540	   [HOTP]     MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
2541	              O. Ranen, "HOTP: An HMAC-Based One Time Password
2542	              Algorithm", RFC 4226,
2543	              URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
2544	              December 2005.

2546	   [NIST-SP800-57]
2547	              National Institute of Standards and Technology,
2548	              "Recommendation for Key Management - Part I: General
2549	              (Revised)", NIST 800-57, URL: http://csrc.nist.gov/
2550	              publications/nistpubs/800-57/
2551	              sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007.

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

2556	   [OCRA]     MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.
2557	              Bajaj, "OCRA: OATH Challenge Response Algorithm", Internet
2558	              Draft Informational, URL: http://www.ietf.org/
2559	              internet-drafts/
2560	              draft-mraihi-mutual-oath-hotp-variants-06.txt,
2561	              December 2007.

2563	   [PKCS12]   RSA Laboratories, "PKCS #12: Personal Information Exchange
2564	              Syntax Standard", Version 1.0,
2565	              URL: http://www.rsasecurity.com/rsalabs/pkcs/.

2567	   [Schneier]
2568	              Schneier, B., "Secrets and Lies: Digitial Security in a
2569	              Networked World",  Wiley Computer Publishing, ISBN 0-8493-
2570	              8253-7, 2000.

2572	Authors' Addresses

2574	   Philip Hoyer
2575	   ActivIdentity, Inc.
2576	   109 Borough High Street
2577	   London, SE1  1NL
2578	   UK

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

2583	   Mingliang Pei
2584	   VeriSign, Inc.
2585	   487 E. Middlefield Road
2586	   Mountain View, CA  94043
2587	   USA

2589	   Phone: +1 650 426 5173
2590	   Email: mpei@verisign.com

2592	   Salah Machani
2593	   Diversinet, Inc.
2594	   2225 Sheppard Avenue East
2595	   Suite 1801
2596	   Toronto, Ontario  M2J 5C2
2597	   Canada

2599	   Phone: +1 416 756 2324 Ext. 321
2600	   Email: smachani@diversinet.com

2602	Full Copyright Statement

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

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

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

2618	Intellectual Property

2620	   The IETF takes no position regarding the validity or scope of any
2621	   Intellectual Property Rights or other rights that might be claimed to
2622	   pertain to the implementation or use of the technology described in
2623	   this document or the extent to which any license under such rights
2624	   might or might not be available; nor does it represent that it has
2625	   made any independent effort to identify any such rights.  Information
2626	   on the procedures with respect to rights in RFC documents can be
2627	   found in BCP 78 and BCP 79.

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

2636	   The IETF invites any interested party to bring to its attention any
2637	   copyrights, patents or patent applications, or other proprietary
2638	   rights that may cover technology that may be required to implement
2639	   this standard.  Please address the information to the IETF at
2640	   ietf-ipr@ietf.org.

2642	Acknowledgment

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