idnits 2.17.1 

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

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

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

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


  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 2604 has weird spacing: '...inition  http:...'

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

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

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

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

  == 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.  MUST be expressed in UTC
     form, with no time zone component.  Implementations SHOULD NOT rely on
     time resolution finer than milliseconds and MUST NOT generate time
     instants that specify leap seconds.

  == 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.  MUST be expressed in UTC
     form, with no time zone component.  Implementations SHOULD NOT rely on
     time resolution finer than milliseconds and MUST NOT generate time
     instants that specify leap seconds.

  == 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  <MaxFailedAttempts> (OPTIONAL), the maximum number of times the
     PIN can be entered wrongly before it MUST not be possible to use the key
     anymore.  If PinUsageMode is 'Local' the device MUST enforce this value,
     otherwise it MUST be enforced by the validation server.

  == 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  <MinLength> (OPTIONAL), the minimum lenght of a PIN that can be
     set to protect this key.  It MUST not be possible to set a PIN shorter
     than this value.  If the Format element is 'DECIMAL', 'HEXADECIMAL' or
     'ALPHANUMERIC' this value indicates the number of digits/characters.  If
     the Format attribute is 'BASE64' or 'BINARY', this value indicates the
     number of bytes of the unencoded value.  If PinUsageMode is 'Local' the
     device MUST enforce this value, otherwise it MUST be enforced by the
     validation server.

  == 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  <MaxLength> (OPTIONAL), the maximum lenght of a PIN that can be
     set to protect this key.  It MUST not be possible to set a PIN longer
     than this value.  If the Format element is 'DECIMAL', 'HEXADECIMAL' or
     'ALPHANUMERIC' this value indicates the number of digits/characters.  If
     the Format attribute is 'BASE64' or 'BINARY', this value indicates the
     number of bytes of the unencoded value.  If PinUsageMode is 'Local' the
     device MUST enforce this value, otherwise it MUST be enforced by the
     validation server.

  -- 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 (November 03, 2008) is 5652 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 3680, but no explicit
     reference was found in the text

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

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

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

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

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

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

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

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

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

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

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

  -- Obsolete informational reference (is this intentional?): RFC 4051 (ref.
     'AlgorithmURIs') (Obsoleted by RFC 6931)

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


     Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 12 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: May 7, 2009                                            VeriSign
6	                                                              S. Machani
7	                                                              Diversinet
8	                                                       November 03, 2008

10	                    Portable Symmetric Key Container
11	       draft-ietf-keyprov-portable-symmetric-key-container-06.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 May 7, 2009.

38	Abstract

40	   This document specifies a symmetric key format for transport and
41	   provisioning of symmetric keys (for example One Time Password (OTP)
42	   shared secrets or symmetric cryptographic keys) to different types of
43	   crypto modules such as a strong authentication device.  The standard
44	   key transport format enables enterprises to deploy best-of-breed
45	   solutions combining components from different vendors into the same
46	   infrastructure.

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

55	Table of Contents

57	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
58	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
59	     2.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  6
60	     2.2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
61	   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
62	     3.1.  Online Use Cases . . . . . . . . . . . . . . . . . . . . .  8
63	       3.1.1.  Transport of keys from Server to Cryptographic
64	               Module . . . . . . . . . . . . . . . . . . . . . . . .  8
65	       3.1.2.  Transport of keys from Cryptographic Module to
66	               Cryptographic Module . . . . . . . . . . . . . . . . .  8
67	       3.1.3.  Transport of keys from Cryptographic Module to
68	               Server . . . . . . . . . . . . . . . . . . . . . . . .  9
69	       3.1.4.  Server to server Bulk import/export of keys  . . . . .  9
70	     3.2.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . .  9
71	       3.2.1.  Server to server Bulk import/export of keys  . . . . .  9
72	   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
73	   5.  Portable Key container definition  . . . . . . . . . . . . . . 13
74	     5.1.  KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 14
75	     5.2.  KeyProperties  . . . . . . . . . . . . . . . . . . . . . . 15
76	     5.3.  Device . . . . . . . . . . . . . . . . . . . . . . . . . . 17
77	       5.3.1.  DeviceInfo . . . . . . . . . . . . . . . . . . . . . . 18
78	     5.4.  Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
79	       5.4.1.  KeyData  . . . . . . . . . . . . . . . . . . . . . . . 23
80	       5.4.2.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 25
81	       5.4.3.  ValueFormat  . . . . . . . . . . . . . . . . . . . . . 29
82	       5.4.4.  PINPolicy  . . . . . . . . . . . . . . . . . . . . . . 29
83	   6.  Usage and profile of algorithms for the portable symmetric
84	       key container  . . . . . . . . . . . . . . . . . . . . . . . . 33
85	     6.1.  Usage of EncryptionKey to protect keys in transit  . . . . 33
86	       6.1.1.  Protecting keys using a pre-shared key via
87	               symmetric algorithms . . . . . . . . . . . . . . . . . 33
88	       6.1.2.  Protecting keys using passphrase based key
89	               encryption keys  . . . . . . . . . . . . . . . . . . . 35
90	     6.2.  Protecting keys using asymmetric algorithms  . . . . . . . 38
91	     6.3.  Profile of Key Algorithm . . . . . . . . . . . . . . . . . 39
92	       6.3.1.  OTP Key Algorithm Identifiers  . . . . . . . . . . . . 40
93	       6.3.2.  PIN key value compare algorithm identifier . . . . . . 40
94	   7.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 41
95	   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
96	     8.1.  Content-type registration for 'application/pskc+xml' . . . 48
97	     8.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 49
98	     8.3.  URN Sub-Namespace Registration for
99	           urn:ietf:params:xml:ns:keyprov:pskc:1.0  . . . . . . . . . 49
100	     8.4.  Symmetric Key Algorithm Identifier Registry  . . . . . . . 50
101	       8.4.1.  Applicability  . . . . . . . . . . . . . . . . . . . . 50
102	       8.4.2.  Registerable Algorithms  . . . . . . . . . . . . . . . 51
103	       8.4.3.  Registration Procedures  . . . . . . . . . . . . . . . 52
104	       8.4.4.  Initial Values . . . . . . . . . . . . . . . . . . . . 54
105	   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 76
106	     9.1.  Payload confidentiality  . . . . . . . . . . . . . . . . . 76
107	     9.2.  Payload integrity  . . . . . . . . . . . . . . . . . . . . 77
108	     9.3.  Payload authenticity . . . . . . . . . . . . . . . . . . . 77
109	   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
110	   11. Appendix A - Example Symmetric Key Containers  . . . . . . . . 79
111	     11.1. Symmetric Key Container with a single Non-Encrypted
112	           HOTP Secret Key  . . . . . . . . . . . . . . . . . . . . . 79
113	     11.2. Symmetric Key Container with a single PIN protected
114	           Non-Encrypted HOTP Secret Key  . . . . . . . . . . . . . . 80
115	     11.3. Symmetric Key Container with a single AES-128-CBC
116	           Encrypted HOTP Secret Key and non-encrypted counter
117	           value  . . . . . . . . . . . . . . . . . . . . . . . . . . 82
118	     11.4. Symmetric Key Container with signature and a single
119	           Password-based Encrypted HOTP Secret Key . . . . . . . . . 83
120	     11.5. Symmetric Key Container with a single RSA 1.5
121	           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 85
122	     11.6. Symmetric Key Container with a single AES-128-CBC
123	           Encrypted OCRA Secret Key and non-encrypted counter
124	           value  . . . . . . . . . . . . . . . . . . . . . . . . . . 86
125	     11.7. Symmetric Key Container with a single AES-256-CBC
126	           Encrypted TOTP Secret Key and non-encrypted time values  . 88
127	     11.8. Symmetric Key Container with two devices containing a
128	           Non-Encrypted HOTP Secret Key each sharing common
129	           KeyProperties  . . . . . . . . . . . . . . . . . . . . . . 90
130	   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
131	     12.1. Normative References . . . . . . . . . . . . . . . . . . . 92
132	     12.2. Informative References . . . . . . . . . . . . . . . . . . 93
133	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
134	   Intellectual Property and Copyright Statements . . . . . . . . . . 95

136	1.  Introduction

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

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

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

162	   To provide an analogy, in public key environments the PKCS#12 format
163	   [PKCS12] is commonly used for importing and exporting private keys
164	   and certificates between systems.  In the environments outlined in
165	   this document where OTP keys may be transported directly down to
166	   smartcards or devices with limited computing capabilities and
167	   explicit shared secret, configuration attribute information is
168	   desirable.  With PKCS#12, one would have to use opaque data to carry
169	   shared secret attributes used for OTP calculations, whereas a more
170	   explicit attribute schema definition is better for interoperability
171	   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	   DeviceInfo:  A set of elements whose values combined uniquely
209	      identify a device e.g.  Manufacturer 'TokenVendorAcme' and
210	      Serialnumber '12345678'

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

215	   Key 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 Cryptographic Module

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

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

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

285	3.1.2.  Transport of keys from Cryptographic Module to Cryptographic
286	        Module

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

295	3.1.3.  Transport of keys from Cryptographic Module to Server

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

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

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

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

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

323	3.2.  Offline Use Cases

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

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

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

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

353	4.  Requirements

355	   This section outlines the most relevant requirements that are the
356	   basis of this work.  Several of the requirements were derived from
357	   use cases described above.

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

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

367	         *  Unique Key Identifier

369	         *  Issuer information

371	         *  Algorithm ID

373	         *  Algorithm mode

375	         *  Issuer Name

377	         *  Key friendly name

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

381	         *  Time value

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

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

390	   R5:   The format SHOULD allow bulk representation of PINs related to
391	         specific keys

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

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

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

402	   R9:   The format SHOULD be extensible.  It SHOULD enable extension
403	         points allowing vendors to specify additional attributes in the
404	         future.

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

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

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

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

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

432	5.  Portable Key container definition

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

437	   1.  KeyContainer entity as defined in Section 5.1

439	   2.  KeyProperties entity as defined in Section 5.2

441	   3.  Device entity as defined in Section 5.3

443	   4.  Key entity as defined in Section 5.4

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

448	   A KeyContainer MAY contain one or more Device entities.  A Device MAY
449	   contain one or more Key entities

451	   The figure below indicates a possible relationship diagram of a
452	   container.

454	   --------------------------------------------
455	   | KeyContainer                             |
456	   |                                          |
457	   |  --------------------                    |
458	   |  |  Keyproperties 1 |                    |
459	   |  |                  |                    |
460	   |  --------------------                    |
461	   |  ------------------   -----------------  |
462	   |  | Device 1       |   | Device n      |  |
463	   |  |                |   |               |  |
464	   |  |  ------------  |   | ------------  |  |
465	   |  |  | Key 1    |  |   | | Key n    |  |  |
466	   |  |  ------------  |   | ------------  |  |
467	   |  |                |   |               |  |
468	   |  |                |   |               |  |
469	   |  |  ------------  |   | ------------  |  |
470	   |  |  | Key m    |  |   | | Key p    |  |  |
471	   |  |  ------------  |   | ------------  |  |
472	   |  ------------------   -----------------  |
473	   |                                          |
474	   --------------------------------------------

476	   The following sections describe in detail all the entities and
477	   related XML schema elements and attributes:

479	5.1.  KeyContainer

481	   The KeyContainer represents the key container entity.  A Container
482	   MAY contain more than one Device entity; each Device entity MAY
483	   contain more than one Key entity.

485	   The KeyContainer is defined as follows:

487	   <xs:complexType name="KeyContainerType">
488	           <xs:sequence>
489	                   <xs:element name="EncryptionKey"
490	                   type="ds:KeyInfoType" minOccurs="0"/>
491	                   <xs:element name="MACAlgorithm"
492	                   type="pskc:KeyAlgorithmType" minOccurs="0"/>
493	                   <xs:element name="KeyProperties"
494	                   type="pskc:KeyPropertiesType" minOccurs="0"
495	                   maxOccurs="unbounded"/>
496	                   <xs:element name="Device"
497	                   type="pskc:DeviceType" minOccurs="1"
498	                   maxOccurs="unbounded"/>
499	                   <xs:element name="Signature"
500	                   type="ds:SignatureType" minOccurs="0"/>
501	          <xs:element name="Extensions"
502	          type="pskc:ExtensionsType" minOccurs="0"
503	          maxOccurs="unbounded"/>
504	           </xs:sequence>
505	           <xs:attribute name="Version" type="pskc:VersionType"
506	           use="required"/>
507	           <xs:attribute ref="xml:id" use="optional"/>
508	   </xs:complexType>

510	   The attributes of the KeyContainer have the following meanings:

512	   o  Version (MANDATORY), the version number for the portable key
513	      container format (the XML schema defined in this document).

515	   o  ID (OPTIONAL), the unique ID for this container in case an XML
516	      document contains more than one container and wants to refer to
517	      them uniquely.

519	   The elements of the KeyContainer have the following meanings:

521	   o  <EncryptionKey> (OPTIONAL), Identifies the key encryption key,
522	      algorithm and possible parameters used to protect the Secret Key
523	      data in the container.  Please see Section 6.1 for detailed
524	      description of how to protect key data in transit and the usage of
525	      this element.

527	   o  <MACAlgorithm> (OPTIONAL), Identifies the algorithm used to
528	      generate a Message Authentication Code (MAC) of the Secret Key
529	      data values when protection algorithms are used that do not have
530	      integrity checks.  The digest guarantees the integrity and the
531	      authenticity of the key data. for profile and usage please see
532	      Section 6.1.1

534	   o  <KeyProperties> (OPTIONAL), key property entities containing key
535	      related properties that are common for keys within this container.
536	      Please see Section 5.2 for detailed description of this
537	      element.The KeyContainer MAY contain multiple KeyProperties
538	      elements each containing a set of properties related to one or
539	      more keys transported within the container.

541	   o  <Device> (MANDATORY), the host Device for one or more Keys as
542	      defined in Section 5.3 The KeyContainer MAY contain multiple
543	      Device data elements, allowing for bulk provisioning of multiple
544	      devices each containing multiple keys.

546	   o  <Signature> (OPTIONAL), the signature value of the Container.
547	      When the signature is applied to the entire container, it MUST use
548	      XML Signature methods as defined in [XMLDSIG].  It MAY be omitted
549	      when application layer provisioning or transport layer
550	      provisioning protocols provide the integrity and authenticity of
551	      the payload between the sender and the recipient of the container.
552	      When required, this specification recommends using a symmetric key
553	      based signature with the same key used in the encryption of the
554	      secret key data.  The signature is enveloped.

556	   o  <Extensions> (OPTIONAL), is the extension point for this entity.
557	      All extensions are grouped under this element and will be of type
558	      pskc:ExtensionType, which contains an optional attribute
559	      'definition' that can have a URI pointing at the defintion of the
560	      extension.  In this way groups of extension can be bundled under a
561	      subelement.  For example:

563	 <Extensions>
564	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
565	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
566	   </YourExtension99>
567	 </Extensions>

569	5.2.  KeyProperties

571	   The KeyProperties represents common properties shared by more than
572	   one key held in the container.  If a value is set in the properties
573	   the Key element can refer to it via ID attribute.  Values that are
574	   present in the Key element itself MUST take precedence over values
575	   set in KeyProperties.  The KeyProperties is defined as follows:

577	   <xs:complexType name="KeyPropertiesType">
578	           <xs:sequence>
579	                   <xs:element name="Issuer" type="xs:string"
580	                   minOccurs="0"/>
581	                   <xs:element name="Usage" type="pskc:UsageType"
582	                   minOccurs="0"/>
583	                   <xs:element name="KeyProfileId" type="xs:string"
584	                   minOccurs="0"/>
585	                   <xs:element name="MasterKeyId" type="xs:string"
586	                   minOccurs="0"/>
587	                   <xs:element name="Data" type="pskc:KeyDataType"
588	                   minOccurs="0" maxOccurs="1"/>
589	                   <xs:element name="PINPolicy"
590	                   type="pskc:PINPolicyType" minOccurs="0"/>
591	                   <xs:element name="StartDate" type="xs:dateTime"
592	                   minOccurs="0"/>
593	                   <xs:element name="ExpiryDate"
594	                   type="xs:dateTime" minOccurs="0"/>
595	          <xs:element name="Extensions"
596	          type="pskc:ExtensionsType" minOccurs="0"
597	          maxOccurs="unbounded"/>
598	           </xs:sequence>
599	           <xs:attribute ref="xml:id" use="required"/>
600	           <xs:attribute name="KeyAlgorithm"
601	           type="pskc:KeyAlgorithmType" use="required"/>
602	   </xs:complexType>

604	   The attributes of the KeyProperties entity have the following
605	   meanings:

607	   o  ID (MANDATORY), a unique and global identifier of set of
608	      KeyProperties.  The identifier is defined as a string of
609	      alphanumeric characters.

611	   o  KeyAlgorithm (MANDATORY), the unique URI of the type of algorithm
612	      to use with a secret key for the profiles described in Section 6.3

614	   Since KeyProperties are a method to group element values that are
615	   common to multiple keys transported, please refer to Section 5.4 for
616	   detailed description of all elements.

618	5.3.  Device

620	   The Device represents an extensible Device entity in the Container.
621	   A Device MAY be bound to a user and MAY contain more than one key.  A
622	   key SHOULD be bound to only one Device.

624	   The Device is defined as follows:

626	   <xs:complexType name="DeviceType">
627	     <xs:sequence>
628	       <xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
629	       minOccurs="0"/>
630	       <xs:element name="Key" type="pskc:KeyType"
631	       maxOccurs="unbounded"/>
632	       <xs:element name="User" type="xs:string" minOccurs="0"/>
633	       <xs:element name="Extensions"
634	       type="pskc:ExtensionsType" minOccurs="0"
635	       maxOccurs="unbounded"/>
636	     </xs:sequence>
637	   </xs:complexType>

639	   The elements of the Device have the following meanings:

641	   o  <DeviceInfo> (OPTIONAL), a set of elements containing information
642	      about the device, whose values uniquely identify the device,
643	      defined in Section 5.3.1

645	   o  <Key> (MANDATORY), represents the key entity as defined in
646	      Section 5.4

648	   o  <User> (OPTIONAL), identifies the owner or the user of the Device,
649	      a string representation of a Distinguished Name as defined in
650	      [RFC4514].  For example UID=jsmith,DC=example,DC=net.  In systems
651	      where unique user Ids are used the string representation
652	      'UID=[uniqueId]' SHOULD be used.

654	   o  <Extensions> (OPTIONAL), is the extension point for this entity.
655	      All extensions are grouped under this element and will be of type
656	      pskc:ExtensionType, which contains an optional attribute
657	      'defintion' that can have a URI pointing at the defintion of the
658	      extension.  In this way groups of extension can be bundled under a
659	      subelement.  For example:

661	 <Extensions>
662	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
663	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
664	   </YourExtension99>
665	 </Extensions>

667	5.3.1.  DeviceInfo

669	   The DeviceInfo represents an extensible set of elements that form the
670	   identifying criteria to uniquely identify the device that contains
671	   the associated keys.  Since devices can come in different form
672	   factors such as hardware tokens, smart-cards, soft tokens in a mobile
673	   phone or PC etc this element allows different criteria to be used.
674	   Combined though the criteria MUST uniquely identify the device.  For
675	   example for hardware tokens the combination of SerialNo and
676	   Manufacturer will uniquely identify a device but not SerialNo alone
677	   since two different token manufacturers might issue devices with the
678	   same serial number (similar to the IssuerDN and serial number of a
679	   certificate).  Symmetric Keys used in the payment industry are
680	   usually stored on Integrated Circuit Smart Cards.  These cards are
681	   uniquely identified via the Primary Account Number (PAN, the long
682	   number printed on the front of the card) and an expiry date of the
683	   card.  DeviceInfo is an extensible type that allows all these
684	   different ways to uniquely identify a specific key containing device.

686	   The DeviceInfo is defined as follows:

688	   <xs:complexType name="DeviceInfoType">
689	   <xs:sequence>
690	       <xs:element name="Manufacturer" type="xs:string"/>
691	       <xs:element name="SerialNo" type="xs:string"/>
692	       <xs:element name="Model" type="xs:string" minOccurs="0"/>
693	       <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
694	       <xs:element name="DeviceBinding" type="xs:string" minOccurs="0"/>
695	       <xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
696	       <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
697	       <xs:element name="Extensions"
698	       type="pskc:ExtensionsType" minOccurs="0"
699	       maxOccurs="unbounded"/>
700	   </xs:sequence>
701	   </xs:complexType>

703	   The elements of DeviceInfo have the following meanings:

705	   o  <Manufacturer> (MANDATORY), the manufacturer of the device.

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

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

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

716	   o  <DeviceBinding> (OPTIONAL), the identifier that can be used to
717	      bind keys to the device or class of device.  When loading keys
718	      into a device, this identifier can be checked against information
719	      obtained from the device to ensure that the correct device or
720	      class of device is being used.

722	   o  <StartDate> (OPTIONAL), the start date of a device (such as the
723	      one on a payment card, used when issue numbers are not printed on
724	      cards).  MUST be expressed in UTC form, with no time zone
725	      component.  Implementations SHOULD NOT rely on time resolution
726	      finer than milliseconds and MUST NOT generate time instants that
727	      specify leap seconds.

729	   o  <ExpiryDate> (OPTIONAL), the expiry date of a device (such as the
730	      one on a payment card, used when issue numbers are not printed on
731	      cards).  MUST be expressed in UTC form, with no time zone
732	      component.  Implementations SHOULD NOT rely on time resolution
733	      finer than milliseconds and MUST NOT generate time instants that
734	      specify leap seconds.

736	   o  <Extensions> (OPTIONAL), is the extension point for this entity.
737	      All extensions are grouped under this element and will be of type
738	      pskc:ExtensionType, which contains an optional attribute
739	      'defintion' that can have a URI pointing at the defintion of the
740	      extension.  In this way groups of extension can be bundled under a
741	      subelement.  For example:

743	 <Extensions>
744	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
745	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
746	   </YourExtension99>
747	 </Extensions>

749	5.4.  Key

751	   The Key represents the key entity in the KeyContainer.  The Key is
752	   defined as follows:

754	   <xs:complexType name="KeyType">
755	           <xs:sequence>
756	                   <xs:element name="Issuer" type="xs:string"
757	                   minOccurs="0"/>
758	                   <xs:element name="Usage" type="pskc:UsageType"
759	                   minOccurs="0"/>
760	                   <xs:element name="KeyProfileId" type="xs:string"
761	                   minOccurs="0"/>
762	                   <xs:element name="MasterKeyId" type="xs:string"
763	                   minOccurs="0"/>
764	                   <xs:element name="FriendlyName" type="xs:string"
765	                   minOccurs="0"/>
766	                   <xs:element name="Data" type="pskc:KeyDataType"
767	                   minOccurs="0" maxOccurs="1"/>
768	                   <xs:element name="PINPolicy"
769	                   type="pskc:PINPolicyType" minOccurs="0"/>
770	                   <xs:element name="StartDate" type="xs:dateTime"
771	                   minOccurs="0"/>
772	                   <xs:element name="ExpiryDate" type="xs:dateTime"
773	                   minOccurs="0"/>
774	                   <xs:element name="UserId" type="xs:string"
775	                   minOccurs="0"/>
776	           <xs:element name="Extensions"
777	           type="pskc:ExtensionsType" minOccurs="0"
778	           maxOccurs="unbounded"/>
779	           </xs:sequence>
780	           <xs:attribute name="KeyId" type="xs:string"
781	           use="required"/>
782	           <xs:attribute name="KeyAlgorithm"
783	           type="pskc:KeyAlgorithmType" use="optional"/>
784	           <xs:attribute name="KeyProperties" type="xs:IDREF"
785	           use="optional"/>
786	   </xs:complexType>

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

790	   o  KeyId (MANDATORY), a unique and global identifier of the symmetric
791	      key.  The identifier is defined as a string of alphanumeric
792	      characters.  This identifier SHOULD be valid globally and outside
793	      of the instance document of the container.

795	   o  KeyAlgorithm (MANDATORY), the unique URI of the type of algorithm
796	      to use with the secret key, for profiles are described in
797	      Section 6.3

799	   o  KeyProperties (OPTIONAL), the references to the unique id of the
800	      KeyProperties whose value the instance of this key inherits.  If
801	      this value is set implementation MUST lookup the Keyproperties
802	      element referred to by this unique Id and this instance of key
803	      will inherit all values from the KeyProperties.  Values held in
804	      the key instance MUST take precedence over values inherited from
805	      KeyProperties."/>

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

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

815	   o  <Usage> (OPTIONAL), defines the intended usage of the key and
816	      related metadata as defined in Section 5.4.2

818	   o  <KeyProfileId> (OPTIONAL), A unique identifier used between the
819	      sending and receiving party of the container to establish a set of
820	      key attribute values, common to one or more keys, that are not
821	      transmitted witin the container but agreed between sending and
822	      receiving party of the container out of band.  This Id will then
823	      represent the unique reference to a a set of attribute values.
824	      For example a smart card application personalisation profile id
825	      related to attributes present on a smart card application that
826	      have influence when computing a response.  An example would be
827	      that a sending and receiving party agree on a set of values
828	      related to the EMV MasterCard CAP [CAP] algorithm that application
829	      on a card personalised with data for a specific batch of cards
830	      such as:

832	         IAF Internet authentication flag

834	         CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
835	         VISA 13, VISA14)

837	         AIP (Application Interchange Profile), 2 bytes

839	         CVR The card verification result

841	         IIPB

843	      So sending and reciving party would agree thet KeyProfileId '1'
844	      would represent a cetain set of values (e.g.  IAF="80").  When
845	      sending keys these values would not be transmitted as key
846	      attributes but only referred to via the KeyProfileId element set
847	      to the specific agreed profile (in this case '1').  WHen the
848	      receiving party receives the keys it can then associate all
849	      relevant key attributes contained in the out of band agreed
850	      profile with the imported keys.  Often this methodology is used
851	      between between the manufacturing and the validation service to
852	      avoid transmission of mainly the same set of values.  The
853	      KeyProfileId is defined as a String.

855	   o  <MasterKeyId> (OPTIONAL), The unique reference to an external
856	      master key when key derivation schemes are used and no specific
857	      key is transported but only the reference to the master key used
858	      to derive a specific key and some derivation data (e.g. the
859	      PKCS#11 key label in an HSM).

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

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

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

871	   o  <StartDate> (OPTIONAL), the start date of the key, it MUST not be
872	      possible to use this key before this date.  MUST be expressed in
873	      UTC form, with no time zone component.  Implementations SHOULD NOT
874	      rely on time resolution finer than milliseconds and MUST NOT
875	      generate time instants that specify leap seconds.

877	   o  <ExpiryDate> (OPTIONAL), the expiry date of the key, it MUST not
878	      be possible to use this key after this date.  MUST be expressed in
879	      UTC form, with no time zone component.  Implementations SHOULD NOT
880	      rely on time resolution finer than milliseconds and MUST NOT
881	      generate time instants that specify leap seconds.

883	   o  <UserId> (OPTIONAL), identifies the user account (e.g. username or
884	      user id) to which the key is assigned.  The value MUST be a string
885	      representation of a Distinguished Name as defined in [RFC4514].
886	      For example "UID=jsmith,DC=example,DC=net".  In systems where
887	      unique user Ids are used the string representation
888	      'UID=[uniqueId]' SHOULD be used.

890	   o  <Extensions> (OPTIONAL), is the extension point for this entity.
891	      All extensions are grouped under this element and will be of type
892	      pskc:ExtensionType, which contains an optional attribute
893	      'defintion' that can have a URI pointing at the defintion of the
894	      extension.  In this way groups of extension can be bundled under a
895	      subelement.  For example:

897	 <Extensions>
898	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
899	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
900	   </YourExtension99>
901	 </Extensions>

903	5.4.1.  KeyData

905	   Defines an extensible set of data elements relating to a key
906	   including the key value itself (secret).  After considerable
907	   discussions in forums and at IETF the authors needed a mean to convey
908	   data related to a key in an extensible form.  A name-value pair
909	   approach would be extensible for future new data fields but it lacks
910	   support of typing.  Hence the current apporach is to have within
911	   KeyData a set of elements that have both typing and can be encrypted.

913	   Regarding to the encryption, the requirements were that the data
914	   elements could be simply encrypted.  The XML encryption is adopted in
915	   consideration of open standards and broad existing implementations.
916	   In this document, a simplified profile of XML encryption is used that
917	   only encrypts data value rather than XML elements. xenc:
918	   EncryptedDataType is leveraged to carry encrypted data.  This
919	   simplified usage doesn't need to involve any XML canonicalization
920	   among others.

922	   All elements within <Data> hence obey a simple structure in that they
923	   MUST have:

925	   a choice between:

927	      A <PlainValue> element that is typed to the specific type (e.g.
928	      xs:integer)

930	      An <EncryptedValue> element that is of type xenc:EncryptedDataType
931	      where the value of the specific element is placed in case it is
932	      encrypted

934	   an optional <ValueMac> element that is populated with a MAC generated
935	   from the unencrypted value in case the encryption algorithm does not
936	   support integrity checks

938	   For example the pskc:intDataType is defined as follows:

940	   <xs:complexType name="intDataType">
941	           <xs:sequence>
942	                   <xs:choice>
943	                           <xs:element name="PlainValue"
944	                           type="xs:int"/>
945	                           <xs:element name="EncryptedValue"
946	                           type="xenc:EncryptedDataType"/>
947	                   </xs:choice>
948	                   <xs:element name="ValueMAC"
949	                   type="xs:base64Binary" minOccurs="0"/>
950	           </xs:sequence>
951	   </xs:complexType>

953	   The following typed base types have been defined within the current
954	   schema of the PSKC spec with the naming convention <type>DataType
955	   (e.g. intDataType) to be able to cater transmission of key data
956	   elements:

958	      pskc:intDataType - to carry data elements of type integer,
959	      PlainValue sub element is of type xs:integer.  When encrypted the
960	      binary value MUST be 4 bytes unsigned integer in big endian (i.e.
961	      network byte order) form

963	      pskc:longDataType - to carry data elements of type long,
964	      PlainValue sub element is of type xs:long.  When encrypted the
965	      binary value MUST be 8 bytes unsigned integer in big endian (i.e.
966	      network byte order) form

968	      pskc:binaryDataType - to carry data elements of type binary,
969	      PlainValue sub element is of type xs:Base64Binary

971	      pskc:stringDataType - to carry data elements of type string,
972	      PlainValue sub element is of type xs:string.  When encrypted the
973	      binary value MUST UTF-8 encoded string in binary form

975	   Therefore the KeyData element is defined as follows and contains sub
976	   elements to convey the values required by algorithms considered
977	   during the definition of this specification:

979	   <xs:complexType name="KeyDataType">
980	     <xs:sequence>
981	       <xs:element name="Secret" type="pskc:binaryDataType"
982	       minOccurs="0" maxOccurs="1"/>
983	       <xs:element name="Counter" type="pskc:longDataType"
984	       minOccurs="0" maxOccurs="1"/>
985	       <xs:element name="Time" type="pskc:intDataType"
986	       minOccurs="0" maxOccurs="1"/>
987	       <xs:element name="TimeInterval" type="pskc:intDataType"
988	       minOccurs="0" maxOccurs="1"/>
989	       <xs:element name="TimeDrift" type="pskc:intDataType"
990	       minOccurs="0" maxOccurs="1"/>
991	       <xs:any namespace="##other" minOccurs="0"
992	       maxOccurs="unbounded"/>
993	     </xs:sequence>
994	   </xs:complexType>

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

998	   o  <Secret> (OPTIONAL), the value of the key itself in binary.

1000	   o  <Counter> (OPTIONAL), the event counter for event based OTP
1001	      algorithms.

1003	   o  <Time> (OPTIONAL), the time for time based OTP algorithms.  (If
1004	      time interval is used, this element carries the number of time
1005	      intervals passed from a specific start point, normally algorithm
1006	      dependent)

1008	   o  <TimeInterval> (OPTIONAL), the time interval value for time based
1009	      OTP algorithms.

1011	   o  <TimeDrift> (OPTIONAL), the device clock drift value for time
1012	      based OTP algorithms.  The value indicates number of seconds that
1013	      the device clock may drift each day.

1015	   o  <xs:any ..> the extension point for carrying future elements.
1016	      Please note that all elements added MUST carry PlainValue and
1017	      EncryptedValue sub eleemnts as described above.

1019	5.4.2.  Usage

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

1024	   <xs:complexType name="UsageType">
1025	           <xs:sequence>
1026	                   <xs:element name="ChallengeFormat" minOccurs="0">
1027	                           <xs:complexType>
1028	                             <xs:attribute name="Format"
1029	                             type="pskc:ValueFormatType"
1030	                             use="required"/>
1031	                             <xs:attribute name="Min"
1032	                             type="xs:unsignedInt" use="required"/>
1033	                             <xs:attribute name="Max"
1034	                             type="xs:unsignedInt" use="required"/>
1035	                             <xs:attribute name="CheckDigits"
1036	                             type="xs:boolean" default="false"/>
1037	                           </xs:complexType>
1038	                   </xs:element>
1039	                   <xs:element name="ResponseFormat">
1040	                           <xs:complexType>
1041	                             <xs:attribute name="Format"
1042	                             type="pskc:ValueFormatType"
1043	                             use="required"/>
1044	                             <xs:attribute name="Length"
1045	                             type="xs:unsignedInt" use="required"/>
1046	                             <xs:attribute name="CheckDigits"
1047	                             type="xs:boolean" default="false"/>
1048	                           </xs:complexType>
1049	                   </xs:element>
1050	           <xs:element name="Extensions"
1051	           type="pskc:ExtensionsType" minOccurs="0"
1052	           maxOccurs="unbounded"/>
1053	           </xs:sequence>
1054	           <xs:attribute name="OTP" type="xs:boolean"
1055	           default="false"/>
1056	           <xs:attribute name="CR" type="xs:boolean"
1057	           default="false"/>
1058	           <xs:attribute name="Integrity" type="xs:boolean"
1059	           default="false"/>
1060	           <xs:attribute name="Encrypt" type="xs:boolean"
1061	           default="false"/>
1062	           <xs:attribute name="Unlock" type="xs:boolean"
1063	           default="false"/>
1064	           <xs:anyAttribute namespace="##other"/>
1065	   </xs:complexType>

1067	   The attributes of the Usage element define the intended usage of the
1068	   key.  This list of attributes is extensible for future needs.  They
1069	   are a combination of one or more of the following (set to true):

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

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

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

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

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

1084	   The <Extensions> (OPTIONAL) element, is the extension point for the
1085	   Usage entity.  All extensions are grouped under this element and will
1086	   be of type pskc:ExtensionType, which contains an optional attribute
1087	   'defintion' that can have a URI pointing at the defintion of the
1088	   extension.  In this way groups of extension can be bundled under a
1089	   subelement.  For example:

1091	 <Extensions>
1092	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
1093	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
1094	   </YourExtension99>
1095	 </Extensions>

1097	5.4.2.1.  OTP and CR specific Usage elements

1099	   When the intended usage of a key usage is OTP and/or CR, the
1100	   following additional elements MUST be provided within the Usage
1101	   element to support the OTP and/or the response computation as
1102	   required by the underlying algorithm.  These elements also allow
1103	   customizing or configuring the result of the computation (e.g.
1104	   format, length).

1106	5.4.2.1.1.  ChallengeFormat element (OPTIONAL)

1108	   The ChallengeFormat element defines the characteristics of the
1109	   challenge in a CR usage scenario.  The Challenge element is defined
1110	   by the following attributes:

1112	   o  Format (MANDATORY), defines the format of the challenge accepted
1113	      by the device and MUST be one of the values defined in
1114	      Section 5.4.3

1116	   o  CheckDigit (OPTIONAL), defines if the device needs to check the
1117	      appended Luhn check digit, as defined in [LUHN], contained in a
1118	      provided challenge.  This is only valid if the Format attribute is
1119	      'DECIMAL'.  Value MUST be:

1121	         TRUE device will check the appended Luhn check digit in a
1122	         provided challenge

1124	         FALSE device will not check appended Luhn check digit in
1125	         challenge

1127	   o  Min (MANDATORY), defines the minimum size of the challenge
1128	      accepted by the device for CR mode.  If the Format attribute is
1129	      'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
1130	      the minimum number of digits/characters.  If the Format attribute
1131	      is 'BASE64' or 'BINARY', this value indicates the minimum number
1132	      of bytes of the unencoded value.  Value MUST be Unsigned integer.

1134	   o  Max (MANDATORY), defines the maximum size of the challenge
1135	      accepted by the device for CR mode.  If the Format attribute is
1136	      'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates
1137	      the maximum number of digits/characters.  If the Format attribute
1138	      is 'BASE64' or 'BINARY', this value indicates the maximum number
1139	      of bytes of the unencoded value.  Value MUST be Unsigned integer.

1141	5.4.2.1.2.  ResponseFormat element (MANDATORY)

1143	   The ResponseFormat element defines the characteristics of the result
1144	   of a computation.  This defines the format of the OTP or of the
1145	   response to a challenge.  For cases where the key is a PIN value,
1146	   this element contains the format of the PIN itself (e.g.  DECIMAL,
1147	   length 4 for a 4 digit PIN).  The Response attribute is defined by
1148	   the following attributes:

1150	   o  Format (MANDATORY), defines the format of the response generated
1151	      by the device and MUST be one of the values defined in
1152	      Section 5.4.3

1154	   o  CheckDigit (OPTIONAL), defines if the device needs to append a
1155	      Luhn check digit,as defined in [LUHN], to the response.  This is
1156	      only valid if the Format attribute is 'DECIMAL'.  Value MUST be:

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

1160	         FALSE device will not append a Luhn check digit to the
1161	         response.

1163	   o  Length (MANDATORY), defines the length of the response generated
1164	      by the device.  If the Format attribute is 'DECIMAL',
1165	      'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
1166	      digits/characters.  If the Format attribute is 'BASE64' or
1167	      'BINARY', this value indicates the number of bytes of the
1168	      unencoded value.  Value MUST be Unsigned integer.

1170	5.4.3.  ValueFormat

1172	   The ValueFormat element defines allowed formats for challenges or
1173	   responses in OTP algorithms.

1175	   ValueFormat is defined as follows:

1177	   <simpleType name="ValueFormat">
1178	     <restriction base="string">
1179	       <enumeration value="DECIMAL"/>
1180	       <enumeration value="HEXADECIMAL"/>
1181	       <enumeration value="ALPHANUMERIC"/>
1182	       <enumeration value="BASE64"/>
1183	       <enumeration value="BINARY"/>
1184	     </restriction>
1185	   </simpleType>

1187	      DECIMAL, Only numerical digits

1189	      HEXADECIMAL, Hexadecimal response

1191	      ALPHANUMERIC, All letters and numbers (case sensitive)

1193	      BASE64, Base 64 encoded

1195	      BINARY, Binary data, this is mainly used in case of connected
1196	      devices

1198	5.4.4.  PINPolicy

1200	   The PINPolicy element provides an extensible mean to define how the
1201	   usage of a specific key is protected by a PIN.  The PIN itself can be
1202	   transmitted as a key using the container.

1204	   If the PINPolicy element is present in the Key element then the key
1205	   is protected with a PIN as defined within the PINPolicy element.  The
1206	   PINPolicy element also has an extension point defined as xs:any to
1207	   allow future extensibility

1209	   PINPolicy is defined as follows:

1211	  <xs:complexType name="PINPolicyType">
1212	      <xs:sequence>
1213	          <xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
1214	          <xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
1215	            minOccurs="0"/>
1216	          <xs:element name="MinLength"
1217	                  type="xs:unsignedInt" minOccurs="0"/>
1218	          <xs:element name="MaxLength"
1219	                  type="xs:unsignedInt" minOccurs="0"/>
1220	          <xs:element name="Format"
1221	                  type="pskc:ValueFormatType" minOccurs="0"/>
1222	          <xs:element name="Extensions"
1223	          type="pskc:ExtensionsType" minOccurs="0"
1224	          maxOccurs="unbounded"/>
1225	      </xs:sequence>
1226	      <xs:attribute name="PINKeyId" type="xs:string" use="optional"/>
1227	  </xs:complexType>

1229	   The attributes of PINPolicy have the following meaning

1231	   o  PINKeyId (OPTIONAL), the unique key Id of the key held within this
1232	      container that contains the value of the PIN that protects the key

1234	   The elements of PINPolicy have the following meaning

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

1239	   o  <MaxFailedAttempts> (OPTIONAL), the maximum number of times the
1240	      PIN can be entered wrongly before it MUST not be possible to use
1241	      the key anymore.  If PinUsageMode is 'Local' the device MUST
1242	      enforce this value, otherwise it MUST be enforced by the
1243	      validation server.

1245	   o  <MinLength> (OPTIONAL), the minimum lenght of a PIN that can be
1246	      set to protect this key.  It MUST not be possible to set a PIN
1247	      shorter than this value.  If the Format element is 'DECIMAL',
1248	      'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
1249	      digits/characters.  If the Format attribute is 'BASE64' or
1250	      'BINARY', this value indicates the number of bytes of the
1251	      unencoded value.  If PinUsageMode is 'Local' the device MUST
1252	      enforce this value, otherwise it MUST be enforced by the
1253	      validation server.

1255	   o  <MaxLength> (OPTIONAL), the maximum lenght of a PIN that can be
1256	      set to protect this key.  It MUST not be possible to set a PIN
1257	      longer than this value.  If the Format element is 'DECIMAL',
1258	      'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of
1259	      digits/characters.  If the Format attribute is 'BASE64' or
1260	      'BINARY', this value indicates the number of bytes of the
1261	      unencoded value.  If PinUsageMode is 'Local' the device MUST
1262	      enforce this value, otherwise it MUST be enforced by the
1263	      validation server.

1265	   o  <Format> (OPTIONAL), defines the format of the PIN and MUST be one
1266	      of the values defined in Section 5.4.3.  If PinUsageMode is
1267	      'Local' the device MUST enforce that the entered value is of this
1268	      format, otherwise it MUST be enforced by the validation server.

1270	   o  <Extensions> (OPTIONAL) element, is the extension point for the
1271	      entity.  All extensions are grouped under this element and will be
1272	      of type pskc:ExtensionType, which contains an optional attribute
1273	      'defintion' that can have a URI pointing at the defintion of the
1274	      extension.  In this way groups of extension can be bundled under a
1275	      subelement.  For example:

1277	 <Extensions>
1278	   <MyExtension1 xmlns="http://ACME/MyExtension.xsd">blah</MyExtension1>
1279	   <YourExtension99 xmlns="http://ACME/YourExtension.xsd">blahblah
1280	   </YourExtension99>
1281	 </Extensions>

1283	5.4.4.1.  PINUsageMode

1285	   The PINUsageMode element defines how the PIN is used with a specific
1286	   key.  The PINUsageMode element also has an extension point defined as
1287	   xs:any to allow future extensibility

1289	   PINUsageMode is defined as follows:

1291	   <xs:complexType name="PINUsageModeType">
1292	       <xs:choice maxOccurs="unbounded">
1293	           <xs:element name="Local"/>
1294	           <xs:element name="Prepend"/>
1295	           <xs:element name="Append"/>
1296	           <xs:element name="Algorithmic"/>
1297	           <xs:any namespace="##other" processContents="lax"
1298	           minOccurs="0" maxOccurs="unbounded"/>
1299	       </xs:choice>
1300	   </xs:complexType>

1302	   The elements of PINPolicy have the following meaning
1303	   o  <Local>, the PIN is checked locally on the device before allowing
1304	      the key to be used in executing the algorithm

1306	   o  <Prepend>, the PIN is prepended to the OTP or response hence it
1307	      MUST be checked by the validation server

1309	   o  <Append>, the PIN is appended to the OTP or response hence it MUST
1310	      be checked by the validation server

1312	   o  <Algorithmic>, the PIN is used as part of the algorithm
1313	      computation

1315	6.  Usage and profile of algorithms for the portable symmetric key
1316	    container

1318	   This section details the use of the XML encryption and XML signature
1319	   elements to protect the keys transported in the container.  It also
1320	   profiles the number of algorithms supported by XML encryption and XML
1321	   signature to a mandatory subset for interoperability.

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

1327	6.1.  Usage of EncryptionKey to protect keys in transit

1329	   The EncryptionKey element in the KeyContainer defines the key,
1330	   algorithm and parameters used to encrypt the Secret Key data
1331	   attributes in the Container.  The standard schema [XMLENC] is adopted
1332	   in carry such information and an encrypted value.  The encryption is
1333	   applied on each individual Secret Key data in the Container.  The
1334	   encryption method MUST be the same for all Secret Key data in the
1335	   container.

1337	   The following sections define specifically the different supported
1338	   means to protect the keys:

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

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

1346	   <KeyContainer Version="1.0"
1347	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1348	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1349	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1350	       <EncryptionKey>
1351	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
1352	       </EncryptionKey>
1353	       ....

1355	   The following is the list of symmetric key encryption algorithm and
1356	   possible parameters used to protect the Secret Key data in the
1357	   container.  Systems implementing PSKC MUST support the MANDATORY
1358	   algorithms detailed below.

1360	   The encryption algorithm URI can be one of the following.  This isn't
1361	   an exhausted list.  The other future OPTIONAL encryption algorithms
1362	   MAY be used.

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

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

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

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

1372	   o  http://www.w3.org/2001/04/xmldsig-more#camellia128 - OPTIONAL

1374	   o  http://www.w3.org/2001/04/xmldsig-more#camellia192 - OPTIONAL

1376	   o  http://www.w3.org/2001/04/xmldsig-more#camellia256 - OPTIONAL

1378	   o  http://www.w3.org/2001/04/xmlenc#kw-aes128 - OPTIONAL

1380	   o  http://www.w3.org/2001/04/xmlenc#kw-aes192 - OPTIONAL

1382	   o  http://www.w3.org/2001/04/xmlenc#kw-aes256 - OPTIONAL

1384	   o  http://www.w3.org/2001/04/xmlenc#kw-tripledes - OPTIONAL

1386	   o  http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 - OPTIONAL

1388	   o  http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 - OPTIONAL

1390	   o  http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 - OPTIONAL

1392	   When algorithms without integrity checks are used (e.g.
1393	   http://www.w3.org/2001/04/xmlenc#aes128-cbc) a keyed MAC value using
1394	   the same key as the key encryption key SHOULD be placed in the
1395	   ValueMAC element of the Data element.  In this case the MAC algorithm
1396	   type MUST be set in the MACAlgorithm element in the key container
1397	   entity as defined in Section 5.1.  Implementations of PSKC MUST
1398	   support the MANDATORY MAC algorithms detailed below.  The
1399	   MACAlgorithm URI can be one of the following:

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

1403	   o  http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 - OPTIONAL

1405	   o  http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 - OPTIONAL

1407	   o  http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 - OPTIONAL

1409	   For example:

1411	   <KeyContainer Version="1.0"
1412	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1413	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1414	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1415	       <EncryptionKey>
1416	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
1417	       </EncryptionKey>
1418	       <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
1419	       </MACAlgorithm>
1420	       .....

1422	6.1.2.  Protecting keys using passphrase based key encryption keys

1424	   To be able to support passphrase based key encryption keys as defined
1425	   in PKCS#5 the following XML representation of the PBE relates
1426	   parameters have been introduced in the schema.  Although the approach
1427	   is extensible implementations of PSKC MUST support the PKCS#5
1428	   recommended PBKDF2 and PBES2.  Differing from the PKCS#5 XML schema
1429	   definition, the PBKDF2 and PBES2 are specified in two separate
1430	   elements in a <KeyContainer>.  Considering that the same key
1431	   encryption key is used to encrypt all <Key> data in a container, the
1432	   PBKDF2 is specified in a newly defined subelement <DerivedKey> of the
1433	   <EncryptionKey>.  The PBES2 is specified by the algorithm attribute
1434	   of EncryptionMethod in the encrypted data elements with the URI
1435	   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2.

1437	   In the following, we introduce a newly defined type <DerivedKeyType>.
1438	   It is used to carry passphrase based key derivation information.  An
1439	   instance of the type MUST be included in the EncryptionKey to
1440	   indicate the passphrase identifier and key derivation.  This type is
1441	   defined as follows.

1443	<xs:complexType name="DerivedKeyType">
1444	    <xs:sequence>
1445	        <xs:element name="CarriedKeyName" type="xs:string"
1446	          minOccurs="0"/>
1447	        <xs:element name="KeyDerivationMethod"
1448	          type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1449	        <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1450	    </xs:sequence>
1451	    <xs:attribute ref="xml:id" use="optional"/>
1452	    <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1453	</xs:complexType>

1455	<xs:complexType name="KeyDerivationMethodType">
1456	    <xs:sequence>
1457	       <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
1458	    </xs:sequence>
1459	    <xs:attribute name="Algorithm" type="xs:anyURI"
1460	    use="required"/>
1461	</xs:complexType>

1463	<xs:element name="DerivedKey" type="pskc:DerivedKeyType"/>

1465	   The attributes of the DerivedKey have the following meanings:

1467	   o  xml:id (OPTIONAL), the unique ID for this key

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

1474	   The elements of the DerivedKey have the following meanings:

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

1478	   o  <KeyDerivationMethod>: define how key encryption key is derived.
1479	      Its algorithm attribute is used to indicate the key derivation
1480	      method.  When PBKDF2 is used, the URI
1481	      http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 MUST
1482	      be used.  The extensible content <xs:any> of the element can
1483	      include any other informations associated with the given
1484	      algorithm.  When PBKDF2 is used, it MUST include a subelement
1485	      <pkcs-5:PBKDF2-params> to indicate the PBKDF2 parameters such as
1486	      salt and iteration count values..

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

1491	   When PBES2 is used for encryption, its URL
1492	   http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 MUST be
1493	   specified as the algorithm attribute of <xenc:EncryptionMethod>, and
1494	   its related parameters such as underlying encryption scheme and
1495	   associated parameters such as initialization vector MUST be included
1496	   set in a subelement <pskc:EncryptionScheme> included in <xenc:
1497	   EncryptionMethod>.  The EncryptionScheme is defined as follows.

1499	  <xs:element name="EncryptionScheme" type="xenc:EncryptionMethodType"/>

1501	   When PKCS#5 password based encryption is used, the EncryptionKey and
1502	   EncryptionMethod MUST be used in exactly the form as shown below.

1504	   <?xml version="1.0" encoding="UTF-8"?>
1505	   <KeyContainer
1506	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1507	     xmlns:pkcs-5=
1508	       "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
1509	     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1510	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1511	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1512	     Version="1.0">
1513	      <pskc:EncryptionKey>
1514	         <pskc:DerivedKey>
1515	           <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
1516	           <pskc:KeyDerivationMethod
1517	             Algorithm=
1518	        "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
1519	             <pkcs-5:PBKDF2-params>
1520	               <Salt>
1521	                 <Specified>Df3dRAhjGh8=</Specified>
1522	               </Salt>
1523	               <IterationCount>2000</IterationCount>
1524	               <KeyLength>16</KeyLength>
1525	               <PRF/>
1526	             </pkcs-5:PBKDF2-params>
1527	           </pskc:KeyDerivationMethod>
1528	           <xenc:ReferenceList>
1529	             <xenc:DataReference URI="#ED"/>
1530	           </xenc:ReferenceList>
1531	         </pskc:DerivedKey>
1532	      </pskc:EncryptionKey>
1533	   ....
1534	       <pskc:Device>
1535	         ...
1536	         <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
1537	           <pskc:Secret>
1538	             <pskc:EncryptedValue Id="ED">
1539	               <xenc:EncryptionMethod Algorithm=
1540	                   "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
1541	                   pkcs-5#pbes2">
1542	                 <pskc:EncryptionScheme Algorithm=
1543	                     "http://www.w3.org/2001/04/xmlenc#aes128-cbc">
1544	                 </pskc:EncryptionScheme>
1545	               </xenc:EncryptionMethod>
1546	               <xenc:CipherData>
1547	                 <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
1548	                 </xenc:CipherValue>
1549	               </xenc:CipherData>
1550	             </pskc:EncryptedValue>
1551	           </pskc:Secret>
1552	          </pskc:Key>
1553	       </pskc:Device>

1555	6.2.  Protecting keys using asymmetric algorithms

1557	   The following is the list of asymmetric key encryption algorithm and
1558	   possible parameters used to protect the Secret Key data in the
1559	   container.  Systems implementing PSKC MUST support the MANDATORY
1560	   algorithms detailed below.  The encryption algorithm URI can be one
1561	   of the following.

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

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

1567	   For example:

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

1571	 <pskc:KeyContainer Version="1.0"
1572	   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1573	   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1574	   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
1575	     <pskc:EncryptionKey>
1576	         <ds:X509Data>
1577	             <ds:X509Certificate>miib</ds:X509Certificate>
1578	         </ds:X509Data>
1579	     </pskc:EncryptionKey>
1580	     <pskc:Device>
1581	         <pskc:DeviceInfo>
1582	             <pskc:Manufacturer>Manufacturer</pskc:Manufacturer>
1583	             <pskc:SerialNo>0755225266</pskc:SerialNo>
1584	         </pskc:DeviceInfo>
1585	         <pskc:Key KeyAlgorithm=
1586	          "http://www.ietf.org/keyprov/pskc#hotp"
1587	          KeyId="0755225266">
1588	             <pskc:Issuer>AnIssuer</pskc:Issuer>
1589	             <pskc:Usage OTP="true">
1590	                 <pskc:ResponseFormat Length="8"
1591	                 Format="DECIMAL"/>
1592	             </pskc:Usage>
1593	             <pskc:Data>
1594	                 <pskc:Secret>
1595	                     <pskc:EncryptedValue Id="ED">
1596	                         <xenc:EncryptionMethod Algorithm=
1597	                         "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
1598	                         <xenc:CipherData>
1599	                          <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
1600	                          </xenc:CipherValue>
1601	                         </xenc:CipherData>
1602	                     </pskc:EncryptedValue>
1603	                 </pskc:Secret>
1604	                 <pskc:Counter>
1605	                     <PlainValue>0</PlainValue>
1606	                 </pskc:Counter>
1607	             </pskc:Data>
1608	         </pskc:Key>
1609	     </pskc:Device>
1610	 </pskc:KeyContainer>

1612	6.3.  Profile of Key Algorithm

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

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

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

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

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

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

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

1630	6.3.1.  OTP Key Algorithm Identifiers

1632	   OTP key algorithm URIs have not been defined in a commonly available
1633	   standard specification.  This document requests from IANA the
1634	   creation of a registry (see Section 8.4) and defines URIs for the
1635	   standard OTP algorithms in Section 8.4.4.

1637	6.3.2.  PIN key value compare algorithm identifier

1639	   PIN key algorithm URIs have not been defined in a commonly available
1640	   standard specification.  This document defines the following URIs for
1641	   a straight value comparison of the transported secret key data as
1642	   when required to compare a PIN.

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

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

1649	7.  Formal Syntax

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

1656	   All implementations of this standard must comply with the schema
1657	   below.

1659	<?xml version="1.0" encoding="UTF-8"?>
1660	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
1661	  xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1662	  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
1663	  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
1664	  targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
1665	  elementFormDefault="qualified" attributeFormDefault="unqualified"
1666	  version="1.0">
1667	    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
1668	      schemaLocation=
1669	      "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
1670	      xmldsig-core-schema.xsd"/>
1671	    <xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
1672	      schemaLocation="http://www.w3.org/TR/2002/
1673	      REC-xmlenc-core-20021210/xenc-schema.xsd"/>
1674	        <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>

1676	    <xs:complexType name="KeyContainerType">
1677	    <xs:sequence>
1678	        <xs:element name="EncryptionKey" type="ds:KeyInfoType"
1679	          minOccurs="0"/>
1680	        <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
1681	          minOccurs="0"/>
1682	        <xs:element name="KeyProperties"
1683	        type="pskc:KeyPropertiesType" minOccurs="0"
1684	        maxOccurs="unbounded"/>
1685	        <xs:element name="Device" type="pskc:DeviceType"
1686	          minOccurs="1" maxOccurs="unbounded"/>
1687	        <xs:element name="Signature" type="ds:SignatureType"
1688	          minOccurs="0"/>
1689	        <xs:element name="Extensions"
1690	        type="pskc:ExtensionsType" minOccurs="0"
1691	        maxOccurs="unbounded"/>
1692	    </xs:sequence>
1693	    <xs:attribute name="Version" type="pskc:VersionType"
1694	      use="required"/>
1695	    <xs:attribute ref="xml:id" use="optional"/>
1696	    </xs:complexType>
1697	    <xs:simpleType name="VersionType" final="restriction">
1698	            <xs:restriction base="xs:string">
1699	                    <xs:pattern value="\d{1,2}\.\d{1,3}"/>
1700	            </xs:restriction>
1701	    </xs:simpleType>
1702	        <xs:complexType name="KeyPropertiesType">
1703	                <xs:sequence>
1704	                        <xs:element name="Issuer"
1705	                        type="xs:string" minOccurs="0"/>
1706	                        <xs:element name="Usage"
1707	                        type="pskc:UsageType" minOccurs="0"/>
1708	                        <xs:element name="KeyProfileId"
1709	                        type="xs:string" minOccurs="0"/>
1710	                        <xs:element name="MasterKeyId"
1711	                        type="xs:string" minOccurs="0"/>
1712	                        <xs:element name="Data" type="pskc:KeyDataType"
1713	                        minOccurs="0" maxOccurs="1"/>
1714	                        <xs:element name="PINPolicy"
1715	                        type="pskc:PINPolicyType" minOccurs="0"/>
1716	                        <xs:element name="StartDate"
1717	                        type="xs:dateTime" minOccurs="0"/>
1718	                        <xs:element name="ExpiryDate"
1719	                        type="xs:dateTime" minOccurs="0"/>
1720	        <xs:element name="Extensions"
1721	        type="pskc:ExtensionsType" minOccurs="0"
1722	        maxOccurs="unbounded"/>
1723	                </xs:sequence>
1724	                <xs:attribute ref="xml:id" use="required"/>
1725	                <xs:attribute name="KeyAlgorithm"
1726	                type="pskc:KeyAlgorithmType"
1727	                use="required"/>
1728	        </xs:complexType>
1729	    <xs:complexType name="KeyType">
1730	        <xs:sequence>
1731	            <xs:element name="Issuer"
1732	            type="xs:string" minOccurs="0"/>
1733	            <xs:element name="Usage"
1734	            type="pskc:UsageType"/>
1735	                        <xs:element name="KeyProfileId"
1736	                        type="xs:string" minOccurs="0"/>
1737	                        <xs:element name="MasterKeyId"
1738	                        type="xs:string" minOccurs="0"/>
1739	            <xs:element name="FriendlyName"
1740	            type="xs:string" minOccurs="0"/>
1741	            <xs:element name="Data" type="pskc:KeyDataType"
1742	            minOccurs="0" maxOccurs="1"/>
1743	            <xs:element name="PINPolicy"
1744	            type="pskc:PINPolicyType" minOccurs="0"/>
1745	            <xs:element name="StartDate"
1746	            type="xs:dateTime" minOccurs="0"/>
1747	            <xs:element name="ExpiryDate"
1748	            type="xs:dateTime" minOccurs="0"/>
1749	            <xs:element name="UserId" type="xs:string"
1750	            minOccurs="0"/>
1751	            <xs:element name="Extensions"
1752	            type="pskc:ExtensionsType" minOccurs="0"
1753	            maxOccurs="unbounded"/>
1754	        </xs:sequence>
1755	        <xs:attribute name="KeyId"
1756	        type="xs:string" use="required"/>
1757	        <xs:attribute name="KeyAlgorithm"
1758	        type="pskc:KeyAlgorithmType"
1759	          use="optional"/>
1760	        <xs:attribute name="KeyProperties"
1761	        type="xs:IDREF" use="optional"/>
1762	    </xs:complexType>
1763	        <xs:complexType name="KeyDataType">
1764	        <xs:sequence>
1765	            <xs:element name="Secret"
1766	            type="pskc:binaryDataType"
1767	            minOccurs="0" maxOccurs="1"/>
1768	            <xs:element name="Counter"
1769	            type="pskc:longDataType"
1770	            minOccurs="0" maxOccurs="1"/>
1771	            <xs:element name="Time"
1772	            type="pskc:intDataType"
1773	            minOccurs="0" maxOccurs="1"/>
1774	            <xs:element name="TimeInterval"
1775	            type="pskc:intDataType"
1776	            minOccurs="0" maxOccurs="1"/>
1777	            <xs:element name="TimeDrift"
1778	            type="pskc:intDataType"
1779	            minOccurs="0" maxOccurs="1"/>
1780	            <xs:any namespace="##other"
1781	            minOccurs="0" maxOccurs="unbounded"/>
1782	        </xs:sequence>
1783	        </xs:complexType>
1784	    <xs:complexType name="binaryDataType">
1785	        <xs:sequence>
1786	            <xs:choice>
1787	                <xs:element name="PlainValue"
1788	                type="xs:base64Binary"/>
1789	                <xs:element name="EncryptedValue"
1790	                type="xenc:EncryptedDataType"/>
1791	            </xs:choice>
1792	                        <xs:element name="ValueMAC"
1793	                        type="xs:base64Binary" minOccurs="0"/>
1794	        </xs:sequence>
1795	    </xs:complexType>
1796	    <xs:complexType name="intDataType">
1797	        <xs:sequence>
1798	            <xs:choice>
1799	                <xs:element name="PlainValue"
1800	                type="xs:int"/>
1801	                <xs:element name="EncryptedValue"
1802	                type="xenc:EncryptedDataType"/>
1803	            </xs:choice>
1804	                        <xs:element name="ValueMAC"
1805	                        type="xs:base64Binary" minOccurs="0"/>
1806	        </xs:sequence>
1807	    </xs:complexType>
1808	    <xs:complexType name="stringDataType">
1809	        <xs:sequence>
1810	            <xs:choice>
1811	                <xs:element name="PlainValue"
1812	                type="xs:string"/>
1813	                <xs:element name="EncryptedValue"
1814	                type="xenc:EncryptedDataType"/>
1815	            </xs:choice>
1816	                        <xs:element name="ValueMAC"
1817	                        type="xs:base64Binary" minOccurs="0"/>
1818	        </xs:sequence>
1819	    </xs:complexType>
1820	    <xs:complexType name="longDataType">
1821	        <xs:sequence>
1822	            <xs:choice>
1823	                <xs:element name="PlainValue"
1824	                type="xs:long"/>
1825	                <xs:element name="EncryptedValue"
1826	                type="xenc:EncryptedDataType"/>
1827	            </xs:choice>
1828	                        <xs:element name="ValueMAC"
1829	                        type="xs:base64Binary" minOccurs="0"/>
1830	        </xs:sequence>
1831	    </xs:complexType>
1832	    <xs:complexType name="DerivedKeyType">
1833	        <xs:sequence>
1834	            <xs:element name="KeyDerivationMethod"
1835	              type="pskc:KeyDerivationMethodType" minOccurs="0"/>
1836	            <xs:element ref="xenc:ReferenceList" minOccurs="0"/>
1837	            <xs:element name="CarriedKeyName" type="xs:string"
1838	              minOccurs="0"/>
1839	        </xs:sequence>
1840	        <xs:attribute ref="xml:id" use="optional"/>
1841	        <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
1842	    </xs:complexType>
1843	    <xs:complexType name="KeyDerivationMethodType">
1844	        <xs:sequence>
1845	            <xs:any namespace="##other" minOccurs="0"
1846	            maxOccurs="unbounded"/>
1847	        </xs:sequence>
1848	        <xs:attribute name="Algorithm" type="xs:anyURI"
1849	        use="required"/>
1850	    </xs:complexType>
1851	    <xs:complexType name="PINPolicyType">
1852	        <xs:sequence>
1853	            <xs:element name="PINUsageMode"
1854	              type="pskc:PINUsageModeType"/>
1855	            <xs:element name="MaxFailedAttempts" type="xs:unsignedInt"
1856	              minOccurs="0"/>
1857	            <xs:element name="MinLength"
1858	                    type="xs:unsignedInt" minOccurs="0"/>
1859	            <xs:element name="MaxLength"
1860	                    type="xs:unsignedInt" minOccurs="0"/>
1861	            <xs:element name="Format"
1862	                type="pskc:ValueFormatType" minOccurs="0"/>
1863	        <xs:element name="Extensions"
1864	        type="pskc:ExtensionsType" minOccurs="0"
1865	        maxOccurs="unbounded"/>
1866	        </xs:sequence>
1867	        <xs:attribute name="PINKeyId" type="xs:string"
1868	          use="optional"/>
1869	    </xs:complexType>
1870	    <xs:complexType name="PINUsageModeType">
1871	            <xs:choice maxOccurs="unbounded">
1872	                    <xs:element name="Local"/>
1873	                    <xs:element name="Prepend"/>
1874	                    <xs:element name="Append"/>
1875	                    <xs:element name="Algorithmic"/>
1876	                    <xs:any namespace="##other"
1877	                    processContents="lax" minOccurs="0"
1878	                    maxOccurs="unbounded"/>
1879	            </xs:choice>
1880	    </xs:complexType>
1881	    <xs:complexType name="DeviceInfoType">
1882	        <xs:sequence>
1883	        <xs:element name="Manufacturer" type="xs:string"/>
1884	        <xs:element name="SerialNo" type="xs:string"/>
1885	        <xs:element name="Model" type="xs:string"
1886	        minOccurs="0"/>
1887	        <xs:element name="IssueNo" type="xs:string"
1888	        minOccurs="0"/>
1889	        <xs:element name="DeviceBinding" type="xs:string"
1890	        minOccurs="0"/>
1891	        <xs:element name="StartDate" type="xs:dateTime"
1892	        minOccurs="0"/>
1893	        <xs:element name="ExpiryDate" type="xs:dateTime"
1894	        minOccurs="0"/>
1895	        <xs:element name="Extensions"
1896	        type="pskc:ExtensionsType" minOccurs="0"
1897	        maxOccurs="unbounded"/>
1898	        </xs:sequence>
1899	    </xs:complexType>
1900	    <xs:complexType name="DeviceType">
1901	      <xs:sequence>
1902	        <xs:element name="DeviceInfo" type="pskc:DeviceInfoType"
1903	          minOccurs="0"/>
1904	        <xs:element name="Key" type="pskc:KeyType"
1905	          maxOccurs="unbounded"/>
1906	        <xs:element name="User" type="xs:string"
1907	        minOccurs="0"/>
1908	        <xs:element name="Extensions"
1909	        type="pskc:ExtensionsType" minOccurs="0"
1910	        maxOccurs="unbounded"/>
1911	      </xs:sequence>
1912	    </xs:complexType>
1913	    <xs:complexType name="UsageType">
1914	        <xs:sequence>
1915	            <xs:element name="ChallengeFormat" minOccurs="0">
1916	                <xs:complexType>
1917	                    <xs:attribute name="Format"
1918	                      type="pskc:ValueFormatType" use="required"/>
1919	                    <xs:attribute name="Min" type="xs:unsignedInt"
1920	                      use="required"/>
1921	                    <xs:attribute name="Max" type="xs:unsignedInt"
1922	                      use="required"/>
1923	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1924	                      default="false"/>
1925	                </xs:complexType>
1926	            </xs:element>
1927	            <xs:element name="ResponseFormat">
1928	                <xs:complexType>
1929	                    <xs:attribute name="Format"
1930	                      type="pskc:ValueFormatType" use="required"/>
1931	                    <xs:attribute name="Length" type="xs:unsignedInt"
1932	                      use="required"/>
1933	                    <xs:attribute name="CheckDigits" type="xs:boolean"
1934	                      default="false"/>
1935	                </xs:complexType>

1937	            </xs:element>
1938	        <xs:element name="Extensions"
1939	        type="pskc:ExtensionsType" minOccurs="0"
1940	        maxOccurs="unbounded"/>
1941	            </xs:sequence>
1942	            <xs:attribute name="OTP" type="xs:boolean" default="false"/>
1943	            <xs:attribute name="CR" type="xs:boolean" default="false"/>
1944	            <xs:attribute name="Integrity" type="xs:boolean"
1945	              default="false"/>
1946	            <xs:attribute name="Encrypt" type="xs:boolean"
1947	              default="false"/>
1948	            <xs:attribute name="Unlock" type="xs:boolean"
1949	              default="false"/>
1950	             <xs:anyAttribute namespace="##other"/>
1951	    </xs:complexType>
1952	    <xs:complexType name="ExtensionsType">
1953	      <xs:sequence>
1954	        <xs:any namespace="##other" processContents="lax"
1955	        maxOccurs="unbounded"/>
1956	      </xs:sequence>
1957	      <xs:attribute name="definition" type="xs:anyURI"
1958	      use="optional"/>
1959	    </xs:complexType>
1960	    <xs:simpleType name="KeyAlgorithmType">
1961	        <xs:restriction base="xs:anyURI"/>
1962	    </xs:simpleType>
1963	    <xs:simpleType name="ValueFormatType">
1964	        <xs:restriction base="xs:string">
1965	            <xs:enumeration value="DECIMAL"/>
1966	            <xs:enumeration value="HEXADECIMAL"/>
1967	            <xs:enumeration value="ALPHANUMERIC"/>
1968	            <xs:enumeration value="BASE64"/>
1969	            <xs:enumeration value="BINARY"/>
1970	        </xs:restriction>
1971	    </xs:simpleType>

1973	    <xs:element name="DerivedKey" type="pskc:DerivedKeyType"/>
1974	    <xs:element name="EncryptionScheme"
1975	        type="xenc:EncryptionMethodType"/>
1976	    <xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
1977	</xs:schema>
1978	8.  IANA Considerations

1980	8.1.  Content-type registration for 'application/pskc+xml'

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

1986	   MIME media type name:  application

1988	   MIME subtype name:  pskc+xml

1990	   Mandatory parameters:  none

1992	   Optional parameters:  charset

1994	      Indicates the character encoding of enclosed XML.

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

2000	   Security considerations:  This content type is designed to carry PSKC
2001	      protocol payloads.

2003	   Interoperability considerations:  None

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

2008	   Applications which use this media type:  This MIME type is being used
2009	      as a symmetric key container format for transport and provisioning
2010	      of symmetric keys (One Time Password (OTP) shared secrets or
2011	      symmetric cryptographic keys) to different types of strong
2012	      authentication devices.  As such, it is used for key provisioning
2013	      systems.

2015	   Additional information:

2017	      Magic Number:  None

2019	      File Extension:  .pskcxml

2021	      Macintosh file type code:  'TEXT'

2023	   Personal and email address for further information:  Philip Hoyer,
2024	      Philip.Hoyer@actividentity.com

2026	   Intended usage:  LIMITED USE

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

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

2033	8.2.  XML Schema Registration

2035	   This section registers an XML schema as per the guidelines in
2036	   [RFC3688].

2038	   URI:  urn:ietf:params:xml:ns:keyprov:pskc:1.0

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

2043	   XML Schema:  The XML schema to be registered is contained in
2044	      Section 7.  Its first line is

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

2048	      and its last line is

2050	   </xs:schema>

2052	8.3.  URN Sub-Namespace Registration for
2053	      urn:ietf:params:xml:ns:keyprov:pskc:1.0

2055	   This section registers a new XML namespace,
2056	   "urn:ietf:params:xml:ns:keyprov:pskc:1.0", per the guidelines in
2057	   [RFC3688].

2059	   URI:  urn:ietf:params:xml:ns:keyprov:pskc:1.0

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

2064	   XML:

2066	   BEGIN
2067	   <?xml version="1.0"?>
2068	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
2069	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
2070	   <html xmlns="http://www.w3.org/1999/xhtml">
2071	   <head>
2072	     <meta http-equiv="content-type"
2073	           content="text/html;charset=iso-8859-1"/>
2074	     <title>PSKC Namespace</title>
2075	   </head>
2076	   <body>
2077	     <h1>Namespace for PSKC</h1>
2078	     <h2>urn:ietf:params:xml:ns:keyprov:pskc:1.0</h2>
2079	   <p>See <a href="[URL of published RFC]">RFCXXXX
2080	       [NOTE TO IANA/RFC-EDITOR:
2081	        Please replace XXXX with the RFC number of this
2082	       specification.]</a>.</p>
2083	   </body>
2084	   </html>
2085	   END

2087	8.4.  Symmetric Key Algorithm Identifier Registry

2089	   This specification requests the creation of a new IANA registry for
2090	   symmetric key cryptographic algorithm identifiers in accordance with
2091	   the principles set out in RFC 5226 [RFC5226]as follows:

2093	8.4.1.  Applicability

2095	   The use of URIs as algorithm identifiers provides an effectively
2096	   unlimited namespace.  While this eliminates the possibility of
2097	   namespace exhaustion it creates a new concern, that divergent
2098	   identifiers will be employed for the same purpose in different
2099	   contexts.

2101	   The key algorithm registry is intended to provide a means of
2102	   specifying the canonical identifier to be used for a given algorithm.
2103	   If an algorithm has an identifier specified in the registry an
2104	   application that is conformant to a protocol specification that
2105	   specifies use of that registry to define identifiers SHOULD always
2106	   use that particular form of the identifier when originating data.  A
2107	   conformant application MAY accept other identifiers in data that is
2108	   received.

2110	   For the sake of expediency, the initial registry only defines
2111	   algorithm classes for symmetric algorithms plus cryptographic message
2112	   digest functions (one-way hash).  While the same principles may be
2113	   extended to asymmetric algorithms, doing so would require much
2114	   greater consideration of issues such as key length and treatment of
2115	   parameters, particularly where elliptic curve cryptography algorithms
2116	   are concerned.

2118	   As part of this registry the IANA will maintain the following
2119	   information:

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

2123	   Class  The type of algorithm, encryption, Message Authentication Code
2124	      (MAC), One Time Password (OTP), Digest, etc.

2126	   Canonical URI  The canonical URI to be used to identify the
2127	      algorithm.

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

2132	   Identifier Definition  A reference to the document in which the use
2133	      of the identifier to refer to the algorithm is described.  This
2134	      would ideally be the document in which the algorithm is defined.

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

2140	   Note that where a single algorithm has different forms distinguished
2141	   by parameters such as key length, the algorithm class and each
2142	   combination of algorithm parameters may be considered a distinct
2143	   algorithm for the purpose of assigning identifiers.

2145	8.4.2.  Registerable Algorithms

2147	8.4.2.1.  Assigned URIs

2149	   If the registrant wishes to have a URI assigned, then a URN of the
2150	   form

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

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

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

2163	   NOTE: Expert Review is sufficient in cases where the request does not
2164	   require a URN assignment in the IETF namespace.  IETF consensus is
2165	   not required.

2167	8.4.2.2.  Assigned Classes

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

2173	   The initial assigned classes are:

2175	   Digest  A cryptographic Digest algorithm.

2177	   MAC  A Message Authentication Code algorithm.

2179	   Symmetric  A symmetric encryption algorithm.

2181	   OTP  A one time password (OTP) algorithm.

2183	8.4.3.  Registration Procedures

2185	8.4.3.1.  Review

2187	   Algorithm identifier registrations are to be subject to Expert Review
2188	   as per RFC 5226 [RFC5226].

2190	   The need for supporting documentation for the registration depends on
2191	   the nature of the request.  In the case of a cryptographic algorithm
2192	   that is being described for publication as an RFC, the request for a
2193	   URI allocation would normally appear within the RFC itself.  In the
2194	   case of a cryptographic algorithm that is fully and comprehensively
2195	   defined in another form, it would not be necessary to duplicate the
2196	   information for the sake of issuing the information in the RFC
2197	   series.  In other cases an RFC may be required in order to ensure
2198	   that certain algorithm parameters are sufficiently and unambiguously
2199	   defined.

2201	   The scope of such expert review is to be strictly limited to
2202	   identifying possible ambiguity and/or duplication of existing
2203	   identifiers.  The expert review MUST NOT consider the cryptographic
2204	   properties, intellectual property considerations or any other factor
2205	   not related to the use of the identifier.

2207	   In reviewing a request, the expert should consider whether other URI
2208	   identifiers are already defined for a given algorithm.  In such cases
2209	   it is the duty of the expert to bring the potential duplication to
2210	   the notice of the proposers of the registration and the Security Area
2211	   Directors.  If the proposers are not willing to accept registration
2212	   of the existing identifier the IETF Consensus policy is to apply.

2214	   In reviewing a request, the expert should consider whether the
2215	   algorithm is sufficiently defined to allow successful interoperation.
2216	   In particular the expert should consider whether issues such as key
2217	   sizes and byte order are sufficiently defined to allow for
2218	   interoperation.

2220	   While the definition requirement MAY be satisfed by a comprehensive
2221	   specification of the algorithm, disclosure of the algorithm is not
2222	   mandatory.

2224	8.4.3.2.  Canonical URI

2226	   Until the IANA requests or implements an automated process for the
2227	   registration of these elements, any specifications must make that
2228	   request part of the IANA considerations section of their respective
2229	   documents.  That request must be in the form of the following
2230	   template:

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

2234	   Class  The type of algorithm, encryption, Message Authentication Code
2235	      (MAC), One Time Password (OTP), Digest, etc.  As specified by a
2236	      defined algorithm class.

2238	   URI  The canonical URI to be used to identify the algorithm.

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

2243	   Identifier Definition  A reference to the document in which the use
2244	      of the identifier to refer to the algorithm is described.  This
2245	      would ideally be the document in which the algorithm is defined.

2247	   Registrant Contact  A reference to the document in which the use of
2248	      the identifier to refer to the algorithm is described.  This would
2249	      ideally be the document in which the algorithm is defined.

2251	8.4.3.3.  Alias URI

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

2258	   Alias for URI  The canonical URI that identifies the algorithm.  The
2259	      URI referenced MUST be a canonical URI.

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

2264	8.4.4.  Initial Values

2266	   The following initial values are defined.  Note that these values are
2267	   limited to identifiers that are required by KEYPROV but not specified
2268	   elsewhere:

2270	8.4.4.1.  HOTP

2272	   Common Name:  HOTP

2274	   Class:  OTP

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

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

2280	   Identifier Definition:  (this RFC)

2282	   Registrant Contact:  IESG

2284	   Profile of XML attributes and subelements of the <Key> entity:

2286	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2287	      present.  The "OTP" attribute of the <Usage> MUST be set "true"
2288	      and it MUST be the only attribute set.  The element
2289	      <ResponseFormat> of the <Usage> MUST be used to indicate the OTP
2290	      length and the value format.

2292	      For the <Data> elements of a <Key> of this algorithm, the
2293	      following subelements MUST be present in either the <Key> element
2294	      itself or an commonly shared <KeyProperties> element.

2296	      *  Counter

2298	      The following additional constraints apply:

2300	         - The value of the <Secret> element MUST contain key material
2301	         with a lengthy of at least 16 octets (128 bits) if it is
2302	         present.

2304	         - The <ResponseFormat> element MUST have the 'Format' attribute
2305	         set to "DECIMAL", and the 'Length' attribute MUST be between 6
2306	         and 9.

2308	         - The <PINPolicy> element MAY be present but the <Format> child
2309	         element of the <PINPolicy> element cannot be set to
2310	         "Algorithmic".

2312	      An example of a <Key> of this algorithm is as follows.

2314	<?xml version="1.0" encoding="UTF-8"?>
2315	<KeyContainer Version="1.0"
2316	xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
2317	    <Device>
2318	        <DeviceInfo>
2319	            <Manufacturer>TokenVendorAcme</Manufacturer>
2320	            <SerialNo>987654321</SerialNo>
2321	        </DeviceInfo>
2322	        <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
2323	        KeyId="987654321">
2324	            <Issuer>Issuer</Issuer>
2325	            <Usage OTP="true">
2326	               <ResponseFormat Length="8" Format="DECIMAL"/>
2327	            </Usage>
2328	            <Data>
2329	                <Secret>
2330	                   <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</PlainValue>
2331	                </Secret>
2332	                <Counter>
2333	                   <PlainValue>0</PlainValue>
2334	                </Counter>
2335	            </Data>
2336	        </Key>
2337	    </Device>
2338	</KeyContainer>

2340	8.4.4.2.  OCRA (OATH Chellenge Response Algorithm)

2342	   Common Name:  OCRA

2344	   Class:  OTP

2346	   URI:  http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters)
2347	      - e.g.
2348	      http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08

2350	   Algorithm Definition:  http://www.ietf.org/internet-drafts/
2351	      draft-mraihi-mutual-oath-hotp-variants-07.txt

2353	   Identifier Definition  (this RFC)

2355	   Registrant Contact:  IESG

2357	   Profile of XML attributes and subelements of the <Key> entity:

2359	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2360	      present.  The "CR" attribute of the <Usage> MUST be set "true" and
2361	      it MUST be the only attribute set.  The element <ChallengeFormat>
2362	      and <ResponseFormat> of the <Usage> MUST be present.

2364	      For the <Data> elements of a <Key> of this algorithm, the
2365	      following subelements MUST be present in either the <Key> element
2366	      itself or an commonly shared <KeyProperties> element.

2368	      *  Counter

2370	      *  Time

2372	      If the element <Time> is present, the following elements MUST be
2373	      also present.

2375	      *  TimeInterval

2377	      The following additional constraints apply:

2379	         - The value of the <Secret> element MUST contain key material
2380	         with a lengthy of at least 16 octets (128 bits) if it is
2381	         present.

2383	         - The <ResponseFormat> element MUST have the 'Format' attribute
2384	         set to "DECIMAL", and the 'Length' attribute MUST be between 6
2385	         and 9.

2387	         - The <PINPolicy> element MAY be present but the <Format> child
2388	         element of the <PINPolicy> element cannot be set to
2389	         "Algorithmic".

2391	      An example of a <Key> of this algorithm is as follows.

2393	  <?xml version="1.0" encoding="UTF-8"?>
2394	  <KeyContainer Version="1.0"
2395	  xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
2396	      <Device>
2397	          <DeviceInfo>
2398	              <Manufacturer>TokenVendorAcme</Manufacturer>
2399	              <SerialNo>987654322</SerialNo>
2400	          </DeviceInfo>
2401	          <Key KeyId="12345678"
2402	          KeyAlgorithm="http://www.ietf.org/keyprov/
2403	          pskc#OCRA-1:HOTP-SHA512-8:C-QN08">
2404	              <Issuer>Issuer</Issuer>
2405	              <Usage CR="true">
2406	                <ChallengeFormat Min="8" Max="8" Format="DECIMAL"/>
2407	                <ResponseFormat Length="8" Format="DECIMAL"/>
2408	              </Usage>
2409	              <Data>
2410	                <Secret>
2411	                   <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</PlainValue>
2412	                </Secret>
2413	                <Counter>
2414	                  <PlainValue>0</PlainValue>
2415	                </Counter>
2416	              </Data>
2417	          </Key>
2418	      </Device>
2419	  </KeyContainer>

2421	8.4.4.3.  TOTP (OATH Time based OTP)

2423	   Common Name:  TOTP

2425	   Class:  OTP

2427	   URI:  http://www.ietf.org/keyprov/pskc#totp

2429	   Algorithm Definition:  http://www.ietf.org/internet-drafts/
2430	      draft-mraihi-totp-timebased-00.txt

2432	   Identifier Definition  (this RFC)

2434	   Registrant Contact:  IESG

2436	   Profile of XML attributes and subelements of the <Key> entity:

2438	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2439	      present.  The "OTP" attribute of the <Usage> MUST be set "true"
2440	      and it MUST be the only attribute set.  The element
2441	      <ResponseFormat> of the <Usage> MUST be used to indicate the OTP
2442	      length and the value format.

2444	      For the <Data> elements of a <Key> of this algorithm, the
2445	      following subelements MUST be present in either the <Key> element
2446	      itself or an commonly shared <KeyProperties> element.

2448	      *  Time

2450	      *  TimeInterval

2452	      The following additional constraints apply:

2454	         - The value of the <Secret> element MUST contain key material
2455	         with a lengthy of at least 16 octets (128 bits) if it is
2456	         present.

2458	         - The <ResponseFormat> element MUST have the 'Format' attribute
2459	         set to "DECIMAL", and the 'Length' attribute MUST be between 6
2460	         and 9.

2462	         - The <PINPolicy> element MAY be present but the <Format> child
2463	         element of the <PINPolicy> element cannot be set to
2464	         "Algorithmic".

2466	      An example of a <Key> of this algorithm is as follows.

2468	   <?xml version="1.0" encoding="UTF-8"?>
2469	   <KeyContainer Version="1.0"
2470	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
2471	       <Device>
2472	           <DeviceInfo>
2473	               <Manufacturer>TokenVendorAcme</Manufacturer>
2474	               <SerialNo>987654323</SerialNo>
2475	           </DeviceInfo>
2476	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#totp"
2477	           KeyId="987654323">
2478	               <Issuer>Issuer</Issuer>
2479	               <Usage OTP="true">
2480	                   <ResponseFormat Length="6" Format="DECIMAL"/>
2481	               </Usage>
2482	               <Data>
2483	                   <Secret>
2484	                       <PlainValue>
2485	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
2486	                       </PlainValue>
2487	                   </Secret>
2488	                   <Time>
2489	                       <PlainValue>0</PlainValue>
2490	                   </Time>
2491	                   <TimeInterval>
2492	                       <PlainValue>30</PlainValue>
2493	                   </TimeInterval>
2494	                   <TimeDrift>
2495	                       <PlainValue>4</PlainValue>
2496	                   </TimeDrift>
2497	               </Data>
2498	           </Key>
2499	       </Device>
2500	   </KeyContainer>

2502	8.4.4.4.  KEYPROV-PIN

2504	   Common Name:  KEYPROV-PIN

2506	   Class:  Symmetric static credential comparison

2508	   URI:  http://www.ietf.org/keyprov/pskc#pin

2510	   Algorithm Definition:  (this document)

2512	   Identifier Definition  (this document)
2513	   Registrant Contact:  IESG

2515	   Profile of XML attributes and subelements of the <Key> entity:

2517	      For a <Key> of this algorithm, the <Usage> subelements MAY be
2518	      present.  No attribute of the <Usage> is required.  The element
2519	      <ResponseFormat> MAY be used to indicate the PIN value format.

2521	      The <Data> elements of a <Key> of this algorithm MUST include
2522	      <Secret>.  A key of this type is usually paired with another key
2523	      where the PIN may be used together, for example, a HOTP key.

2525	      See the example in section Section 11.2

2527	8.4.4.5.  SecurID-AES

2529	   Common Name:  SecurID-AES

2531	   Class:  OTP

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

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

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

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

2543	   Profile of XML attributes and subelements of the <Key> entity:

2545	      For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
2546	      <Usage> sub-elements MUST be present.  The "OTP" attribute of
2547	      <Usage> MUST be set to "true" and it MUST be the only attribute
2548	      set.  The <ResponseFormat> sub-element of <Usage> MUST be used to
2549	      indicate the OTP length and the value format.

2551	      The following additional constraints apply:

2553	         - The value of the <Secret> element MUST contain key material
2554	         with a lengthy of at least 16 octets (128 bits) if it is
2555	         present.

2557	         - The <ResponseFormat> element MUST have the 'Format' attribute
2558	         set to "DECIMAL", and the 'Length' attribute MUST be set to a
2559	         minimum value of 6.

2561	         - The <StartDate> and <ExpiryDate> elements MUST be of type
2562	         <xs:dateTime>.

2564	         - The <PINPolicy> element MAY be present but the <Format> child
2565	         element of the <PINPolicy> element cannot be set to
2566	         "Algorithmic".

2568	      An example of a <Key> of this algorithm is as follows.

2570	 <?xml version="1.0" encoding="UTF-8"?>
2571	 <KeyContainer Version="1.0"
2572	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
2573	   <Device>
2574	     <DeviceInfo>
2575	       <Manufacturer>RSA, The Security Division of EMC</Manufacturer>
2576	       <SerialNo>123456798</SerialNo>
2577	     </DeviceInfo>
2578	     <Key
2579	       KeyAlgorithm=http://www.rsasecurity.com/rsalabs/otps/schemas/2005
2580	       /09/otps-wst#SecurID-AES
2581	       KeyId="23456789">
2582	       <Issuer>Issuer</Issuer>
2583	       <Usage OTP="true>
2584	         <ResponseFormat Length="6" Format="DECIMAL"/>
2585	       </Usage>
2586	       <StartDate>2006-04-14T00:00:00Z</StartDate>
2587	       <ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
2588	     </Key>
2589	   </Device>
2590	 </KeyContainer>

2592	8.4.4.6.  SecurID-AES-Counter

2594	   Common Name:  SecurID-AES-Counter

2596	   Class:  OTP

2598	   URI:  http://www.rsa.com/names/2008/04/algorithms/SecurID/
2599	      SecurID-AES128-Counter

2601	   Algorithm Definition:  http://www.rsa.com/names/2008/04/algorithms/
2602	      SecurID/SecurID-AES128-Counter

2604	   Identifier Definition  http://www.rsa.com/names/2008/04/algorithms/
2605	      SecurID/SecurID-AES128-Counter

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

2610	   Profile of XML attributes and subelements of the <Key> entity:

2612	      For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
2613	      <Usage> sub-elements MUST be present.  The "OTP" attribute of
2614	      <Usage> MUST be set to "true" and it MUST be the only attribute
2615	      set.  The <ResponseFormat> sub-element of <Usage> MUST be used to
2616	      indicate the OTP length and the value format.

2618	      For the Data elements of a <Key> of this algorithm, the following
2619	      subelements MUST be present in either the <Key> element itself or
2620	      an commonly shared <KeyProperties> element.

2622	      *  Counter

2624	      The following additional constraints apply:

2626	         - The value of the <Secret> element MUST contain key material
2627	         with a lengthy of at least 16 octets (128 bits) if it is
2628	         present.

2630	         - The <ResponseFormat> element MUST have the 'Format' attribute
2631	         set to "DECIMAL", and the 'Length' attribute MUST be set to a
2632	         minimum value of 6.

2634	         - The <StartDate> and <ExpiryDate> elements MUST be of type
2635	         <xs:dateTime>.

2637	         - The <PINPolicy> element MAY be present but the <Format> child
2638	         element of the <PINPolicy> element cannot be set to
2639	         "Algorithmic".

2641	      An example of a <Key> of this algorithm is as follows.

2643	<?xml version="1.0" encoding="UTF-8"?>
2644	<KeyContainer Version="1.0"
2645	  xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
2646	    <Device>
2647	       <DeviceInfo>
2648	          <Manufacturer>RSA, The Security Division of EMC</Manufacturer>
2649	          <SerialNo>123456798</SerialNo>
2650	       </DeviceInfo>
2651	       <Key
2652	          KeyAlgorithm=http://www.rsa.com/names/2008/04/algorithms/
2653	          SecurID/SecurID-AES128-Counter
2654	          KeyId="23456789">
2655	          <Issuer>Issuer</Issuer>
2656	          <Usage OTP="true>
2657	            <ResponseFormat Length="6" Format="DECIMAL"/>
2658	          </Usage>
2659	          <StartDate>2006-04-14T00:00:00Z</StartDate>
2660	          <ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
2661	          <Data>
2662	            <Secret>
2663	              <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
2664	              </PlainValue>
2665	            </Secret>
2666	            <Counter>
2667	              <PlainValue>0</PlainValue>
2668	            </Counter>
2669	          </Data>
2670	        </Key>
2671	    </Device>
2672	</KeyContainer>

2674	8.4.4.7.  SecurID-ALGOR

2676	   Common Name:  SecurID-ALGOR

2678	   Class:  OTP

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

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

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

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

2690	   Profile of XML attributes and subelements of the <Key> entity:

2692	      For a <Key> of this algorithm, the <StartDate>, <ExpiryDate>, and
2693	      <Usage> sub-elements MUST be present.  The "OTP" attribute of
2694	      <Usage> MUST be set to "true" and it MUST be the only attribute
2695	      set.  The <ResponseFormat> sub-element of <Usage> MUST be used to
2696	      indicate the OTP length and the value format.

2698	      The following additional constraints apply:

2700	         - The value of the <Secret> element MUST contain key material
2701	         with a lengthy of at least 8 octets (64 bits) if it is present.

2703	         - The <ResponseFormat> element MUST have the 'Format' attribute
2704	         set to "DECIMAL", and the 'Length' attribute MUST be set to a
2705	         value of 6 through 8.

2707	         - The <StartDate> and <ExpiryDate> elements MUST be of type
2708	         <xs:dateTime>.

2710	         - The <PINPolicy> element MAY be present but the <Format> child
2711	         element of the <PINPolicy> element cannot be set to
2712	         "Algorithmic".

2714	      An example of a <Key> of this algorithm is as follows.

2716	   <?xml version="1.0" encoding="UTF-8"?>
2717	   <KeyContainer Version="1.0"
2718	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
2719	     <Device>
2720	       <DeviceInfo>
2721	         <Manufacturer>RSA, The Security Division of EMC</Manufacturer>
2722	         <SerialNo>123456798</SerialNo>
2723	       </DeviceInfo>
2724	       <Key
2725	           KeyAlgorithm=http://www.rsasecurity.com/rsalabs/otps/schemas/
2726	           2005/09/otps-wst#SecurID-ALGOR KeyId="23456789">
2727	         <Issuer>Issuer</Issuer>
2728	         <Usage OTP="true>
2729	            <ResponseFormat Length="6" Format="DECIMAL"/>
2730	         </Usage>
2731	         <StartDate>2006-04-14T00:00:00Z</StartDate>
2732	         <ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
2733	       </Key>
2734	     </Device>
2735	   </KeyContainer>

2737	8.4.4.8.  ActivIdentity-3DES

2739	   Common Name:  ActivIdentity-3DES

2741	   Class:  OTP

2743	   URI:  http://www.actividentity.com/2008/04/algorithms/
2744	      algorithms#ActivIdentity-3DES

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

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

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

2755	   Profile of XML attributes and subelements of the <Key> entity:

2757	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2758	      present.  This algorithm can be used for otp, challenge response,
2759	      parameter based MACing (integrity) and to generate a device unlock
2760	      code (n case of devices where there is local PIN management and
2761	      the devce has been locked after a specific amount of wrong PIN
2762	      entry attempts).  Hence the "OTP", "CR","Integrity" and "Unlock"
2763	      attribute of the <Usage> can be set to "true", but at least one of
2764	      the above MUST be set to true.  The element <ResponseFormat> of
2765	      the <Usage> MUST be used to indicate the OTP length, the value
2766	      format and optionally if a check digit is being used.  If the use
2767	      is challenge-response then the <ChallengeFormat> of the <Usage>
2768	      MUST be used to indicate the challenge minimum and maximum length,
2769	      its format and optionally if a check digit is being used.

2771	      For the <Data> elements of a <Key> of this algorithm, the
2772	      following subelements MUST be present in either the <Key> element
2773	      itself or an commonly shared <KeyProperties> element.

2775	      *  Secret

2777	      *  Counter

2779	      *  Time

2781	      *  TimeInterval

2783	      The following additional constraints apply:

2785	         - The value of the <Secret> element MUST contain key material
2786	         with a length of at least 16 octets (Double DES keys 128 bits
2787	         including parity) if it is present.

2789	         - The <ResponseFormat> element MUST have the 'Format' attribute
2790	         set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
2791	         MUST be between 6 and 16.

2793	         - The <ChallengeFormat> element MUST have the 'Format'
2794	         attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
2795	         be between 4 and 16 (The Min attribute MUST be equal or less
2796	         than the Max).

2798	         - The <PINPolicy> element MAY be present but the <Format> child
2799	         element of the <PINPolicy> element cannot be set to
2800	         "Algorithmic".

2802	      An example of a Key of this algorithm is as follows.

2804	   <?xml version="1.0" encoding="UTF-8"?>
2805	   <KeyContainer Version="1.0"
2806	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
2807	       <Device>
2808	           <DeviceInfo>
2809	               <Manufacturer>ActivIdentity</Manufacturer>
2810	               <SerialNo>34567890</SerialNo>
2811	           </DeviceInfo>
2812	           <Key KeyAlgorithm="http://www.actividentity.com/
2813	           2008/04/algorithms/algorithms#ActivIdentity-3DES"
2814	           KeyId="12345677">
2815	               <Issuer>Issuer</Issuer>
2816	               <Usage OTP="true">
2817	                   <ResponseFormat Length="8" Format="DECIMAL"/>
2818	               </Usage>
2819	               <Data>
2820	                   <Secret>
2821	                       <PlainValue>
2822	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
2823	                       </PlainValue>
2824	                   </Secret>
2825	                   <Counter>
2826	                       <PlainValue>0</PlainValue>
2827	                   </Counter>
2828	                   <Time>
2829	                       <PlainValue>0</PlainValue>
2830	                   </Time>
2831	                   <TimeInterval>
2832	                       <PlainValue>32</PlainValue>
2833	                   </TimeInterval>
2834	                   <TimeDrift>
2835	                       <PlainValue>0</PlainValue>
2836	                   </TimeDrift>
2837	               </Data>
2838	           </Key>
2839	       </Device>
2840	   </KeyContainer>

2842	8.4.4.9.  ActivIdentity-AES

2844	   Common Name:  ActivIdentity-AES

2846	   Class:  OTP

2848	   URI:  http://www.actividentity.com/2008/04/algorithms/
2849	      algorithms#ActivIdentity-AES

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

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

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

2860	   Profile of XML attributes and subelements of the <Key> entity:

2862	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2863	      present.  This algorithm can be used for otp, challenge response,
2864	      parameter based MACing (integrity) and to generate a device unlock
2865	      code (n case of devices where there is local PIN management and
2866	      the devce has been locked after a specific amount of wrong PIN
2867	      entry attempts).  Hence the "OTP", "CR","Integrity" and "Unlock"
2868	      attribute of the <Usage> can be set to "true", but at least one of
2869	      the above MUST be set to true.  The element <ResponseFormat> of
2870	      the <Usage> MUST be used to indicate the OTP length, the value
2871	      format and optionally if a check digit is being used.  If the use
2872	      is challenge-response then the <ChallengeFormat> of the <Usage>
2873	      MUST be used to indicate the challenge minimum and maximum length,
2874	      its format and optionally if a check digit is being used.

2876	      For the <Data> elements of a key of this algorithm, the following
2877	      subelements MUST be present in either the <Key> element itself or
2878	      an commonly shared <KeyProperties> element.

2880	      *  Secret

2882	      *  Counter

2884	      *  Time

2886	      *  TimeInterval

2888	      The following additional constraints apply:

2890	         - The value of the <Secret> element MUST contain key material
2891	         with a length of at least 16 octets (128 bits) if it is
2892	         present.

2894	         - The <ResponseFormat> element MUST have the 'Format' attribute
2895	         set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
2896	         MUST be between 6 and 16.

2898	         - The <ChallengeFormat> element MUST have the 'Format'
2899	         attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
2900	         be between 4 and 16 (The Min attribute MUST be equal or less
2901	         than the Max).

2903	         - The <PINPolicy> element MAY be present but the <Format> child
2904	         element of the <PINPolicy> element cannot be set to
2905	         "Algorithmic".

2907	      An example of a <Key> of this algorithm is as follows.

2909	   <?xml version="1.0" encoding="UTF-8"?>
2910	   <KeyContainer Version="1.0"
2911	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
2912	       <Device>
2913	           <DeviceInfo>
2914	               <Manufacturer>ActivIdentity</Manufacturer>
2915	               <SerialNo>34567890</SerialNo>
2916	           </DeviceInfo>
2917	           <Key KeyAlgorithm="http://www.actividentity.com/
2918	           2008/04/algorithms/algorithms#ActivIdentity-AES"
2919	           KeyId="12345677">
2920	               <Issuer>Issuer</Issuer>
2921	               <Usage OTP="true">
2922	                   <ResponseFormat Length="8" Format="DECIMAL"/>
2923	               </Usage>
2924	               <Data>
2925	                   <Secret>
2926	                       <PlainValue>
2927	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
2928	                       </PlainValue>
2929	                   </Secret>
2930	                   <Counter>
2931	                       <PlainValue>0</PlainValue>
2932	                   </Counter>
2933	                   <Time>
2934	                       <PlainValue>0</PlainValue>
2935	                   </Time>
2936	                   <TimeInterval>
2937	                       <PlainValue>32</PlainValue>
2938	                   </TimeInterval>
2939	                   <TimeDrift>
2940	                       <PlainValue>0</PlainValue>
2941	                   </TimeDrift>
2942	               </Data>
2943	           </Key>
2944	       </Device>
2945	   </KeyContainer>

2947	8.4.4.10.  ActivIdentity-DES

2949	   Common Name:  ActivIdentity-DES

2951	   Class:  OTP

2953	   URI:  http://www.actividentity.com/2008/04/algorithms/
2954	      algorithms#ActivIdentity-DES

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

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

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

2965	   Profile of XML attributes and subelements of the <Key> entity:

2967	      For a <Key> of this algorithm, the <Usage> subelements MUST be
2968	      present.  This algorithm can be used for otp, challenge response,
2969	      parameter based MACing (integrity) and to generate a device unlock
2970	      code (n case of devices where there is local PIN management and
2971	      the devce has been locked after a specific amount of wrong PIN
2972	      entry attempts).  Hence the "OTP", "CR","Integrity" and "Unlock"
2973	      attribute of the <Usage> can be set to "true", but at least one of
2974	      the above MUST be set to true.  The element <ResponseFormat> of
2975	      the <Usage> MUST be used to indicate the OTP length, the value
2976	      format and optionally if a check digit is being used.  If the use
2977	      is challenge-response then the <ChallengeFormat> of the <Usage>
2978	      MUST be used to indicate the challenge minimum and maximum length,
2979	      its format and optionally if a check digit is being used.

2981	      For the <Data> elements of a key of this algorithm, the following
2982	      subelements MUST be present in either the <Key> element itself or
2983	      an commonly shared <KeyProperties> element.

2985	      *  Counter

2987	      *  Time

2989	      *  TimeInterval

2991	      The following additional constraints apply:

2993	         - The value of the <Secret> element MUST contain key material
2994	         with a length of at least 8 octets (56 bits + parity) if it is
2995	         present.

2997	         - The <ResponseFormat> element MUST have the 'Format' attribute
2998	         set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
2999	         MUST be between 6 and 16.

3001	         - The <ChallengeFormat> element MUST have the 'Format'
3002	         attribute set to "DECIMAL", and the 'Min' and 'Max' attributes
3003	         be between 4 and 16 (The Min attribute MUST be equal or less
3004	         than the Max).

3006	         - The <PINPolicy> element MAY be present but the <Format> child
3007	         element of the <PINPolicy> element cannot be set to
3008	         "Algorithmic".

3010	      An example of a <Key> of this algorithm is as follows.

3012	   <?xml version="1.0" encoding="UTF-8"?>
3013	   <KeyContainer Version="1.0"
3014	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
3015	       <Device>
3016	           <DeviceInfo>
3017	               <Manufacturer>ActivIdentity</Manufacturer>
3018	               <SerialNo>34567890</SerialNo>
3019	           </DeviceInfo>
3020	           <Key KeyAlgorithm="http://www.actividentity.com/
3021	           2008/04/algorithms/algorithms#ActivIdentity-DES"
3022	           KeyId="12345677">
3023	               <Issuer>Issuer</Issuer>
3024	               <Usage OTP="true">
3025	                   <ResponseFormat Length="8" Format="DECIMAL"/>
3026	               </Usage>
3027	               <Data>
3028	                   <Secret>
3029	                       <PlainValue>
3030	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3031	                       </PlainValue>
3032	                   </Secret>
3033	                   <Counter>
3034	                       <PlainValue>0</PlainValue>
3035	                   </Counter>
3036	                   <Time>
3037	                       <PlainValue>0</PlainValue>
3038	                   </Time>
3039	                   <TimeInterval>
3040	                       <PlainValue>32</PlainValue>
3041	                   </TimeInterval>
3042	                   <TimeDrift>
3043	                       <PlainValue>0</PlainValue>
3044	                   </TimeDrift>
3045	               </Data>
3046	           </Key>
3047	       </Device>
3048	   </KeyContainer>

3050	8.4.4.11.  ActivIdentity-EVENT

3052	   Common Name:  ActivIdentity-EVENT

3054	   Class:  OTP

3056	   URI:  http://www.actividentity.com/2008/04/algorithms/
3057	      algorithms#ActivIdentity-EVENT

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

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

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

3068	   Profile of XML attributes and subelements of the <Key> entity:

3070	      For a <Key> of this algorithm, the <Usage> subelements MUST be
3071	      present.  This algorithm can be used for otp, challenge response,
3072	      parameter based MACing (integrity) and to generate a device unlock
3073	      code (n case of devices where there is local PIN management and
3074	      the device has been locked after a specific amount of wrong PIN
3075	      entry attempts).  Hence the "OTP", "CR","Integrity" and "Unlock"
3076	      attribute of the <Usage> can be set to "true", but at least one of
3077	      the above MUST be set to true.  The element <ResponseFormat> of
3078	      the <Usage> MUST be used to indicate the OTP length, the value
3079	      format and optionally if a check digit is being used.  If the use
3080	      is challenge-response then the <ChallengeFormat> of the <Usage>
3081	      MUST be used to indicate the challenge minimum and maximum length,
3082	      its format and optionally if a check digit is being used.

3084	      For the <Data> elements of a key of this algorithm, the following
3085	      subelements MUST be present in either the <Key> element itself or
3086	      an commonly shared <KeyProperties> element.

3088	      *  Counter

3090	      The following additional constraints apply:

3092	         - The value of the <Secret> element MUST contain key material
3093	         with a length of at least 8 octets (56 bits + parity) if it is
3094	         present.

3096	         - The <ResponseFormat> element MUST have the 'Format' attribute
3097	         set to "DECIMAL" or "HEXADECIMAL", and the 'Length' attribute
3098	         MUST be between 6 and 16.

3100	         - The <PINPolicy> element MAY be present but the <Format> child
3101	         element of the <PINPolicy> element cannot be set to
3102	         "Algorithmic".

3104	      An example of a <Key> of this algorithm is as follows.

3106	   <?xml version="1.0" encoding="UTF-8"?>
3107	   <KeyContainer Version="1.0"
3108	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
3109	       <Device>
3110	           <DeviceInfo>
3111	               <Manufacturer>ActivIdentity</Manufacturer>
3112	               <SerialNo>34567890</SerialNo>
3113	           </DeviceInfo>
3114	           <Key KeyAlgorithm="http://www.actividentity.com/
3115	           2008/04/algorithms/algorithms#ActivIdentity-EVENT"
3116	           KeyId="12345677">
3117	               <Issuer>Issuer</Issuer>
3118	               <Usage OTP="true">
3119	                   <ResponseFormat Length="8" Format="DECIMAL"/>
3120	               </Usage>
3121	               <Data>
3122	                   <Secret>
3123	                       <PlainValue>
3124	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3125	                       </PlainValue>
3126	                   </Secret>
3127	                   <Counter>
3128	                       <PlainValue>0</PlainValue>
3129	                   </Counter>
3130	               </Data>
3131	           </Key>
3132	       </Device>
3133	   </KeyContainer>

3135	9.  Security Considerations

3137	   The portable key container carries sensitive information (e.g.,
3138	   cryptographic keys) and may be transported across the boundaries of
3139	   one secure perimeter to another.  For example, a container residing
3140	   within the secure perimeter of a back-end provisioning server in a
3141	   secure room may be transported across the internet to an end-user
3142	   device attached to a personal computer.  This means that special care
3143	   must be taken to ensure the confidentiality, integrity, and
3144	   authenticity of the information contained within.

3146	9.1.  Payload confidentiality

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

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

3153	   In this case no transport layer security is required.  However,
3154	   standard security best practices apply when selecting the strength of
3155	   the cryptographic algorithm for payload encryption.  Symmetric
3156	   cryptographic cipher should be used - the longer the cryptographic
3157	   key, the stronger the protection.  At the time of this writing both
3158	   3DES and AES are mandatory algorithms but 3DES may be dropped in the
3159	   relatively near future.  Applications concerned with algorithm
3160	   longevity are advised to use AES-256-CBC.  In cases where the
3161	   exchange of key encryption keys between the sender and the receiver
3162	   is not possible, asymmetric encryption of the secret key payload may
3163	   be employed.  Similarly to symmetric key cryptography, the stronger
3164	   the asymmetric key, the more secure the protection is.

3166	   If the payload is encrypted with a method that uses one of the
3167	   password-based encryption methods provided above, the payload may be
3168	   subjected to password dictionary attacks to break the encryption
3169	   password and recover the information.  Standard security best
3170	   practices for selection of strong encryption passwords apply
3171	   [Schneier].

3173	   Practical implementations should use PBESalt and PBEIterationCount
3174	   when PBE encryption is used.  Different PBESalt value per key
3175	   container should be used for best protection.

3177	   The second approach to protecting the confidentiality of the payload
3178	   is based on using transport layer security.  The secure channel
3179	   established between the source secure perimeter (the provisioning
3180	   server from the example above) and the target perimeter (the device
3181	   attached to the end-user computer) utilizes encryption to transport
3182	   the messages that travel across.  No payload encryption is required
3183	   in this mode.  Secure channels that encrypt and digest each message
3184	   provide an extra measure of security, especially when the signature
3185	   of the payload does not encompass the entire payload.

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

3193	9.2.  Payload integrity

3195	   The portable symmetric key container provides a mean to guarantee the
3196	   integrity of the information it contains through digital signatures.
3197	   For best security practices, the digital signature of the container
3198	   should encompass the entire payload.  This provides assurances for
3199	   the integrity of all attributes.  It also allows verification of the
3200	   integrity of a given payload even after the container is delivered
3201	   through the communication channel to the target perimeter and channel
3202	   message integrity check is no longer possible.

3204	9.3.  Payload authenticity

3206	   The digital signature of the payload is the primary way of showing
3207	   its authenticity.  The recipient of the container may use the public
3208	   key associated with the signature to assert the authenticity of the
3209	   sender by tracing it back to a preloaded public key or certificate.
3210	   Note that the digital signature of the payload can be checked even
3211	   after the container has been delivered through the secure channel of
3212	   communication.

3214	   A weaker payload authenticity guarantee may be provided by the
3215	   transport layer if it is configured to digest each message it
3216	   transports.  However, no authenticity verification is possible once
3217	   the container is delivered at the recipient end.  This approach may
3218	   be useful in cases where the digital signature of the container does
3219	   not encompass the entire payload.

3221	10.  Acknowledgements

3223	   The authors of this draft would like to thank the following people
3224	   for their contributions and support to make this a better
3225	   specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
3226	   Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
3227	   Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders
3228	   Rundgren, Sean Turner and especially Robert Philpott.

3230	11.  Appendix A - Example Symmetric Key Containers

3232	   All examples are syntactically correct and compatible with the XML
3233	   schema in section 7.  The examples will be revised as the test
3234	   vectors for implementation interoperability verification.  Two of the
3235	   examples below carry some sample test inputs.

3237	11.1.  Symmetric Key Container with a single Non-Encrypted HOTP Secret
3238	       Key

3240	   Assume the following test data:

3242	      OTP Secret Key Hex Value (20 bytes):
3243	      0x3132333435363738393031323334353637383930

3245	   Sample KeyContainer:

3247	   <?xml version="1.0" encoding="UTF-8"?>
3248	   <KeyContainer Version="1.0"
3249	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
3250	       <Device>
3251	           <DeviceInfo>
3252	               <Manufacturer>TokenVendorAcme</Manufacturer>
3253	               <SerialNo>987654321</SerialNo>
3254	           </DeviceInfo>
3255	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
3256	           KeyId="987654321">
3257	               <Issuer>Issuer</Issuer>
3258	               <Usage OTP="true">
3259	                   <ResponseFormat Length="8" Format="DECIMAL"/>
3260	               </Usage>
3261	               <StartDate>2006-04-14T00:00:00Z</StartDate>
3262	               <ExpiryDate>2010-09-30T00:00:00Z</ExpiryDate>
3263	               <Data>
3264	                   <Secret>
3265	                       <PlainValue>
3266	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3267	                       </PlainValue>
3268	                   </Secret>
3269	                   <Counter>
3270	                       <PlainValue>0</PlainValue>
3271	                   </Counter>
3272	               </Data>
3273	           </Key>
3274	       </Device>
3275	   </KeyContainer>

3277	11.2.  Symmetric Key Container with a single PIN protected Non-Encrypted
3278	       HOTP Secret Key

3280	   <?xml version="1.0" encoding="UTF-8"?>
3281	   <KeyContainer Version="1.0"
3282	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
3283	       <Device>
3284	           <DeviceInfo>
3285	               <Manufacturer>TokenVendorAcme</Manufacturer>
3286	               <SerialNo>0755225266</SerialNo>
3287	           </DeviceInfo>
3288	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
3289	             KeyId="0755225266">
3290	               <Issuer>AnIssuer</Issuer>
3291	               <Usage OTP="true">
3292	                   <ResponseFormat Length="6" Format="DECIMAL"/>
3293	               </Usage>
3294	               <Data>
3295	                   <Secret>
3296	                       <PlainValue>
3297	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3298	                       </PlainValue>
3299	                   </Secret>
3300	                   <Counter>
3301	                       <PlainValue>0</PlainValue>
3302	                   </Counter>
3303	               </Data>
3304	               <PINPolicy PINKeyId="07552252661">
3305	                   <PINUsageMode>
3306	                       <Local/>
3307	                   </PINUsageMode>
3308	               </PINPolicy>
3309	           </Key>
3310	           <Key KeyId="07552252661"
3311	             KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
3312	               <Usage>
3313	                   <ResponseFormat Length="4" Format="DECIMAL"/>
3314	               </Usage>
3315	               <Data>
3316	                   <Secret>
3317	                       <PlainValue>
3318	                       MTIzNA==
3319	                       </PlainValue>
3320	                   </Secret>
3321	               </Data>
3322	           </Key>
3323	       </Device>
3324	   </KeyContainer>

3326	11.3.  Symmetric Key Container with a single AES-128-CBC Encrypted HOTP
3327	       Secret Key and non-encrypted counter value

3329	   Assume the following test data:

3331	      OTP Secret Key Hex Value (20 bytes):
3332	      0x3132333435363738393031323334353637383930

3334	      AES Key Hex Value (16 bytes): 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b

3336	      The MAC key is the same as the AES encryption key.

3338	   The sample KeyContainer:

3340	   <?xml version="1.0" encoding="UTF-8"?>
3341	   <KeyContainer Version="1.0"
3342	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
3343	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
3344	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
3345	       <EncryptionKey>
3346	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
3347	       </EncryptionKey>
3348	       <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
3349	       </MACAlgorithm>
3350	       <Device>
3351	           <DeviceInfo>
3352	               <Manufacturer>TokenVendorAcme</Manufacturer>
3353	               <SerialNo>0755225266</SerialNo>
3354	           </DeviceInfo>
3355	           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
3356	             KeyId="0755225266">
3357	               <Issuer>AnIssuer</Issuer>
3358	               <Usage OTP="true">
3359	                   <ResponseFormat Length="8" Format="DECIMAL"/>
3360	               </Usage>
3361	               <Data>
3362	                 <Secret>
3363	                    <EncryptedValue>
3364	                       <xenc:EncryptionMethod
3365	              Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
3366	                         <xenc:CipherData>
3367	                            <xenc:CipherValue>xxxxxxxxxxxxxxxxxxxxxx
3368	                             </xenc:CipherValue>
3369	                         </xenc:CipherData>
3370	                     </EncryptedValue>
3371	                     <ValueMAC>xxxxxxxxxxxxxxxxxxxxxx</ValueMAC>
3372	                 </Secret>
3373	                <Counter>
3374	                 <PlainValue>0</PlainValue>
3375	                </Counter>
3376	               </Data>
3377	           </Key>
3378	       </Device>
3379	   </KeyContainer>

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

3384	 <?xml version="1.0" encoding="UTF-8"?>
3385	 <pskc:KeyContainer
3386	   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
3387	   xmlns:pkcs-5=
3388	     "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
3389	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3390	   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
3391	   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
3392	    <pskc:EncryptionKey>
3393	       <pskc:DerivedKey>
3394	         <pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
3395	         <pskc:KeyDerivationMethod
3396	           Algorithm=
3397	      "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
3398	           <pkcs-5:PBKDF2-params>
3399	             <Salt>
3400	               <Specified>P1ciQdGbrI0=</Specified>
3401	             </Salt>
3402	             <IterationCount>2000</IterationCount>
3403	             <KeyLength>16</KeyLength>
3404	             <PRF/>
3405	           </pkcs-5:PBKDF2-params>
3406	         </pskc:KeyDerivationMethod>
3407	         <xenc:ReferenceList>
3408	           <xenc:DataReference URI="#ED"/>
3409	         </xenc:ReferenceList>
3410	       </pskc:DerivedKey>
3411	    </pskc:EncryptionKey>
3412	    <pskc:Device>
3413	       <pskc:DeviceInfo>
3414	         <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
3415	         <pskc:SerialNo>0755225266</pskc:SerialNo>
3416	       </pskc:DeviceInfo>
3417	       <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
3418	           KeyId="0755225266">
3419	             <pskc:Issuer>AnIssuer</pskc:Issuer>
3420	             <pskc:Usage OTP="true">
3421	                 <pskc:ResponseFormat Length="6" Format="DECIMAL"/>
3422	             </pskc:Usage>
3423	             <pskc:Data>
3424	               <pskc:Secret>
3425	               <pskc:EncryptedValue>
3426	                 <xenc:EncryptionMethod Algorithm=
3427	                    "http://www.rsasecurity.com/rsalabs/pkcs/schemas/
3428	                    pkcs-5#pbes2">
3429	                     <pskc:EncryptionScheme Algorithm=
3430	                       "http://www.w3.org/2001/04/xmlenc#aes128-cbc">
3431	                     </pskc:EncryptionScheme>
3432	                 </xenc:EncryptionMethod>
3433	                 <xenc:CipherData>
3434	                     <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
3435	                     </xenc:CipherValue>
3436	                 </xenc:CipherData>
3437	                 </pskc:EncryptedValue>
3438	               </pskc:Secret>
3439	               <pskc:Counter>
3440	                 <pskc:PlainValue>0</pskc:PlainValue>
3441	               </pskc:Counter>
3442	             </pskc:Data>
3443	       </pskc:Key>
3444	    </pskc:Device>
3445	    <pskc:Signature>
3446	           <ds:SignedInfo>
3447	               <ds:CanonicalizationMethod
3448	                   Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
3449	               <ds:SignatureMethod  Algorithm=
3450	                   "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
3451	               <ds:Reference URI="">
3452	                   <ds:DigestMethod Algorithm=
3453	                      "http://www.w3.org/2000/09/xmldsig#sha1"/>
3454	                   <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=
3455	                   </ds:DigestValue>
3456	               </ds:Reference>
3457	           </ds:SignedInfo>
3458	           <ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=
3459	           </ds:SignatureValue>
3460	           <ds:KeyInfo>
3461	               <ds:X509Data>
3462	                   <ds:X509IssuerSerial>
3463	                       <ds:X509IssuerName>CN=KeyProvisioningUs.com,C=US
3464	                       </ds:X509IssuerName>
3465	                       <ds:X509SerialNumber>12345678
3466	                       </ds:X509SerialNumber>
3467	                   </ds:X509IssuerSerial>
3468	               </ds:X509Data>
3469	           </ds:KeyInfo>
3470	    </pskc:Signature>
3471	 </pskc:KeyContainer>

3473	11.5.  Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
3474	       Secret Key

3476	 <?xml version="1.0" encoding="UTF-8"?>
3477	 <pskc:KeyContainer Version="1.0"
3478	   xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
3479	   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
3480	   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
3481	     <pskc:EncryptionKey>
3482	         <ds:X509Data>
3483	             <ds:X509Certificate>miib</ds:X509Certificate>
3484	         </ds:X509Data>
3485	     </pskc:EncryptionKey>
3486	     <pskc:Device>
3487	         <pskc:DeviceInfo>
3488	             <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
3489	             <pskc:SerialNo>0755225266</pskc:SerialNo>
3490	         </pskc:DeviceInfo>
3491	         <pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
3492	                   KeyId="0755225266">
3493	             <pskc:Issuer>AnIssuer</pskc:Issuer>
3494	             <pskc:Usage OTP="true">
3495	                 <pskc:ResponseFormat Length="8" Format="DECIMAL"/>
3496	             </pskc:Usage>
3497	             <pskc:Data>
3498	                 <pskc:Secret>
3499	                     <pskc:EncryptedValue Id="ED">
3500	                         <xenc:EncryptionMethod Algorithm=
3501	                         "http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
3502	                         <xenc:CipherData>
3503	                          <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
3504	                          </xenc:CipherValue>
3505	                         </xenc:CipherData>
3506	                     </pskc:EncryptedValue>
3507	                 </pskc:Secret>
3508	                 <pskc:Counter>
3509	                     <pskc:PlainValue>0</pskc:PlainValue>
3510	                 </pskc:Counter>
3511	             </pskc:Data>
3512	         </pskc:Key>
3513	     </pskc:Device>
3514	 </pskc:KeyContainer>

3516	11.6.  Symmetric Key Container with a single AES-128-CBC Encrypted OCRA
3517	       Secret Key and non-encrypted counter value

3519	   <?xml version="1.0" encoding="UTF-8"?>
3520	   <KeyContainer Version="1.0"
3521	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
3522	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
3523	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
3524	       <EncryptionKey>
3525	           <ds:KeyName>Pre-shared-key</ds:KeyName>
3526	       </EncryptionKey>
3527	       <MACAlgorithm>
3528	       http://www.w3.org/2000/09/xmldsig#hmac-sha1
3529	       </MACAlgorithm>
3530	       <Device>
3531	           <DeviceInfo>
3532	               <Manufacturer>TokenVendorAcme</Manufacturer>
3533	               <SerialNo>987654321</SerialNo>
3534	           </DeviceInfo>
3535	           <Key KeyId="12345678"
3536	           KeyAlgorithm="http://www.ietf.org/keyprov/
3537	           pskc#OCRA-1:HOTP-SHA512-8:C-QN08">
3538	               <Issuer>Issuer</Issuer>
3539	               <Usage CR="true">
3540	                   <ChallengeFormat Min="8"
3541	                   Max="8" Format="DECIMAL"/>
3542	                   <ResponseFormat
3543	                   Length="8" Format="DECIMAL"/>
3544	               </Usage>
3545	               <Data>
3546	                 <Secret>
3547	                     <EncryptedValue>
3548	                         <xenc:EncryptionMethod
3549	               Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
3550	                         <xenc:CipherData>
3551	                             <xenc:CipherValue>
3552	                     gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
3553	                             </xenc:CipherValue>
3554	                         </xenc:CipherData>
3555	                     </EncryptedValue>
3556	                     <ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
3557	                 </Secret>
3558	                   <Counter>
3559	                       <PlainValue>0</PlainValue>
3560	                   </Counter>
3561	               </Data>
3562	           </Key>
3563	       </Device>
3564	   </KeyContainer>

3566	11.7.  Symmetric Key Container with a single AES-256-CBC Encrypted TOTP
3567	       Secret Key and non-encrypted time values

3569	   <?xml version="1.0" encoding="UTF-8"?>
3570	   <KeyContainer Version="1.0"
3571	     xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"
3572	     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
3573	     xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
3574	       <EncryptionKey>
3575	           <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
3576	       </EncryptionKey>
3577	       <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
3578	       </MACAlgorithm>
3579	       <Device>
3580	           <DeviceInfo>
3581	               <Manufacturer>TokenVendorAcme</Manufacturer>
3582	               <SerialNo>0755225266</SerialNo>
3583	           </DeviceInfo>
3584	           <Key KeyAlgorithm=
3585	           "http://www.ietf.org/keyprov/pskc#totp"
3586	             KeyId="0755225266">
3587	               <Issuer>AnIssuer</Issuer>
3588	               <Usage OTP="true">
3589	                   <ResponseFormat Length="6" Format="DECIMAL"/>
3590	               </Usage>
3591	               <Data>
3592	                 <Secret>
3593	                     <EncryptedValue>
3594	                         <xenc:EncryptionMethod
3595	               Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
3596	                         <xenc:CipherData>
3597	                             <xenc:CipherValue>
3598	                     gVc5jCsntSD1rhIgwWxmWNvEIkpTgn0E6+OH5mDPAok=
3599	                             </xenc:CipherValue>
3600	                         </xenc:CipherData>
3601	                     </EncryptedValue>
3602	                     <ValueMAC>JIOeKMISfMTy7og7Saq0CZrLdfE=</ValueMAC>
3603	                 </Secret>
3604	                 <Time>
3605	                     <PlainValue>0</PlainValue>
3606	                 </Time>
3607	                 <TimeInterval>
3608	                     <PlainValue>30</PlainValue>
3609	                 </TimeInterval>
3610	                 <TimeDrift>
3611	                     <PlainValue>4</PlainValue>
3612	                 </TimeDrift>
3613	               </Data>
3614	           </Key>
3615	       </Device>
3616	   </KeyContainer>

3618	11.8.  Symmetric Key Container with two devices containing a Non-
3619	       Encrypted HOTP Secret Key each sharing common KeyProperties

3621	   <?xml version="1.0" encoding="UTF-8"?>
3622	   <KeyContainer Version="1.0"
3623	   xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
3624	           <KeyProperties xml:id="KPID1"
3625	           KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp">
3626	                   <Issuer>Issuer</Issuer>
3627	                   <Usage OTP="true">
3628	                           <ResponseFormat Length="8"
3629	                           Format="DECIMAL"/>
3630	                   </Usage>
3631	                   <Data>
3632	                           <Counter>
3633	                                   <PlainValue>0</PlainValue>
3634	                           </Counter>
3635	                   </Data>
3636	           </KeyProperties>
3637	       <Device>
3638	           <DeviceInfo>
3639	               <Manufacturer>TokenVendorAcme</Manufacturer>
3640	               <SerialNo>987654321</SerialNo>
3641	           </DeviceInfo>
3642	           <Key KeyProperties="KPID1"
3643	           KeyId="987654321">
3644	               <Data>
3645	                   <Secret>
3646	                       <PlainValue>
3647	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3648	                       </PlainValue>
3649	                   </Secret>
3650	               </Data>
3651	           </Key>
3652	       </Device>
3653	       <Device>
3654	           <DeviceInfo>
3655	               <Manufacturer>TokenVendorAcme</Manufacturer>
3656	               <SerialNo>987654322</SerialNo>
3657	           </DeviceInfo>
3658	           <Key KeyProperties="KPID1"
3659	           KeyId="987654322">
3660	               <Data>
3661	                   <Secret>
3662	                       <PlainValue>
3663	                       MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
3664	                       </PlainValue>

3666	                   </Secret>
3667	               </Data>
3668	           </Key>
3669	       </Device>
3670	   </KeyContainer>

3672	12.  References

3674	12.1.  Normative References

3676	   [LUHN]     Luhn, H., "Luhn algorithm", US Patent 2950048,
3677	              August 1960, <http://patft.uspto.gov/netacgi/
3678	              nph-Parser?patentnumber=2950048>.

3680	   [PKCS1]    Kaliski, B., "PKCS #1: RSA Cryptography Specifications
3681	              Version 2.0.", RFC 2437, October 1998.

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

3687	   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
3688	              Levels", BCP 14, RFC 2119, March 1997.

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

3693	   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
3694	              IETF URN Sub-namespace for Registered Protocol
3695	              Parameters", BCP 73, RFC 3553, June 2003.

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

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

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

3707	   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
3708	              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3709	              May 2008.

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

3715	   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
3716	              URL: http://www.w3.org/TR/xmlenc-core/,
3717	              W3C Recommendation, December 2002.

3719	12.2.  Informative References

3721	   [AlgorithmURIs]
3722	              Eastlake, D., "Additional XML Security Uniform Resource
3723	              Identifiers", RFC 4051, April 2005.

3725	   [CAP]      MasterCard International, "Chip Authentication Program
3726	              Functional Architecture", September 2004.

3728	   [DSKPP]    Doherty, A., Pei, M., Machani, S., and M. Nystrom,
3729	              "Dynamic Symmetric Key Provisioning Protocol", Internet
3730	              Draft Informational, URL: http://www.ietf.org/
3731	              internet-drafts/draft-ietf-keyprov-dskpp-05.txt,
3732	              February 2008.

3734	   [HOTP]     MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
3735	              O. Ranen, "HOTP: An HMAC-Based One Time Password
3736	              Algorithm", RFC 4226, December 2005.

3738	   [NIST-SP800-57]
3739	              National Institute of Standards and Technology,
3740	              "Recommendation for Key Management - Part I: General
3741	              (Revised)", NIST 800-57, URL: http://csrc.nist.gov/
3742	              publications/nistpubs/800-57/
3743	              sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007.

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

3748	   [OCRA]     MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.
3749	              Bajaj, "OCRA: OATH Challenge Response Algorithm", Internet
3750	              Draft Informational, URL: http://www.ietf.org/
3751	              internet-drafts/
3752	              draft-mraihi-mutual-oath-hotp-variants-06.txt,
3753	              December 2007.

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

3759	   [Schneier]
3760	              Schneier, B., "Secrets and Lies: Digitial Security in a
3761	              Networked World",  Wiley Computer Publishing, ISBN 0-8493-
3762	              8253-7, 2000.

3764	Authors' Addresses

3766	   Philip Hoyer
3767	   ActivIdentity, Inc.
3768	   117 Waterloo Road
3769	   London, SE1  8UL
3770	   UK

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

3775	   Mingliang Pei
3776	   VeriSign, Inc.
3777	   487 E. Middlefield Road
3778	   Mountain View, CA  94043
3779	   USA

3781	   Phone: +1 650 426 5173
3782	   Email: mpei@verisign.com

3784	   Salah Machani
3785	   Diversinet, Inc.
3786	   2225 Sheppard Avenue East
3787	   Suite 1801
3788	   Toronto, Ontario  M2J 5C2
3789	   Canada

3791	   Phone: +1 416 756 2324 Ext. 321
3792	   Email: smachani@diversinet.com

3794	Full Copyright Statement

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

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

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

3810	Intellectual Property

3812	   The IETF takes no position regarding the validity or scope of any
3813	   Intellectual Property Rights or other rights that might be claimed to
3814	   pertain to the implementation or use of the technology described in
3815	   this document or the extent to which any license under such rights
3816	   might or might not be available; nor does it represent that it has
3817	   made any independent effort to identify any such rights.  Information
3818	   on the procedures with respect to rights in RFC documents can be
3819	   found in BCP 78 and BCP 79.

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

3828	   The IETF invites any interested party to bring to its attention any
3829	   copyrights, patents or patent applications, or other proprietary
3830	   rights that may cover technology that may be required to implement
3831	   this standard.  Please address the information to the IETF at
3832	   ietf-ipr@ietf.org.