< draft-ietf-keyprov-pskc-00.txt   draft-ietf-keyprov-pskc-01.txt >
keyprov P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: July 17, 2009 VeriSign Expires: July 24, 2009 VeriSign
S. Machani S. Machani
Diversinet Diversinet
January 13, 2009 January 20, 2009
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-00.txt draft-ietf-keyprov-pskc-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2009. This Internet-Draft will expire on July 24, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Portable Key Container Entities Overview and Relationships . . 6 3. Portable Key Container Entities Overview and Relationships . . 6
4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 8 4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 8
4.1. <DeviceInfo> Element: Unique Device Identification . . . . 9 4.1. <DeviceInfo> Element: Unique Device Identification . . . . 9
4.2. <Key>: Embedding Keying Material . . . . . . . . . . . . . 10 4.2. <Key>: Embedding Keying Material . . . . . . . . . . . . . 10
4.3. <User> Element: User Identification . . . . . . . . . . . 11 4.3. <User> Element: User Identification . . . . . . . . . . . 11
4.4. <Usage> Element: Supplementary Information for OTP and 4.4. <Usage> Element: Supplementary Information for OTP and
CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12 CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 11
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Protection of Keys and Related Data . . . . . . . . . . . . . 19 6. Protection of Keys and Related Data . . . . . . . . . . . . . 18
6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 18
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 21 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 20
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 23
6.4. Transmission of Key Derivation Values . . . . . . . . . . 26 6.4. Transmission of Key Derivation Values . . . . . . . . . . 25
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 27
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 29
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 32
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 33
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 33
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. Content-type registration for 'application/pskc+xml' . . . 43 12.1. Content-type registration for 'application/pskc+xml' . . . 42
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 43
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 43
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 44
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 45
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 45
13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46
13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 47 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 46
13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 48 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 47
13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 48 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 47
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
16.1. Normative References . . . . . . . . . . . . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . . 50
16.2. Informative References . . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 53 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 52
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 53 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 52
A.1.1. Transport of keys from Server to Cryptographic A.1.1. Transport of keys from Server to Cryptographic
Module . . . . . . . . . . . . . . . . . . . . . . . . 53 Module . . . . . . . . . . . . . . . . . . . . . . . . 52
A.1.2. Transport of keys from Cryptographic Module to A.1.2. Transport of keys from Cryptographic Module to
Cryptographic Module . . . . . . . . . . . . . . . . . 53 Cryptographic Module . . . . . . . . . . . . . . . . . 52
A.1.3. Transport of keys from Cryptographic Module to A.1.3. Transport of keys from Cryptographic Module to
Server . . . . . . . . . . . . . . . . . . . . . . . . 54 Server . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1.4. Server to server Bulk import/export of keys . . . . . 54 A.1.4. Server to server Bulk import/export of keys . . . . . 53
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 54 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 53
A.2.1. Server to server Bulk import/export of keys . . . . . 54 A.2.1. Server to server Bulk import/export of keys . . . . . 53
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 56 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
With increasing use of symmetric key based authentication systems With increasing use of symmetric key based authentication systems,
such as systems based one time password (OTP) and challenge response such as those based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric standard format for importing and exporting (provisioning) symmetric
keys from one system to another. Traditionally authentication server keys. Traditionally, vendors of authentication servers and service
vendors and service providers have used proprietary formats for providers have used proprietary formats for importing and exporting
importing, exporting and provisioning these keys into their systems these keys into their systems making it hard to use tokens from
making it hard to use tokens from vendor A with a server from vendor vendor "Foo" with a server from vendor "Bar".
B.
This document describes a standard format for serializing symmetric
keys such as OTP shared secrets for system import, export or network/
protocol transport. The goal is that the format will facilitate
dynamic provisioning and transfer of symmetric keys such as OTP
shared secrets or encryption keys of different types. In the case of
OTP shared secrets, the format will facilitate dynamic provisioning
using an online provisioning protocol to different flavors of
embedded tokens or allow customers to import new or existing tokens
in batch or single instances into a compliant system.
This draft also specifies the key attributes required for computation
such as the initial event counter used in the HOTP algorithm [HOTP].
It is also applicable for other time-based or proprietary algorithms.
To provide an analogy, in public key environments the PKCS#12 format This document proposes a standardized XML-based key container, called
[PKCS12] is commonly used for importing and exporting private keys Portable Symmetric Key Container (PSKC), for transporting symmetric
and certificates between systems. In the environments outlined in keys and meta data. This document also specifies the information
this document where OTP keys may be transported directly down to elements that are required for computing the initial event counter
smartcards or devices with limited computing capabilities and used by the MAC-Based One Time Password Algorithm (HOTP) algorithm
explicit shared secret, configuration attribute information is [HOTP] and these elements are also applicable for other time-based
desirable. With PKCS#12, one would have to use opaque data to carry algorithms.
shared secret attributes used for OTP calculations, whereas a more
explicit attribute schema definition is better for interoperability
and efficiency.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In subsequent sections of the document we highlight mandatory NOTE: In subsequent sections of the document we highlight
elements and attributes. Optional elements and attributes are not **mandatory** XML elements and attributes. Optional elements and
explicitly indicated. attributes are not explicitly indicated, i.e., if it does not say
mandatory it is optional.
3. Portable Key Container Entities Overview and Relationships 3. Portable Key Container Entities Overview and Relationships
The portable key container is based on an XML schema definition and The portable key container is based on an XML schema definition and
contains the following main conceptual entities: contains the following main conceptual entities:
1. KeyContainer entity - representing the container that carries the 1. KeyContainer entity - representing the container that carries the
keys keys
2. Device entity - representing a physical or virtual device where 2. Device entity - representing a physical or virtual device where
the keys reside optionally bound to a specific user the keys reside optionally bound to a specific user
3. DeviceInfo entity - representing the information about the device 3. DeviceInfo entity - representing the information about the device
and criteria to uniquely identify the device and criteria to uniquely identify the device
4. Key entity - representing the key transmitted 4. Key entity - representing the key transmitted
5. KeyData entity - representing data related to the key including 5. KeyData entity - representing data related to the key including
value either in plain or encrypted value either in plain or encrypted
The figure below represents the entity relationship diagram (brackets Figure 1 shows the high-level structure of the PSKC data elements.
() denote optional elements).
----------------- -----------------
| KeyContainer | | KeyContainer |
|---------------| |---------------|
| EncryptionKey | | EncryptionKey |
| Signature | | Signature |
| ... | | ... |
----------------- -----------------
| |
| |
/|\ 1..n /|\ 1..n
---------------- ---------------- ---------------- ----------------
| Device | 1| DeviceInfo | | Device | 1| DeviceInfo |
|--------------|-----|--------------| |--------------|-----|--------------|
| (User) | | SerialNumber | | User | | SerialNumber |
---------------- | Manufacturer | ---------------- | Manufacturer |
| | .... | | | .... |
| ---------------- | ----------------
/|\ 1..n /|\ 1..n
---------------- ----------------
| Key | | Key |
|--------------| |--------------|
| ID | | ID |
| Algorithm | | Algorithm |
| (User) | | User |
| .... | | .... |
---------------- ----------------
| |
| |
/|\ 1..n -------------- /|\ 1..n --------------
---------------- | Plainvalue | ---------------- | Plainvalue |
| KeyData | -------------- | KeyData | --------------
|--------------| | |--------------| |
| name | either| | name | either|
| value |----------| | value |----------|
| ..... | ------------------ | ..... | ------------------
---------------- | EncryptedValue | ---------------- | EncryptedValue |
------------------ ------------------
Figure 1
The following sections describe in detail all the entities and The following sections describe in detail all the entities and
related XML schema elements and attributes. related XML schema elements and attributes.
4. <KeyContainer> Element: The Basics 4. <KeyContainer> Element: The Basics
In it's most basic form a PSKC document uses the top-level element In it's most basic form a PSKC document uses the top-level element
<KeyContainer> and a single <Device> element to carry key <KeyContainer> and a single <Device> element to carry key
information. information.
The following example shows such a simple PSKC document. We will use The following example shows such a simple PSKC document. We will use
skipping to change at page 8, line 42 skipping to change at page 8, line 42
</PlainValue> </PlainValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 1: Basic PSKC Key Container Example Figure 2: Basic PSKC Key Container Example
The attributes of the <KeyContainer> element have the following The attributes of the <KeyContainer> element have the following
semantic: semantic:
'Version:' The 'Version' attribute is used to identify the version 'Version:' The 'Version' attribute is used to identify the version
of the PSKC schema version. This specification defines the of the PSKC schema version. This specification defines the
initial version ("1") of the PSKC schema. This attribute is initial version ("1") of the PSKC schema. This attribute is
mandatory. mandatory.
'ID:' The 'ID' attribute carries a unique identifier for the 'ID:' The 'ID' attribute carries a unique identifier for the
container. This is useful when needing to refer to an individual container. As such, it helps to identify a specific key
key container when more than one container is embedded into a container.
larger XML document.
A <KeyContainer> element MUST contain at least one <Device> elements. A <KeyContainer> element MUST contain at least one <Device> element.
Multiple <Device> elements may be used when for bulk provisioning, Multiple <Device> elements can be used when for bulk provisioning,
see Section 8. A <Device> MUST contain at least one <Key> element. see Section 8. A <Device> MUST contain at least one <Key> element.
A <Device> MAY be bound to a user. A key SHOULD be bound to only one A <Device> MAY be bound to a user. A key SHOULD be bound to only one
<Device> element. <Device> element.
4.1. <DeviceInfo> Element: Unique Device Identification 4.1. <DeviceInfo> Element: Unique Device Identification
The <DeviceInfo> element allows to uniquely identify the device the The <DeviceInfo> element uniquely identifies the device the <Key>
<Key> element refers to. Since devices can come in different form element refers to. Since devices can come in different form factors,
factors, such as hardware tokens, smart-cards, soft tokens in a such as hardware tokens, smart-cards, soft tokens in a mobile phone
mobile phone or as a PC, this element allows different criteria to be or as a PC, this element allows different criteria to be used.
used. Combined though the criteria MUST uniquely identify the Combined though the criteria MUST uniquely identify the device. For
device. For example, for hardware tokens the combination of SerialNo example, for hardware tokens the combination of <SerialNo> and
and Manufacturer will uniquely identify a device but not SerialNo <Manufacturer> elements uniquely identifies a device but the
alone since two different token manufacturers might issue devices <SerialNo> element alone is insufficient since two different token
with the same serial number (similar to the IssuerDN and serial manufacturers might issue devices with the same serial number
number of a certificate). Symmetric keys used in the payment (similar to the Issuer Distinguished Name and serial number of a
industry are usually stored on Integrated Circuit Smart Cards. certificate).
The <DeviceInfo> element has the following child elements: The <DeviceInfo> element has the following child elements:
<Manufacturer>: This element indicates the manufacturer of the <Manufacturer>: This element indicates the manufacturer of the
device. device.
<SerialNo>: This element contains the serial number of the device <SerialNo>: This element contains the serial number of the device.
<Model>: This element describes the model of the device (e.g., one- <Model>: This element describes the model of the device (e.g., one-
button-HOTP-token-V1) button-HOTP-token-V1).
<IssueNo>: This element contains the issue number in case devices <IssueNo>: This element contains the issue number in case devices
with the same serial number that are distinguished by different with the same serial number that are distinguished by different
issue numbers issue numbers.
<DeviceBinding>: This element carries the identifier that can be <DeviceBinding>: This element carries the identifier that can be
used to bind keys to the device or class of device. When loading used to bind keys to the device or to a class of devices. When
keys into a device, this identifier can be checked against loading keys into a device, this identifier can be checked against
information obtained from the device to ensure that the correct information obtained from the device to ensure that the correct
device or class of device is being used. device or class of device is being used.
<StartDate>: This element indicates the start date of a device (such <StartDate>: and <ExpiryDate>: These two elements indicates the
as the one on a payment card, used when issue numbers are not start and end date of a device (such as the one on a payment card,
printed on cards). The date MUST be expressed in UTC form with no used when issue numbers are not printed on cards). The date MUST
timezone component. Implementations SHOULD NOT rely on time be expressed in UTC form with no timezone component.
resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds.
<ExpiryDate>: This field contains the expiry date of a device (such Implementations SHOULD NOT rely on time resolution finer than
as the one on a payment card, used when issue numbers are not milliseconds and MUST NOT generate time instants that specify leap
printed on cards). It MUST be expressed in UTC form with no seconds.
timezone component. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time Depending on the device type certain child elements of the
instants that specify leap seconds. <DeviceInfo> element are necessary to include in order to uniquely
identify a device. This document does not enumerate the different
device types and therefore does not list the elements that are
mandatory for each type of device.
4.2. <Key>: Embedding Keying Material 4.2. <Key>: Embedding Keying Material
The following attributes of the <Key> element MUST be included at a The following attributes of the <Key> element MUST be included at a
minimum: minimum:
'KeyId': This attribute carries a globally unique identifier for the 'KeyId': This attribute carries a globally unique identifier for the
symmetric key. The identifier is defined as a string of symmetric key. The identifier is defined as a string of
alphanumeric characters. alphanumeric characters.
'KeyAlgorithm': This attribute contains a unique identifier for the 'KeyAlgorithm': This attribute contains a unique identifier for the
PSKC algorithm profile. This profile associates a specific PSKC algorithm profile. This profile associates a specific
semantic to the elements and attributes contained in the <Key> semantic to the elements and attributes contained in the <Key>
element. More information about the PSKC algorithm profile element. More information about the PSKC algorithm profile
defined in this document can be found in Section 10. defined in this document can be found in Section 10.
The <Key> element has a number of optional child elements. An The <Key> element has a number of optional child elements. An
initial set is described below: initial set is described below:
<Issuer>: The key issuer name, this is normally the name of the <Issuer>: This element represents the name of the party that issued
organization that issues the key to the end user of the key. For the key. For example, a bank "Foobar Bank Inc." issuing hardware
example MyBank issuing hardware tokens to their retail banking tokens to their retail banking users may set this element to
users 'MyBank' would be the issuer. "Foobar Bank Inc.".
<FriendlyName>: A human readable name for the secret key for easier <FriendlyName>: A human readable name for the secret key for easier
reference. This element serves informational purposes only. reference. This element serves informational purposes only.
<Usage>: This element defines the intended usage of the key and <Usage>: This element provides supplementary information for usage
related metadata as defined in Section 4.4 There are cases where with OTP and CR algorithms. A more detailed discussion of the
the specific context in which the key is used can be inferred but element can be found in Section 4.4.
typically the context is provided explicitly.
<Data>: This element carries data about and related to the key.
Further description about the <Data> element can be found
subsequent to this list.
This document defines a few child element for the <Data> element,
namely
<Secret>: This element carries the value of the key itself in a <Data>: This element carries data about and related to the key. The
binary representation. follow child elements are defined for the <Data> element:
<Counter>: This element contains the event counter for event based <Secret>: This element carries the value of the key itself in a
OTP algorithms. binary representation.
<Time>: This element contains the time for time based OTP <Counter>: This element contains the event counter for event
algorithms. (If time interval is used, this element carries the based OTP algorithms.
number of time intervals passed from a specific start point,
normally algorithm dependent)
<TimeInterval>: This element carries the time interval value for <Time>: This element contains the time for time based OTP
time based OTP algorithms. algorithms. (If time interval is used, this element carries
the number of time intervals passed from a specific start
point, normally algorithm dependent)
<TimeDrift>: This element contains the device clock drift value for <TimeInterval>: This element carries the time interval value for
time based OTP algorithms. The value indicates number of seconds time based OTP algorithms.
that the device clock may drift each day.
All these elements listed above (and those defined in the future) <TimeDrift>: This element contains the device clock drift value
obey a simple structure in that they must support child element to for time based OTP algorithms. The value indicates number of
convey the content in plaintext or in encrypted format: seconds that the device clock may drift each day.
Plain Text: The <PlainValue> element carries plaintext content that All these elements listed above (and those defined in the future)
is typed, for example to xs:integer. obey a simple structure in that they MUST support child elements
to convey the content in plaintext and in encrypted format:
Encrypted Content: The <EncryptedValue> element carries encrypted Plain Text: The <PlainValue> element carries plaintext content
content. that is typed, for example to xs:integer.
Additionally, an optional <ValueMac> element, which is populated with Encrypted Content: The <EncryptedValue> element carries encrypted
a MAC generated from the unencrypted value in case the encryption content.
algorithm does not support integrity checks, may be included as a
child element.
The example shown at Figure 1 illustrates the usage of the <Data> Additionally, a <ValueMac> element, which is populated with a MAC
element with two child elements, namely <Secret> and <Counter>. Both generated from the unencrypted value in case the encryption
elements carry plaintext value within the <PlainValue> child element. algorithm does not support integrity checks, MAY be included as a
child element. The example shown at Figure 2 illustrates the
usage of the <Data> element with two child elements, namely
<Secret> and <Counter>. Both elements carry plaintext value
within the <PlainValue> child element.
4.3. <User> Element: User Identification 4.3. <User> Element: User Identification
<User> element identifies the owner or the user of the device using a The <User> element identifies the user of the device using a
distinguished name, as defined in [RFC4514]. For example: distinguished name, as defined in [RFC4514]. For example:
UID=jsmith,DC=example,DC=net UID=jsmith,DC=example,DC=net
There is no semantic associated with this element, i.e., there are no There is no semantic associated with this element, i.e., there are no
checks enforcing that only a specific user can use this key. As checks enforcing that only a specific user can use this key. As
such, this element is for informational purposes only. such, this element is for informational purposes only.
4.4. <Usage> Element: Supplementary Information for OTP and CR 4.4. <Usage> Element: Supplementary Information for OTP and CR
Algorithms Algorithms
The <Usage> element is a child element of the <Key> element. The <Usage> element is a child element of the <Key> element and this
document defines two child elements: <ChallengeFormat> and
<ResponseFormat>
The optional <ChallengeFormat> element defines the characteristics of <ChallengeFormat>:
the challenge in a CR usage scenario whereby the following attributes
are defined:
'Encoding': This mandatory attribute defines the encoding of the The <ChallengeFormat> element defines the characteristics of the
challenge accepted by the device and MUST be one of the following challenge in a CR usage scenario whereby the following attributes
values: are defined:
DECIMAL Only numerical digits 'Encoding': This mandatory attribute defines the encoding of the
challenge accepted by the device and MUST be one of the
following values:
HEXADECIMAL Hexadecimal response DECIMAL Only numerical digits
ALPHANUMERIC All letters and numbers (case sensitive) HEXADECIMAL Hexadecimal response
BASE64 Base 64 encoded ALPHANUMERIC All letters and numbers (case sensitive)
BINARY Binary data BASE64 Base 64 encoded
'CheckDigit': This optional attribute indicates whether a device BINARY Binary data
needs to check the appended Luhn check digit, as defined in
[LUHN], contained in a provided challenge. This is only valid if
the 'Encoding' attribute is 'DECIMAL'. A value of TRUE indicates
that the device will check the appended Luhn check digit in a
provided challenge. A value of indicates that the device will not
check appended Luhn check digit in challenge.
'Min': This mandatory attribute defines the minimum size of the 'CheckDigit': This optional attribute indicates whether a device
challenge accepted by the device for CR mode. If the 'Encoding' needs to check the appended Luhn check digit, as defined in
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value [LUHN], contained in a provided challenge. This is only valid
indicates the minimum number of digits/characters. If the if the 'Encoding' attribute is 'DECIMAL'. A value of TRUE
'Encoding' attribute is 'BASE64' or 'BINARY', this value indicates indicates that the device will check the appended Luhn check
the minimum number of bytes of the unencoded value. digit in a provided challenge. A value of indicates that the
device will not check appended Luhn check digit in challenge.
'Max': This mandatory attribute defines the maximum size of the 'Min': This mandatory attribute defines the minimum size of the
challenge accepted by the device for CR mode. If the 'Encoding' challenge accepted by the device for CR mode. If the
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
indicates the maximum number of digits/characters. If the 'ALPHANUMERIC' this value indicates the minimum number of
'Encoding' attribute is 'BASE64' or 'BINARY', this value indicates digits/characters. If the 'Encoding' attribute is 'BASE64' or
the maximum number of bytes of the unencoded value. 'BINARY', this value indicates the minimum number of bytes of
the unencoded value.
The <ResponseFormat> element defines the characteristics of the 'Max': This mandatory attribute defines the maximum size of the
result of a computation and defines the format of the OTP or the challenge accepted by the device for CR mode. If the
response to a challenge. For cases where the key is a PIN value, 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
this element contains the format of the PIN itself (e.g., DECIMAL, 'ALPHANUMERIC' this value indicates the maximum number of
length 4 for a 4 digit PIN). The following attributes are defined: digits/characters. If the 'Encoding' attribute is 'BASE64' or
'BINARY', this value indicates the maximum number of bytes of
the unencoded value.
'Encoding': This mandatory attribute defines the encoding of the <ResponseFormat>:
response generated by the device and MUST be one of the following
values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY
'CheckDigit': This optional attribute indicates whether the device The <ResponseFormat> element defines the characteristics of the
needs to append a Luhn check digit, as defined in [LUHN], to the result of a computation and defines the format of the OTP or the
response. This is only valid if the 'Encoding' attribute is response to a challenge. For cases where the key is a PIN value,
'DECIMAL'. If the value is TRUE then the device will append a this element contains the format of the PIN itself (e.g., DECIMAL,
Luhn check digit to the response. If the value is FALSE then the length 4 for a 4 digit PIN). The following attributes are
device will not append a Luhn check digit to the response. defined:
'Length': This mandatory attribute defines the length of the 'Encoding': This mandatory attribute defines the encoding of the
response generated by the device. If the 'Encoding' attribute is response generated by the device and MUST be one of the
'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64,
the number of digits/characters. If the 'Encoding' attribute is or BINARY.
'BASE64' or 'BINARY', this value indicates the number of bytes of
the unencoded value. 'CheckDigit': This optional attribute indicates whether the
device needs to append a Luhn check digit, as defined in
[LUHN], to the response. This is only valid if the 'Encoding'
attribute is 'DECIMAL'. If the value is TRUE then the device
will append a Luhn check digit to the response. If the value
is FALSE then the device will not append a Luhn check digit to
the response.
'Length': This mandatory attribute defines the length of the
response generated by the device. If the 'Encoding' attribute
is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value
indicates the number of digits/characters. If the 'Encoding'
attribute is 'BASE64' or 'BINARY', this value indicates the
number of bytes of the unencoded value.
5. Policy 5. Policy
This section illustrates the functionality of the <Policy> element This section illustrates the functionality of the <Policy> element
within PSKC that allows policy to be attached to a key and related within PSKC that allows policy to be attached to a key and related
meta data. This element is a child element of the <Key> element. meta data. This element is a child element of the <Key> element.
If the <Policy> element contains child elements or values within If the <Policy> element contains child elements or values within
elements/attributes that are not understood by the recipient of the elements/attributes that are not understood by the recipient of the
PSKC document then the recipient MUST assume that key usage is not PSKC document then the recipient MUST assume that key usage is not
permitted. This statement ensures that the lack of understanding of permitted. This statement ensures that the lack of understanding of
certain extension does not lead to unintended key usage. certain extension does not lead to unintended key usage.
We will start our description with an example that expands the We will start our description with an example that expands the
example shown in Figure 2. example shown in Figure 3.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" id="exampleID1" <KeyContainer Version="1" id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyId="12345678" <Key KeyId="12345678"
skipping to change at page 15, line 50 skipping to change at page 15, line 50
</Usage> </Usage>
<Data> <Data>
<Secret> <Secret>
<PlainValue>MTIzNA==</PlainValue> <PlainValue>MTIzNA==</PlainValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 2: Non-Encrypted HOTP Secret Key protected by PIN Figure 3: Non-Encrypted HOTP Secret Key protected by PIN
This document defines the following elements: This document defines the following elements:
<StartDate>: This element denotes the start date of the key. It <StartDate> and <ExpiryDate>: These two elements denote the validity
MUST NOT be possible to use this key before this date. The value period of a key. It MUST be ensured that the key is only used
MUST be expressed in UTC form, with no time zone component. between the start and the end date (inclusive). The value MUST be
expressed in UTC form, with no time zone component.
Implementations SHOULD NOT rely on time resolution finer than Implementations SHOULD NOT rely on time resolution finer than
milliseconds and MUST NOT generate time instants that specify leap milliseconds and MUST NOT generate time instants that specify leap
seconds. When this element is absent then the current time is seconds. When this element is absent then the current time is
assumed as a start time. assumed as a start time.
<ExpiryDate>: This element denotes the expiry date of the key. It <KeyUsage>: The <KeyUsage> element puts constraints on the intended
MUST NOT be possible to use this key after this date. The value usage of the key. The recipient of the PSKC document MUST enforce
MUST be expressed in UTC form, with no time zone component. the key usage. Currently, the following tokens are registered by
Implementations SHOULD NOT rely on time resolution finer than this document:
milliseconds and MUST NOT generate time instants that specify leap
seconds. When this element is absent then no expiry date is
assumed.
<KeyUsage>: The <KeyUsage> element allows to indicate the intended
usage of the key. The recipient of the PSKC document is expected
to enforce the key usage. Currently, the following tokens are
registered by this document:
OTP: The key MUST only be used for OTP generation. OTP: The key MUST only be used for OTP generation.
CR: The key MUST only be used for Challenge/Response purposes. CR: The key MUST only be used for Challenge/Response purposes.
Encrypt: The key MUST only be used for data encryption purposes. Encrypt: The key MUST only be used for data encryption purposes.
Integrity: The key MUST only be used to generate a keyed message Integrity: The key MUST only be used to generate a keyed message
digest for data integrity or authentication purposes. digest for data integrity or authentication purposes.
Unlock: The key MUST only be used for an inverse challenge Unlock: The key MUST only be used for an inverse challenge
response in the case a user has locked the device by entering a response in the case a user has locked the device by entering a
wrong PIN too many times (for devices with PIN-input wrong PIN too many times (for devices with PIN-input
capability). capability).
Decrypt: The key MUST only be used for data decryption purposes. Decrypt: The key MUST only be used for data decryption purposes.
KeyWrap: The key MUST only be used for key wrap purposes. KeyWrap: The key MUST only be used for key wrap purposes.
The element may also be repeated to allow several key usages to be The element MAY also be repeated to allow several key usages to be
expressed. When this element is absent then no key usage expressed. When this element is absent then no key usage
constraint is assumed, i.e., the key may be utilized for every constraint is assumed, i.e., the key MAY be utilized for every
usage. usage.
<PINPolicy>: The <PINPolicy> element allows policy about the PIN <PINPolicy>: The <PINPolicy> element allows policy about the PIN
usage to be associated to the key. The following attributes are usage to be associated with the key. The following attributes are
specified: specified:
'PINKeyId': This attribute contains the unique key id of the key 'PINKeyId': This attribute contains the unique key id of the key
held within this container that contains the value of the PIN held within this container that contains the value of the PIN
that protects the key. that protects the key.
'PINUsageMode': This mandatory attribute indicates the way the 'PINUsageMode': This mandatory attribute indicates the way the
PIN is used during the usage of the key. The following values PIN is used during the usage of the key. The following values
are defined: are defined:
skipping to change at page 17, line 29 skipping to change at page 17, line 25
server. server.
Append: This value indicates that the PIN is appended to the Append: This value indicates that the PIN is appended to the
OTP or response hence it MUST be checked by the validation OTP or response hence it MUST be checked by the validation
server. server.
Algorithmic: This value indicates that the PIN is used as part Algorithmic: This value indicates that the PIN is used as part
of the algorithm computation. of the algorithm computation.
'MaxFailedAttempts': This attribute indicates the maximum number 'MaxFailedAttempts': This attribute indicates the maximum number
of times the PIN can be entered wrongly before it MUST not be of times the PIN can be entered wrongly before it MUST NOT be
possible to use the key anymore. If the 'PinUsageMode'="Local" possible to use the key anymore.
then the device MUST enforce this value, otherwise it MUST be
enforced by the validation server.
'MinLength': This attribute indicates the minimum length of a PIN 'MinLength': This attribute indicates the minimum length of a PIN
that can be set to protect this key. It MUST NOT be possible that can be set to protect this key. It MUST NOT be possible
to set a PIN shorter than this value. If the 'PINFormat' to set a PIN shorter than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
value indicates the number of digits/characters. If the value indicates the number of digits/characters. If the
'PINFormat' attribute is 'BASE64' or 'BINARY', this value 'PINFormat' attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value. If the indicates the number of bytes of the unencoded value.
'PinUsageMode' attribute is set to "Local" then the device MUST
enforce this value, otherwise it MUST be enforced by the
validation server.
'MaxLength': This attribute indicates the maximum lenght of a PIN 'MaxLength': This attribute indicates the maximum lenght of a PIN
that can be set to protect this key. It MUST NOT be possible that can be set to protect this key. It MUST NOT be possible
to set a PIN longer than this value. If the 'PINFormat' to set a PIN longer than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this
value indicates the number of digits/characters. If the value indicates the number of digits/characters. If the
'PINFormat' attribute is 'BASE64' or 'BINARY', this value 'PINFormat' attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value. If the indicates the number of bytes of the unencoded value.
'PinUsageMode' attribute is set to "Local" then the device MUST
enforce this value, otherwise it MUST be enforced by the
validation server.
'PINEncoding': This attribute indicates the encoding of the PIN 'PINEncoding': This attribute indicates the encoding of the PIN
and MUST be one of the values: DECIMAL, HEXADECIMAL, and MUST be one of the values: DECIMAL, HEXADECIMAL,
ALPHANUMERIC, BASE64, or BINARY. If the 'PINUsageMode' ALPHANUMERIC, BASE64, or BINARY.
attribute is set to "Local" then the device MUST enforce that
the entered value is of this format, otherwise it MUST be If the 'PinUsageMode' attribute is set to "Local" then the device
enforced by the validation server. MUST enforce the restriction indicated in the 'MaxFailedAttempts',
'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it
MUST be enforced on the server side.
6. Protection of Keys and Related Data 6. Protection of Keys and Related Data
With the functionality described in the previous sections information With the functionality described in the previous sections information
related to keys had to be transmitted in clear text. With the help related to keys had to be transmitted in clear text. With the help
of the <EncryptionKey> element, which is a child element of the of the <EncryptionKey> element, which is a child element of the
<KeyContainer> element, it is possible to encrypt keys and associated <KeyContainer> element, it is possible to encrypt keys and associated
information. The level of encryption is applied to each individual information. The level of encryption is applied to the value of
element and the indicated encryption method MUST be the same for individual elements and the applied encryption algorithm MUST be the
elements. In subsequent sections key encryption based on pre-shared same for elements. Key encryption is supported based on the
keys, based on passphrase-based keys, and based on asymmetric keys following credentials: pre-shared keys, passphrase-based keys, and
will be discussed. asymmetric keys
6.1. Encryption based on Pre-Shared Keys 6.1. Encryption based on Pre-Shared Keys
Figure 3 shows an example that illustrates the encryption of the Figure 4 shows an example that illustrates the encryption of the
content of the <Secret> element using AES128-CBC, the plaintext value content of the <Secret> element using AES128-CBC, the plaintext value
of <Secret> is '3132333435363738393031323334353637383930'. The name of <Secret> is '3132333435363738393031323334353637383930'. The name
of the pre-shared secret is "Example-Key1", as set in the <KeyName> of the pre-shared secret is "Example-Key1", as set in the <KeyName>
element (which is a child element of the <EncryptionKey> element). element (which is a child element of the <EncryptionKey> element).
The value of the key used is '12345678901234567890123456789012'. The value of the key used is '12345678901234567890123456789012'.
Since AES128-CBC does not provide integrity checks a keyed MAC is Since AES128-CBC does not provide integrity checks a keyed MAC is
applied to the encrypted value using the algorithm indicated in applied to the encrypted value using the algorithm indicated in
<MACAlgorithm> element (in our example <MACAlgorithm> element (in our example
"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used). The result "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used). The result
of the keyed MAC computation is placed in the <ValueMAC> element. of the keyed MAC computation is placed in the <ValueMAC> element.
skipping to change at page 20, line 48 skipping to change at page 19, line 48
</ValueMAC> </ValueMAC>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 3: AES-128-CBC Encrypted Pre-Shared Secret Key Figure 4: AES-128-CBC Encrypted Pre-Shared Secret Key
When protecting the payload with pre-shared keys implementations
SHOULD set the name of the specific pre-shared key in the <KeyName>
element inside the <EncryptionKey> element.
The following is the list of symmetric key encryption algorithm and When protecting the payload with pre-shared keys implementations MUST
possible parameters for usage with pre-shared secret based set the name of the specific pre-shared key in the <KeyName> element
encryption. Systems implementing PSKC MUST support AES128-CBC (with inside the <EncryptionKey> element.
the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc).
An example list of optionally-to-implement encryption algorithms can Systems implementing PSKC MUST support AES128-CBC (with the URI of
be found below: http://www.w3.org/2001/04/xmlenc#aes128-cbc). An example list of
optionally-to-implement encryption algorithms can be found below:
Algorithm | URL Algorithm | Uniform Resource Locator (URL)
---------------+------------------------------------------------------ ---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128 Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192 Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256 Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128 KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192 KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256 KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
When algorithms without integrity checks are used, such as AES12-CBC, When algorithms without integrity checks are used, such as AES12-CBC,
a keyed MAC value using the same key as the key encryption key MUST a keyed MAC value using the same key as the key encryption key MUST
be placed in the <ValueMAC> element of the <Data> element. In this be placed in the <ValueMAC> element of the <Data> element. In this
case the MAC algorithm type MUST be set in the <MACAlgorithm> element case the MAC algorithm type MUST be set in the <MACAlgorithm> element
of the <KeyContainer> element. Implementations of PSKC MUST support of the <KeyContainer> element. Implementations of PSKC MUST support
HMAC-SHA1 (with the URI of HMAC-SHA1 (with the URI of
http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to- http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-
implement MAC algorithm. An example list of optionally-to-implement implement MAC algorithm. An example list of optionally-to-implement
MAC algorithms can be found below: MAC algorithms can be found below:
Algorithm | URL Algorithm | Uniform Resource Locator (URL)
---------------+------------------------------------------------------ ---------------+-----------------------------------------------------
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
6.2. Encryption based on Passphrase-based Keys 6.2. Encryption based on Passphrase-based Keys
To be able to support passphrase based key encryption keys as defined To be able to support passphrase based key encryption keys as defined
in PKCS#5 the following PBE related parameters have been introduced in PKCS#5 the following PBE related parameters have been introduced
into PSKC. Implementations of PSKC MUST support the PKCS#5 into PSKC. Implementations of PSKC MUST support the PKCS#5
recommended PBKDF2 and PBES2 algorithms. Differing from the PKCS#5 recommended PBKDF2 and PBES2 algorithms. Differing from the PKCS#5
XML schema definition, the PBKDF2 and PBES2 are specified in two XML schema definition, the PBKDF2 and PBES2 are specified in two
separate elements in a <KeyContainer> element: separate elements in a <KeyContainer> element:
skipping to change at page 22, line 50 skipping to change at page 21, line 48
When PBES2 is used for encryption, the URL When PBES2 is used for encryption, the URL
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 MUST be http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 MUST be
specified as the 'Algorithm' attribute of <xenc:EncryptionMethod> specified as the 'Algorithm' attribute of <xenc:EncryptionMethod>
element. The underlying encryption scheme and initialization vector element. The underlying encryption scheme and initialization vector
MUST be expressed in the <pskc:EncryptionScheme> element, which is a MUST be expressed in the <pskc:EncryptionScheme> element, which is a
child element of <xenc:EncryptionMethod>. child element of <xenc:EncryptionMethod>.
When PKCS#5 password based encryption is used, the <EncryptionKey> When PKCS#5 password based encryption is used, the <EncryptionKey>
element and <xenc:EncryptionMethod> element MUST be used in exactly element and <xenc:EncryptionMethod> element MUST be used in exactly
the form as shown in Figure 4. the form as shown in Figure 5.
In the example below, the following data is used. In the example below, the following data is used.
Password: qwerty Password: qwerty
Salt: 0x123eff3c4a72129c Salt: 0x123eff3c4a72129c
Iteration Count: 1000 Iteration Count: 1000
OTP Secret: 12345678901234567890 OTP Secret: 12345678901234567890
skipping to change at page 24, line 33 skipping to change at page 23, line 31
</xenc:CipherData> </xenc:CipherData>
<ns2:ValueMAC>cOpiQ/H7Zlj6ywiYWtwgz9cRaOA= <ns2:ValueMAC>cOpiQ/H7Zlj6ywiYWtwgz9cRaOA=
</ns2:ValueMAC> </ns2:ValueMAC>
</EncryptedValue> </EncryptedValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 4: Example of a PSKC Document using Encryption based on Figure 5: Example of a PSKC Document using Encryption based on
Passphrase-based Keys Passphrase-based Keys
6.3. Encryption based on Asymmetric Keys 6.3. Encryption based on Asymmetric Keys
When using asymmetric keys to encrypt child element of the <Data> When using asymmetric keys to encrypt child elements of the <Data>
element information about the certificate being used MUST be stated element information about the certificate being used MUST be stated
in the <X509Data> element, which is a child element of the in the <X509Data> element, which is a child element of the
<EncryptionKey> element. The encryption algorithm MUST be indicated <EncryptionKey> element. The encryption algorithm MUST be indicated
in the 'Algorithm' attribute of the <EncryptionMethod> element. In in the 'Algorithm' attribute of the <EncryptionMethod> element. In
the example shown in Figure 5 the algorithm is set to the example shown in Figure 6 the algorithm is set to
"http://www.w3.org/2001/04/xmlenc#rsa_1_5". "http://www.w3.org/2001/04/xmlenc#rsa_1_5".
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" <KeyContainer Version="1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:X509Data> <ds:X509Data>
<ds:X509Certificate>miib</ds:X509Certificate> <ds:X509Certificate>miib</ds:X509Certificate>
skipping to change at page 25, line 48 skipping to change at page 24, line 48
</EncryptedValue> </EncryptedValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 5: Example of a PSKC Document using Encryption based on Figure 6: Example of a PSKC Document using Encryption based on
Asymmetric Keys Asymmetric Keys
Systems implementing PSKC MUST support the Systems implementing PSKC MUST support the
http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm. http://www.w3.org/2001/04/xmlenc#rsa-1_5 algorithm.
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is an example of an http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p is an example of an
optional-to-implement algorithm. optional-to-implement algorithm.
6.4. Transmission of Key Derivation Values 6.4. Transmission of Key Derivation Values
skipping to change at page 27, line 33 skipping to change at page 26, line 33
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
<Policy> <Policy>
<KeyUsage>OTP</KeyUsage> <KeyUsage>OTP</KeyUsage>
</Policy> </Policy>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 6: Example of a PSKC Document transmitting a HOTP key via key The key value will be derived using the serialnumber and a pre-shared
derivation values (the key value will be derived using the masterkey identified by 'MasterKeyLabel'.
serialnumber and a pre-shared masterkey identified by
'MasterKeyLabel' ) Figure 7: Example of a PSKC Document transmitting a HOTP key via key
derivation values
7. Digital Signature 7. Digital Signature
PSKC allows a digital signature to be added to the XML document, as a PSKC allows a digital signature to be added to the XML document, as a
child element of the <KeyContainer> element. The description of the child element of the <KeyContainer> element. The description of the
XML digital signature can be found in [XMLDSIG]. XML digital signature can be found in [XMLDSIG].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer <KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
skipping to change at page 29, line 26 skipping to change at page 28, line 26
</ds:X509IssuerName> </ds:X509IssuerName>
<ds:X509SerialNumber> <ds:X509SerialNumber>
12345678 12345678
</ds:X509SerialNumber> </ds:X509SerialNumber>
</ds:X509IssuerSerial> </ds:X509IssuerSerial>
</ds:X509Data> </ds:X509Data>
</ds:KeyInfo> </ds:KeyInfo>
</Signature> </Signature>
</KeyContainer> </KeyContainer>
Figure 7: Digital Signature Example Figure 8: Digital Signature Example
8. Bulk Provisioning 8. Bulk Provisioning
The functionality of bulk provisioning can be accomplished by The functionality of bulk provisioning can be accomplished by
repeating the <Device> element multiple times within the repeating the <Device> element multiple times within the
<KeyContainer> element indicating that multiple keys are provided to <KeyContainer> element indicating that multiple keys are provided to
different devices. The <EncryptionKey> element then applies to all different devices. The <EncryptionKey> element then applies to all
<Device> elements. Furthermore, within a single <Device> element the <Device> elements. Furthermore, within a single <Device> element the
<Key> element may also be repeated providing different keys and meta <Key> element may also be repeated providing different keys and meta
data for a single device. data for a single device.
Figure 8 shows an example utilizing these capabilities. Figure 9 shows an example utilizing these capabilities.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" <KeyContainer Version="1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo> <SerialNo>654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp" <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"
skipping to change at page 32, line 28 skipping to change at page 31, line 28
</Counter> </Counter>
</Data> </Data>
<Policy> <Policy>
<StartDate>2006-04-01T00:00:00Z</StartDate> <StartDate>2006-04-01T00:00:00Z</StartDate>
<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate> <ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
</Policy> </Policy>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 8: Bulk Provisioning Example Figure 9: Bulk Provisioning Example
9. Extensibility 9. Extensibility
This section lists a few common extension points provided by PSKC: This section lists a few common extension points provided by PSKC:
New PSKC Version: Whenever it is necessary to define a new version New PSKC Version: Whenever it is necessary to define a new version
of this document then a new version number has to be allocated to of this document then a new version number has to be allocated to
refer to the new specification version. The version number is refer to the new specification version. The version number is
carried inside the 'Algorithm' attribute, as described in carried inside the 'Algorithm' attribute, as described in
Section 4, and rules for extensibililty are defined in Section 12. Section 4, and rules for extensibililty are defined in Section 12.
skipping to change at page 34, line 43 skipping to change at page 33, line 43
with a length of at least 16 octets (128 bits), if it is with a length of at least 16 octets (128 bits), if it is
present. present.
+ The <ResponseFormat> element MUST have the 'Format' + The <ResponseFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Length' attribute MUST attribute set to "DECIMAL", and the 'Length' attribute MUST
indicate a length value between 6 and 9. indicate a length value between 6 and 9.
+ The <PINPolicy> element MAY be present but the + The <PINPolicy> element MAY be present but the
'PINUsageMode' attribute cannot be set to "Algorithmic". 'PINUsageMode' attribute cannot be set to "Algorithmic".
An example can be found in Figure 1. An example can be found in Figure 2.
10.2. KEYPROV-PIN 10.2. KEYPROV-PIN
Common Name: KEYPROV-PIN Common Name: KEYPROV-PIN
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
URN: urn:ietf:params:xml:ns:keyprov:pskc#pin URN: urn:ietf:params:xml:ns:keyprov:pskc#pin
Algorithm Definition: (this document) Algorithm Definition: (this document)
skipping to change at page 35, line 20 skipping to change at page 34, line 20
Registrant Contact: IESG Registrant Contact: IESG
Profiling: Profiling:
The <Usage> element MAY be present but no attribute of the The <Usage> element MAY be present but no attribute of the
<Usage> element is required. The <ResponseFormat> element MAY <Usage> element is required. The <ResponseFormat> element MAY
be used to indicate the PIN value format. be used to indicate the PIN value format.
The <Secret> element (see Section 4.2) MUST be provided. The <Secret> element (see Section 4.2) MUST be provided.
See the example in Figure 2 See the example in Figure 3
11. XML Schema 11. XML Schema
This section defines the XML schema for PSKC. This section defines the XML schema for PSKC.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc" targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
skipping to change at page 46, line 38 skipping to change at page 45, line 38
versions. versions.
12.6. Key Usage Registry 12.6. Key Usage Registry
IANA is requested to create a registry for key usage. A description IANA is requested to create a registry for key usage. A description
of the 'KeyUsage' element can be found in Section 5. The registry of the 'KeyUsage' element can be found in Section 5. The registry
has the following structure: has the following structure:
Key Usage Token | Specification Key Usage Token | Specification
+---------------------------+------------------------------- +---------------------------+-------------------------------
| OTP | [Section 5 of this document ] | OTP | [Section 5 of this document]
| CR | [Section 5 of this document ] | CR | [Section 5 of this document]
| Encrypt | [Section 5 of this document ] | Encrypt | [Section 5 of this document]
| Integrity | [Section 5 of this document ] | Integrity | [Section 5 of this document]
| Unlock | [Section 5 of this document ] | Unlock | [Section 5 of this document]
| Decrypt | [Section 5 of this document ] | Decrypt | [Section 5 of this document]
| KeyWrap | [Section 5 of this document ] | KeyWrap | [Section 5 of this document]
+---------------------------+------------------------------- +---------------------------+-------------------------------
Expert Review is required to define new key usage tokens. Each Expert Review is required to define new key usage tokens. Each
registration request has to provide a description of the semantic. registration request has to provide a description of the semantic.
Using the same procedure it is possible to depreciate, delete, or Using the same procedure it is possible to depreciate, delete, or
modify existing key usage tokens. modify existing key usage tokens.
13. Security Considerations 13. Security Considerations
The portable key container carries sensitive information (e.g., The portable key container carries sensitive information (e.g.,
skipping to change at page 47, line 40 skipping to change at page 46, line 40
longevity are advised to use AES-256-CBC. In cases where the longevity are advised to use AES-256-CBC. In cases where the
exchange of key encryption keys between the sender and the receiver exchange of key encryption keys between the sender and the receiver
is not possible, asymmetric encryption of the secret key payload may is not possible, asymmetric encryption of the secret key payload may
be employed. Similarly to symmetric key cryptography, the stronger be employed. Similarly to symmetric key cryptography, the stronger
the asymmetric key, the more secure the protection is. the asymmetric key, the more secure the protection is.
If the payload is encrypted with a method that uses one of the If the payload is encrypted with a method that uses one of the
password-based encryption methods provided above, the payload may be password-based encryption methods provided above, the payload may be
subjected to password dictionary attacks to break the encryption subjected to password dictionary attacks to break the encryption
password and recover the information. Standard security best password and recover the information. Standard security best
practices for selection of strong encryption passwords apply practices for selection of strong encryption passwords apply.
[Schneier].
Practical implementations should use PBESalt and PBEIterationCount Practical implementations should use PBESalt and PBEIterationCount
when PBE encryption is used. Different PBESalt value per key when PBE encryption is used. Different PBESalt value per key
container should be used for best protection. container should be used for best protection.
The second approach to protecting the confidentiality of the payload The second approach to protecting the confidentiality of the payload
is based on using transport layer security. The secure channel is based on using transport layer security. The secure channel
established between the source secure perimeter (the provisioning established between the source secure perimeter (the provisioning
server from the example above) and the target perimeter (the device server from the example above) and the target perimeter (the device
attached to the end-user computer) utilizes encryption to transport attached to the end-user computer) utilizes encryption to transport
the messages that travel across. No payload encryption is required the messages that travel across. No payload encryption is required
in this mode. Secure channels that encrypt and digest each message in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature provide an extra measure of security, especially when the signature
of the payload does not encompass the entire payload. of the payload does not encompass the entire payload.
Because of the fact that the plain text payload is protected only by Because of the fact that the plain text payload is protected only by
the transport layer security, practical implementation must ensure the transport layer security, practical implementation must ensure
protection against man-in-the-middle attacks [Schneier]. Validating protection against man-in-the-middle attacks. Validating the secure
the secure channel end-points is critically important for eliminating channel end-points is critically important for eliminating intruders
intruders that may compromise the confidentiality of the payload. that may compromise the confidentiality of the payload.
13.2. Payload integrity 13.2. Payload integrity
The portable symmetric key container provides a mean to guarantee the The portable symmetric key container provides a mean to guarantee the
integrity of the information it contains through digital signatures. integrity of the information it contains through digital signatures.
For best security practices, the digital signature of the container For best security practices, the digital signature of the container
should encompass the entire payload. This provides assurances for should encompass the entire payload. This provides assurances for
the integrity of all attributes. It also allows verification of the the integrity of all attributes. It also allows verification of the
integrity of a given payload even after the container is delivered integrity of a given payload even after the container is delivered
through the communication channel to the target perimeter and channel through the communication channel to the target perimeter and channel
skipping to change at page 50, line 8 skipping to change at page 49, line 8
not encompass the entire payload. not encompass the entire payload.
14. Contributors 14. Contributors
We would like Hannes Tschofenig for his text contributions to this We would like Hannes Tschofenig for his text contributions to this
document. document.
15. Acknowledgements 15. Acknowledgements
The authors of this draft would like to thank the following people The authors of this draft would like to thank the following people
for their contributions and support to make this a better for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea
Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea Doherty, Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and
Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and
especially Robert Philpott. especially Robert Philpott.
We would like to thank Sean Turner for his draft review in January
2009.
This work is based on earlier work by the members of OATH (Initiative This work is based on earlier work by the members of OATH (Initiative
for Open AuTHentication) to specify a format that can be freely for Open AuTHentication), see [OATH], to specify a format that can be
distributed to the technical community. freely distributed to the technical community.
16. References 16. References
16.1. Normative References 16.1. Normative References
[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
August 1960, <http://patft.uspto.gov/netacgi/
nph-Parser?patentnumber=2950048>.
[PKCS1] Kaliski, B., "PKCS #1: RSA Cryptography Specifications
Version 2.0.", RFC 2437, October 1998.
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
Standard", Version 2.0, Standard", Version 2.0,
URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999. URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", [XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002. W3C Recommendation, February 2002.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, URL: http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002. W3C Recommendation, December 2002.
16.2. Informative References 16.2. Informative References
[AlgorithmURIs]
Eastlake, D., "Additional XML Security Uniform Resource
Identifiers", RFC 4051, April 2005.
[CAP] MasterCard International, "Chip Authentication Program [CAP] MasterCard International, "Chip Authentication Program
Functional Architecture", September 2004. Functional Architecture", September 2004.
[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol", Internet "Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/ Draft Informational, URL: http://www.ietf.org/
internet-drafts/draft-ietf-keyprov-dskpp-05.txt, internet-drafts/draft-ietf-keyprov-dskpp-05.txt,
February 2008. February 2008.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, December 2005. Algorithm", RFC 4226, December 2005.
[NIST-SP800-57] [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
National Institute of Standards and Technology, August 1960, <http://patft.uspto.gov/netacgi/
"Recommendation for Key Management - Part I: General nph-Parser?patentnumber=2950048>.
(Revised)", NIST 800-57, URL: http://csrc.nist.gov/
publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf, March 2007.
[OATH] "Initiative for Open AuTHentication", [OATH] "Initiative for Open AuTHentication",
URL: http://www.openauthentication.org. URL: http://www.openauthentication.org.
[OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Bajaj, "OCRA: OATH Challenge Response Algorithm", Internet IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Draft Informational, URL: http://www.ietf.org/ May 2008.
internet-drafts/
draft-mraihi-mutual-oath-hotp-variants-06.txt,
December 2007.
[PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
Syntax Standard", Version 1.0,
URL: http://www.rsasecurity.com/rsalabs/pkcs/.
[Schneier]
Schneier, B., "Secrets and Lies: Digitial Security in a
Networked World", Wiley Computer Publishing, ISBN 0-8493-
8253-7, 2000.
Appendix A. Use Cases Appendix A. Use Cases
This section describes a comprehensive list of use cases that This section describes a comprehensive list of use cases that
inspired the development of this specification. These requirements inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design. were used to derive the primary requirement that drove the design.
These requirements are covered in the next section. These requirements are covered in the next section.
These use cases also help in understanding the applicability of this These use cases also help in understanding the applicability of this
specification to real world situations. specification to real world situations.
A.1. Online Use Cases A.1. Online Use Cases
This section describes the use cases related to provisioning the keys This section describes the use cases related to provisioning the keys
using an online provisioning protocol such as [DSKPP] using an online provisioning protocol such as [DSKPP].
A.1.1. Transport of keys from Server to Cryptographic Module A.1.1. Transport of keys from Server to Cryptographic Module
For example, a mobile device user wants to obtain a symmetric key for For example, a mobile device user wants to obtain a symmetric key for
use with a Cryptographic Module on the device. The Cryptographic use with a Cryptographic Module on the device. The Cryptographic
Module from vendor A initiates the provisioning process against a Module from vendor A initiates the provisioning process against a
provisioning system from vendor B using a standards-based provisioning system from vendor B using a standards-based
provisioning protocol such as [DSKPP]. The provisioning entity provisioning protocol such as [DSKPP]. The provisioning entity
delivers one or more keys in a standard format that can be processed delivers one or more keys in a standard format that can be processed
by the mobile device. by the mobile device.
 End of changes. 98 change blocks. 
357 lines changed or deleted 296 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/