draft-ietf-keyprov-pskc-01.txt   draft-ietf-keyprov-pskc-02.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 24, 2009 VeriSign Expires: August 26, 2009 VeriSign
S. Machani S. Machani
Diversinet Diversinet
January 20, 2009 February 22, 2009
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-01.txt draft-ietf-keyprov-pskc-02.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 24, 2009. This Internet-Draft will expire on August 26, 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 . . . . . . . . . . . . . . . . . . . . . . 11 CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Protection of Keys and Related Data . . . . . . . . . . . . . 18 6. Protection of Keys and Related Data . . . . . . . . . . . . . 19
6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 18 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 20 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 22
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 23 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24
6.4. Transmission of Key Derivation Values . . . . . . . . . . 25 6.4. Transmission of Key Derivation Values . . . . . . . . . . 26
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 27 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 29 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 33 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 33 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. Content-type registration for 'application/pskc+xml' . . . 42 12.1. Content-type registration for 'application/pskc+xml' . . . 43
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 43 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 43 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 44 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 45 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 45 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46
13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 46 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 48
13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 47 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 49
13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 47 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 49
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
16.1. Normative References . . . . . . . . . . . . . . . . . . . 50 16.1. Normative References . . . . . . . . . . . . . . . . . . . 52
16.2. Informative References . . . . . . . . . . . . . . . . . . 50 16.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 52 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 54
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 52 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 54
A.1.1. Transport of keys from Server to Cryptographic A.1.1. Transport of keys from Server to Cryptographic
Module . . . . . . . . . . . . . . . . . . . . . . . . 52 Module . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1.2. Transport of keys from Cryptographic Module to A.1.2. Transport of keys from Cryptographic Module to
Cryptographic Module . . . . . . . . . . . . . . . . . 52 Cryptographic Module . . . . . . . . . . . . . . . . . 54
A.1.3. Transport of keys from Cryptographic Module to A.1.3. Transport of keys from Cryptographic Module to
Server . . . . . . . . . . . . . . . . . . . . . . . . 53 Server . . . . . . . . . . . . . . . . . . . . . . . . 55
A.1.4. Server to server Bulk import/export of keys . . . . . 53 A.1.4. Server to server Bulk import/export of keys . . . . . 55
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 53 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 55
A.2.1. Server to server Bulk import/export of keys . . . . . 53 A.2.1. Server to server Bulk import/export of keys . . . . . 55
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
With increasing use of symmetric key based authentication systems, With increasing use of symmetric key based authentication systems,
such as those 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 and exporting (provisioning) symmetric standard format for importing and exporting (provisioning) symmetric
keys. Traditionally, vendors of authentication servers and service keys. Traditionally, vendors of authentication servers and service
providers have used proprietary formats for importing and exporting providers have used proprietary formats for importing and exporting
these keys into their systems making it hard to use tokens from these keys into their systems making it hard to use tokens from
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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
Figure 1 shows the high-level structure of the PSKC data elements. Figure 1 shows the high-level structure of the PSKC data 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 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
it to describe the structure of the <KeyContainer> element and it's it to describe the structure of the <KeyContainer> element and it's
child elements. child elements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" id="exampleID1" <KeyContainer Version="1.0" 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"
KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage> <Usage>
skipping to change at page 8, line 49 skipping to change at page 8, line 49
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 2: 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.0") 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. As such, it helps to identify a specific key container. As such, it helps to identify a specific key
container. container.
A <KeyContainer> element MUST contain at least one <Device> element. A <KeyContainer> element MUST contain at least one <Device> element.
Multiple <Device> elements can 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
skipping to change at page 9, line 43 skipping to change at page 9, line 43
<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>: In a number of cases access to lower layer device
used to bind keys to the device or to a class of devices. When identifiers, such as a serial number, from a PSKC implementation
loading keys into a device, this identifier can be checked against is difficult or not possible. For this purpose an opaque
information obtained from the device to ensure that the correct identifier, carried in the <DeviceBinding> element, is introduced
device or class of device is being used. that allows to bind keys to the device or to a class of devices.
When loading keys into a device, the value of the <DeviceBinding>
element MUST be checked against information provided to the user
via out-of-band mechanisms. The implementation then ensures that
the correct device or class of device is being used with respect
to the provisioned key.
<StartDate>: and <ExpiryDate>: These two elements indicates the <StartDate>: and <ExpiryDate>: These two elements indicates the
start and end date of a device (such as the one on a payment card, start and end date of a device (such as the one on a payment card,
used when issue numbers are not printed on cards). The date MUST used when issue numbers are not printed on cards). The date MUST
be expressed in UTC form with no timezone component. be expressed in UTC form with no timezone 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. seconds.
Depending on the device type certain child elements of the Depending on the device type certain child elements of the
<DeviceInfo> element are necessary to include in order to uniquely <DeviceInfo> element are necessary to include in order to uniquely
identify a device. This document does not enumerate the different identify a device. This document does not enumerate the different
device types and therefore does not list the elements that are device types and therefore does not list the elements that are
mandatory for each type of device. mandatory for each type of device.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
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 3. 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.0" 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"
KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage> <Usage>
skipping to change at page 16, line 14 skipping to change at page 16, line 14
<StartDate> and <ExpiryDate>: These two elements denote the validity <StartDate> and <ExpiryDate>: These two elements denote the validity
period of a key. It MUST be ensured that the key is only used period of a key. It MUST be ensured that the key is only used
between the start and the end date (inclusive). The value MUST be between the start and the end date (inclusive). The value MUST be
expressed in UTC form, with no time zone component. 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.
<NumberOfTransactions>: The value in this element indicates a
restriction regarding the number of times a key carried within the
PSKC document can be applied. When this element is omitted then
there is no restriction regarding the number of times a key is
used.
<KeyUsage>: The <KeyUsage> element puts constraints on the intended <KeyUsage>: The <KeyUsage> element puts constraints on the intended
usage of the key. The recipient of the PSKC document MUST enforce usage of the key. The recipient of the PSKC document MUST enforce
the key usage. Currently, the following tokens are registered by the key usage. Currently, the following tokens are registered by
this document: 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.
skipping to change at page 16, line 37 skipping to change at page 16, line 43
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.
Unwrap: The key MUST only be used for key unwrap purposes.
Derive: The key MUST only be used with a key derivation function
to derive a new key (see also Section 8.2.4 of [NIST]).
Generate: The key MUST only be used to generate a new key based
on a random number and the previous value of the key (see also
Section 8.1.5.2.1 of[NIST]).
Verify: The key MUST only be used to verify the digest or
signatures ( is the vice verso of Integrity)
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 with 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
skipping to change at page 19, line 6 skipping to change at page 20, line 6
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.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc" <KeyContainer Version="1.0" 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:KeyName>Pre-shared-key</ds:KeyName> <ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1 <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm> </MACAlgorithm>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
skipping to change at page 20, line 5 skipping to change at page 21, line 5
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
Figure 4: 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 MUST When protecting the payload with pre-shared keys implementations MUST
set the name of the specific pre-shared key in the <KeyName> element set the name of the specific pre-shared key in the <KeyName> element
inside the <EncryptionKey> element. inside the <EncryptionKey> element.
Systems implementing PSKC MUST support AES128-CBC (with the URI of For systems implementing PSKC it is RECOMMENDED to support AES-128-
http://www.w3.org/2001/04/xmlenc#aes128-cbc). An example list of CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and
optionally-to-implement encryption algorithms can be found below: KW-AES128 (with the URI of
http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-
AES128 requires that the key to be protected must be a multiple of 8
bytes. Hence, if keys of a different length have to be protected
then the usage of the key wrap algorithm with padding, as described
in [I-D.housley-aes-key-wrap-with-pad] is RECOMMENDED. An example
list of optionally-to-implement encryption algorithms can be found
below:
Algorithm | Uniform Resource Locator (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 AES-128-
a keyed MAC value using the same key as the key encryption key MUST CBC, a keyed MAC value using the same key as the key encryption key
be placed in the <ValueMAC> element of the <Data> element. In this MUST be placed in the <ValueMAC> element of the <Data> element. In
case the MAC algorithm type MUST be set in the <MACAlgorithm> element this case the MAC algorithm type MUST be set in the <MACAlgorithm>
of the <KeyContainer> element. Implementations of PSKC MUST support element of the <KeyContainer> element. Implementations of PSKC MUST
HMAC-SHA1 (with the URI of support 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 | Uniform Resource Locator (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
skipping to change at page 22, line 24 skipping to change at page 23, line 31
This key is also used to calculate MAC value of the secret key This key is also used to calculate MAC value of the secret key
"12345678901234567890". The encryption with algorithm "AES-128-CBC" "12345678901234567890". The encryption with algorithm "AES-128-CBC"
follows the specification defined in [XMLENC]. follows the specification defined in [XMLENC].
<?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"
xmlns:pkcs5= xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1"> Version="1.0">
<EncryptionKey> <EncryptionKey>
<DerivedKey> <DerivedKey>
<CarriedKeyName>Passphrase1</CarriedKeyName> <CarriedKeyName>Passphrase1</CarriedKeyName>
<KeyDerivationMethod <KeyDerivationMethod
Algorithm= Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2"> "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params> <pkcs5:PBKDF2-params>
<pkcs5:Salt> <pkcs5:Salt>
<pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified> <pkcs5:Specified>Ej7/PEpyEpw=</pkcs5:Specified>
</pkcs5:Salt> </pkcs5:Salt>
skipping to change at page 24, line 6 skipping to change at page 25, line 6
When using asymmetric keys to encrypt child elements 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 6 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
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="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001"
Version="1.0">
<EncryptionKey> <EncryptionKey>
<ds:X509Data> <ds:X509Data>
<ds:X509Certificate>miib</ds:X509Certificate> <ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data> </ds:X509Data>
</EncryptionKey> </EncryptionKey>
<MACAlgorithm>
http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm>
<Device> <Device>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<Key KeyAlgorithm= <Key
"urn:ietf:params:xml:ns:keyprov:pskc#hotp" KeyId="MBK000000001"
KeyId="0755225266"> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>AnIssuer</Issuer> <Issuer>Example-Issuer</Issuer>
<Usage> <Usage>
<ResponseFormat Length="8" <ResponseFormat Length="6" Encoding="DECIMAL"/>
Encoding="DECIMAL"/>
</Usage> </Usage>
<Data> <Data>
<Secret> <Secret>
<EncryptedValue Id="ED"> <EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm= Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk= <xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</Device> </Device>
skipping to change at page 25, line 33 skipping to change at page 26, line 47
KeyProfileId='1' would represent a certain set of values (e.g., KeyProfileId='1' would represent a certain set of values (e.g.,
Internet authentication flag set to a specific value). When sending Internet authentication flag set to a specific value). When sending
keys these values would not be transmitted as key attributes but only keys these values would not be transmitted as key attributes but only
referred to via the <KeyProfileId> element set to the specific agreed referred to via the <KeyProfileId> element set to the specific agreed
profile (in this case '1'). When the receiving party receives the profile (in this case '1'). When the receiving party receives the
keys it can then associate all relevant key attributes contained in keys it can then associate all relevant key attributes contained in
the out of band agreed profile with the imported keys. Often this the out of band agreed profile with the imported keys. Often this
methodology is used between the manufacturing and the validation methodology is used between the manufacturing and the validation
service to avoid transmission of mainly the same set of values. service to avoid transmission of mainly the same set of values.
<MasterKeyId> element uniquely references an external master key when The <KeyReference> element contains a reference to an external key
key derivation schemes are used and no specific key is transported when key derivation schemes are used and no specific key is
but only the reference to the master key used to derive a specific transported but only the reference to the external key is used (e.g.,
key and some derivation data (e.g., the PKCS#11 key label). the PKCS#11 key label).
<?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"
KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<Usage> <Usage>
<ResponseFormat Length="8" Encoding="DECIMAL"/> <ResponseFormat Length="8" Encoding="DECIMAL"/>
</Usage> </Usage>
<KeyProfileId>keyProfile1</KeyProfileId> <KeyProfileId>keyProfile1</KeyProfileId>
<MasterKeyId>MasterKeyLabel</MasterKeyId> <KeyReference>MasterKeyLabel</KeyReference>
<Data> <Data>
<Counter> <Counter>
<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>
The key value will be derived using the serialnumber and a pre-shared The key value will be derived using the serialnumber and an external
masterkey identified by 'MasterKeyLabel'. key identified by the label 'MasterKeyLabel'.
Figure 7: Example of a PSKC Document transmitting a HOTP key via key Figure 7: Example of a PSKC Document transmitting a HOTP key via key
derivation values 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].
skipping to change at page 35, line 42 skipping to change at page 36, line 42
<xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType" <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Device" type="pskc:DeviceType" <xs:element name="Device" type="pskc:DeviceType"
minOccurs="1" maxOccurs="unbounded"/> minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="Signature" type="ds:SignatureType" <xs:element name="Signature" type="ds:SignatureType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0" type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" type="xs:unsignedInt" <xs:attribute name="Version" type="pskc:VersionType"
use="required"/> use="required"/>
<xs:attribute name="id" type="xs:ID" use="optional"/> <xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="KeyType"> <xs:complexType name="KeyType">
<xs:sequence> <xs:sequence>
<xs:element name="Issuer" <xs:element name="Issuer"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="Usage" <xs:element name="Usage"
type="pskc:UsageType"/> type="pskc:UsageType"/>
<xs:element name="KeyProfileId" <xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="MasterKeyId" <xs:element name="KeyReference"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName" <xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="Data" type="pskc:KeyDataType" <xs:element name="Data" type="pskc:KeyDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="UserId" type="xs:string" <xs:element name="UserId" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Policy" <xs:element name="Policy"
type="pskc:PolicyType" minOccurs="0"/> type="pskc:PolicyType" minOccurs="0"/>
<xs:element name="Extensions" <xs:element name="Extensions"
skipping to change at page 36, line 39 skipping to change at page 37, line 44
<xs:complexType name="PolicyType"> <xs:complexType name="PolicyType">
<xs:sequence> <xs:sequence>
<xs:element name="StartDate" <xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate" <xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/> type="xs:dateTime" minOccurs="0"/>
<xs:element name="PINPolicy" <xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/> type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="KeyUsage" <xs:element name="KeyUsage"
type="pskc:KeyUsageType" minOccurs="0"/> type="pskc:KeyUsageType" minOccurs="0"/>
<xs:element name="NumberOfTransactions"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other" <xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="KeyDataType"> <xs:complexType name="KeyDataType">
<xs:sequence> <xs:sequence>
<xs:element name="Secret" <xs:element name="Secret"
type="pskc:binaryDataType" type="pskc:binaryDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="Counter" <xs:element name="Counter"
type="pskc:longDataType" type="pskc:longDataType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="Time" <xs:element name="Time"
type="pskc:intDataType" type="pskc:intDataType"
skipping to change at page 45, line 45 skipping to change at page 46, line 45
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]
| Unwrap | [Section 5 of this document]
| Derive | [Section 5 of this document]
| Generate | [Section 5 of this document]
| Verify | [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.,
cryptographic keys) and may be transported across the boundaries of cryptographic keys) and may be transported across the boundaries of
one secure perimeter to another. For example, a container residing one secure perimeter to another. For example, a container residing
within the secure perimeter of a back-end provisioning server in a within the secure perimeter of a back-end provisioning server in a
secure room may be transported across the internet to an end-user secure room may be transported across the internet to an end-user
skipping to change at page 49, line 14 skipping to change at page 51, line 14
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 feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea Siddhart Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Andrea
Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner and Doherty, 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 We would like to thank Sean Turner for his draft review in January
2009. 2009. We would also like to thank Anders Rundgren for triggering the
discussion regarding to the selection of encryption algorithms (KW-
AES-128 vs. AES-128-CBC) and his input on the keyed message digest
computation.
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), see [OATH], to specify a format that can be for Open AuTHentication), see [OATH], to specify a format that can be
freely distributed to the technical community. freely distributed to the technical community.
16. References 16. References
16.1. Normative References 16.1. Normative References
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
skipping to change at page 50, line 52 skipping to change at page 52, line 52
[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.
[I-D.housley-aes-key-wrap-with-pad]
Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap Algorithm with Padding",
draft-housley-aes-key-wrap-with-pad-00 (work in progress),
January 2009.
[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048, [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
August 1960, <http://patft.uspto.gov/netacgi/ August 1960, <http://patft.uspto.gov/netacgi/
nph-Parser?patentnumber=2950048>. nph-Parser?patentnumber=2950048>.
[NIST] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"NIST Special Publication 800-57, Recommendation for Key
Management - Part 1: General (Revised)", NIST Special
Publication 800-57, March 2007.
[OATH] "Initiative for Open AuTHentication", [OATH] "Initiative for Open AuTHentication",
URL: http://www.openauthentication.org. URL: http://www.openauthentication.org.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
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
 End of changes. 55 change blocks. 
108 lines changed or deleted 177 lines changed or added

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