draft-ietf-keyprov-pskc-05.txt   draft-ietf-keyprov-pskc-06.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 9, 2010 VeriSign Expires: November 15, 2010 VeriSign
S. Machani S. Machani
Diversinet Diversinet
January 5, 2010 May 14, 2010
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-05 draft-ietf-keyprov-pskc-06
Abstract
This document specifies a symmetric key format for transport and
provisioning of symmetric keys to different types of crypto modules.
For example, One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. A standard key
transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.
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 45
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 9, 2010. This Internet-Draft will expire on November 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies a symmetric key format for transport and described in the BSD License.
provisioning of symmetric keys to different types of crypto modules.
For example, One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. A standard key
transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4
1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4
1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5 1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 50 skipping to change at page 3, line 4
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29
6.4. Padding of Encrypted Values for Non-Padded Encryption 6.4. Padding of Encrypted Values for Non-Padded Encryption
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12.1. Content-type registration for 'application/pskc+xml' . . . 46 12.1. Content-type registration for 'application/pskc+xml' . . . 46
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49
13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13.1. Payload Confidentiality . . . . . . . . . . . . . . . . . 51 13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 51
13.2. Payload Integrity . . . . . . . . . . . . . . . . . . . . 52 13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 52
13.3. Payload Authenticity . . . . . . . . . . . . . . . . . . . 52 13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 52
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. Normative References . . . . . . . . . . . . . . . . . . . 55 16.1. Normative References . . . . . . . . . . . . . . . . . . . 55
16.2. Informative References . . . . . . . . . . . . . . . . . . 55 16.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 58
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 58
A.1.1. Transport of keys from Server to Cryptographic A.1.1. Transport of keys from Server to Cryptographic
Module . . . . . . . . . . . . . . . . . . . . . . . . 57 Module . . . . . . . . . . . . . . . . . . . . . . . . 58
A.1.2. Transport of keys from Cryptographic Module to A.1.2. Transport of keys from Cryptographic Module to
Cryptographic Module . . . . . . . . . . . . . . . . . 57 Cryptographic Module . . . . . . . . . . . . . . . . . 58
A.1.3. Transport of keys from Cryptographic Module to A.1.3. Transport of keys from Cryptographic Module to
Server . . . . . . . . . . . . . . . . . . . . . . . . 58 Server . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.4. Server to server Bulk import/export of keys . . . . . 58 A.1.4. Server to server Bulk import/export of keys . . . . . 59
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 59
A.2.1. Server to server Bulk import/export of keys . . . . . 58 A.2.1. Server to server Bulk import/export of keys . . . . . 59
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
With increasing use of symmetric key based systems, such as With increasing use of symmetric key based systems, such as
encryption of data at rest, or systems used for strong encryption of data at rest, or systems used for strong
authentication, such as those based on one-time-password (OTP) and authentication, such as those based on one-time-password (OTP) and
challenge response (CR) mechanisms, there is a need for vendor challenge response (CR) mechanisms, there is a need for vendor
interoperability and a standard format for importing and exporting interoperability and a standard format for importing and exporting
(provisioning) symmetric keys. For instance, traditionally, vendors (provisioning) symmetric keys. For instance, traditionally, vendors
of authentication servers and service providers have used proprietary of authentication servers and service providers have used proprietary
formats for importing and exporting these keys into their systems, formats for importing and exporting these keys into their systems,
thus making it hard to use tokens from two different vendors. thus making it hard to use tokens from two different vendors.
This document defines a standardized XML-based key container, called This document defines a standardized XML-based key container, called
Portable Symmetric Key Container (PSKC), for transporting symmetric Portable Symmetric Key Container (PSKC), for transporting symmetric
keys and key related meta data. The document also specifies the keys and key related meta data. The document also specifies the
information elements that are required when the symmetric key is information elements that are required when the symmetric key is
utilized for specific purposes, such as the initial counter in the utilized for specific purposes, such as the initial counter in the
MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also HMAC-Based One Time Password (HOTP) [HOTP] algorithm. It also
requests the creation of an IANA registry for algorithm profiles requests the creation of an IANA registry for algorithm profiles
where algorithms, their meta-data and PSKC transmission profile can where algorithms, their meta-data and PSKC transmission profile can
be recorded for centralised standardised reference. be recorded for centralised standardised reference.
1.1. Key Words 1.1. Key Words
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].
skipping to change at page 4, line 47 skipping to change at page 4, line 47
1.3. Namespace Identifiers 1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers [RFC3986] to identify This document uses Uniform Resource Identifiers [RFC3986] to identify
resources, algorithms, and semantics. resources, algorithms, and semantics.
1.3.1. Defined Identifiers 1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" "urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined herein References to qualified elements in the PSKC schema defined in this
use the prefix "pskc". specification and used in the example use the prefix "pskc" (defined
as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc") . It is
RECOMMENDED to use this namespace in implementations.
1.3.2. Referenced Identifiers 1.3.2. Referenced Identifiers
The PSKC syntax presented in this document relies on algorithm The PSKC syntax presented in this document relies on algorithm
identifiers and elements defined in the XML Signature [XMLDSIG] identifiers and elements defined in the XML Signature [XMLDSIG]
namespace: namespace:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the References to the XML Signature namespace are represented by the
skipping to change at page 7, line 11 skipping to change at page 7, line 11
**mandatory** XML elements and attributes. Optional elements and **mandatory** XML elements and attributes. Optional elements and
attributes are not explicitly indicated, i.e., if it does not say attributes are not explicitly indicated, i.e., if it does not say
mandatory it is optional. 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 a 1. KeyContainer entity - representing the container that carries a
number of KeyPackages number of KeyPackages. A valid container MUST carry at least 1
KeyPackage.
2. KeyPackage entity - representing the package of at most one key 2. KeyPackage entity - representing the package of at most one key
and its related provisioning endpoint or current usage endpoint, and its related provisioning endpoint or current usage endpoint,
such as a physical or virtual device and a specific CryptoModule such as a physical or virtual device and a specific CryptoModule
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. CryptoModuleInfo entity - representing the information about the 4. CryptoModuleInfo entity - representing the information about the
CryptoModule where the keys reside or are provisioned to CryptoModule where the keys reside or are provisioned to
skipping to change at page 10, line 47 skipping to change at page 10, line 47
<Counter>: This element contains the event counter for event <Counter>: This element contains the event counter for event
based OTP algorithms. based OTP algorithms.
<Time>: This element contains the time for time based OTP <Time>: This element contains the time for time based OTP
algorithms. (If time interval is used, this element carries algorithms. (If time interval is used, this element carries
the number of time intervals passed from a specific start the number of time intervals passed from a specific start
point, normally algorithm dependent). point, normally algorithm dependent).
<TimeInterval>: This element carries the time interval value for <TimeInterval>: This element carries the time interval value for
time based OTP algorithms. time based OTP algorithms in seconds (typical value for this
would be 30 indicating a time interval of 30 seconds).
<TimeDrift>: This element contains the device clock drift value <TimeDrift>: This element contains the device clock drift value
for time-based OTP algorithms. The value indicates the number for time-based OTP algorithms. The integer value (positive or
of seconds that the device clock may drift each day. negative drift) that indicates the number of time intervals
that a validation server has established the device clock
drifted after the last succssful authentication. So for
example if the last successful authentication established a
device time value of 8 intervals from a specific start date but
the validation server determines the time value at 9 intervals,
the server SHOULD record the drift as -1.
All the elements listed above (and those defined in the future) All the elements listed above (and those defined in the future)
obey a simple structure in that they MUST support child elements obey a simple structure in that they MUST support child elements
to convey the data value in either plaintext or encrypted format: to convey the data value in either plaintext or encrypted format:
Plaintext: The <PlainValue> element carries plaintext value that Plaintext: The <PlainValue> element carries plaintext value that
is typed, for example to xs:integer. is typed, for example to xs:integer.
Encrypted: The <EncryptedValue> element carries encrypted value. Encrypted: The <EncryptedValue> element carries encrypted value.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
elements MUST uniquely identify the device. For example, for elements MUST uniquely identify the device. For example, for
hardware tokens the combination of <SerialNo> and <Manufacturer> hardware tokens the combination of <SerialNo> and <Manufacturer>
elements uniquely identifies a device but the <SerialNo> element elements uniquely identifies a device but the <SerialNo> element
alone is insufficient since two different token manufacturers might alone is insufficient since two different token manufacturers might
issue devices with the same serial number (similar to the Issuer issue devices with the same serial number (similar to the Issuer
Distinguished Name and serial number of a certificate). Distinguished Name and serial number of a 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. Values for Manufacturer SHOULD be taken from [OATHMAN]
<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.
skipping to change at page 13, line 32 skipping to change at page 13, line 32
request using a device identifier, e.g., an International Mobile request using a device identifier, e.g., an International Mobile
Equipment Identity (IMEI) for the phone, or an identifier for a Equipment Identity (IMEI) for the phone, or an identifier for a
class of identifiers, e.g., those for which the keys are protected class of identifiers, e.g., those for which the keys are protected
by a Trusted Platform Module (TPM). by a Trusted Platform Module (TPM).
<StartDate>: and <ExpiryDate>: These two elements indicate the start <StartDate>: and <ExpiryDate>: These two elements indicate the start
and end date of a device (such as the one on a payment card, used 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 be when issue numbers are not printed on cards). The date MUST be
expressed in UTC form with no timezone component. Implementations expressed in UTC form with no timezone component. Implementations
SHOULD NOT rely on time resolution finer than milliseconds and SHOULD NOT rely on time resolution finer than milliseconds and
MUST NOT generate time instants that specify leap seconds. MUST NOT generate time instants that specify leap seconds. Keys
that reside on the device SHOULD only be used when the current
date is after the <StartDate> and before the <ExpiryDate>. Note
that usage enforcement of the keys with respective to the dates
MAY only happen on the validation server as some devices such as
smart cards do not have an internal clock. Systems thus SHOULD
NOT rely upon the device to enforce key usage date restrictions.
Depending on the device type certain child elements of the Depending on the device type certain child elements of the
<DeviceInfo> element MUST be included in order to uniquely identify a <DeviceInfo> element MUST be included in order to uniquely identify a
device. This document does not enumerate the different device types device. This document does not enumerate the different device types
and therefore does not list the elements that are mandatory for each and therefore does not list the elements that are mandatory for each
type of device. type of device.
4.2.2. <CryptoModuleInfo> Element: CryptoModule Identification 4.2.2. <CryptoModuleInfo> Element: CryptoModule Identification
The <CryptoModuleInfo> element identifies the cryptographic module to The <CryptoModuleInfo> element identifies the cryptographic module to
skipping to change at page 14, line 47 skipping to change at page 15, line 4
'Encoding': This attribute, which MUST be included, defines the 'Encoding': This attribute, which MUST be included, defines the
encoding of the challenge accepted by the device and MUST be encoding of the challenge accepted by the device and MUST be
one of the following values: one of the following values:
DECIMAL Only numerical digits DECIMAL Only numerical digits
HEXADECIMAL Hexadecimal response HEXADECIMAL Hexadecimal response
ALPHANUMERIC All letters and numbers (case sensitive) ALPHANUMERIC All letters and numbers (case sensitive)
BASE64 Base 64 encoded as defined in Section 4 of [RFC4648].
BASE64 Base 64 encoded
BINARY Binary data BINARY Binary data
'CheckDigit': This attribute indicates whether a device needs to 'CheckDigit': This attribute indicates whether a device needs to
check the appended Luhn check digit, as defined in [LUHN], check the appended Luhn check digit, as defined in
contained in a challenge. This is only valid if the 'Encoding' [ISOIEC7812], contained in a challenge. This is only valid if
attribute is 'DECIMAL'. A value of TRUE indicates that the the 'Encoding' attribute is 'DECIMAL'. A value of TRUE
device will check the appended Luhn check digit in a provided indicates that the device will check the appended Luhn check
challenge. A value of FALSE indicates that the device will not digit in a provided challenge. A value of FALSE indicates that
check the appended Luhn check digit in the challenge. the device will not check the appended Luhn check digit in the
challenge.
'Min': This attribute defines the minimum size of the challenge 'Min': This attribute defines the minimum size of the challenge
accepted by the device for CR mode and MUST be included. If accepted by the device for CR mode and MUST be included. If
the 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or the 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the minimum number of 'ALPHANUMERIC' this value indicates the minimum number of
digits/characters. If the 'Encoding' attribute is 'BASE64' or digits/characters. If the 'Encoding' attribute is 'BASE64' or
'BINARY', this value indicates the minimum number of bytes of 'BINARY', this value indicates the minimum number of bytes of
the unencoded value. the unencoded value.
'Max': This attribute defines the maximum size of the challenge 'Max': This attribute defines the maximum size of the challenge
skipping to change at page 15, line 45 skipping to change at page 15, line 48
this element contains the format of the PIN itself (e.g., DECIMAL, this element contains the format of the PIN itself (e.g., DECIMAL,
length 4 for a 4 digit PIN). The following attributes are length 4 for a 4 digit PIN). The following attributes are
defined: defined:
'Encoding': This attribute defines the encoding of the response 'Encoding': This attribute defines the encoding of the response
generated by the device, it MUST be included and MUST be one of generated by the device, it MUST be included and MUST be one of
the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,
BASE64, or BINARY. BASE64, or BINARY.
'CheckDigit': This attribute indicates whether the device needs 'CheckDigit': This attribute indicates whether the device needs
to append a Luhn check digit, as defined in [LUHN], to the to append a Luhn check digit, as defined in [ISOIEC7812], to
response. This is only valid if the 'Encoding' attribute is the response. This is only valid if the 'Encoding' attribute
'DECIMAL'. If the value is TRUE then the device will append a is 'DECIMAL'. If the value is TRUE then the device will append
Luhn check digit to the response. If the value is FALSE, then a Luhn check digit to the response. If the value is FALSE,
the device will not append a Luhn check digit to the response. then the device will not append a Luhn check digit to the
response.
'Length': This attribute defines the length of the response 'Length': This attribute defines the length of the response
generated by the device and MUST be included. If the generated by the device and MUST be included. If the
'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or 'Encoding' attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the number of digits/ 'ALPHANUMERIC' this value indicates the number of digits/
characters. If the 'Encoding' attribute is 'BASE64' or characters. If the 'Encoding' attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the 'BINARY', this value indicates the number of bytes of the
unencoded value. unencoded value.
4.3. Transmission of Key Derivation Values 4.3. Transmission of Key Derivation Values
skipping to change at page 21, line 30 skipping to change at page 21, line 30
Append: This value indicates that the PIN is appended to the Append: This value indicates that the PIN is appended to the
algorithm response hence it MUST be checked by the party algorithm response hence it MUST be checked by the party
validating the response. validating the response.
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 may be entered wrongly before it MUST NOT be of times the PIN may be entered wrongly before it MUST NOT be
possible to use the key anymore. possible to use the key anymore (typical reasonable values are
in the positive integer range of at least 2 and no more than
10).
'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 the associated key. It MUST NOT be that can be set to protect the associated key. It MUST NOT be
possible to set a PIN shorter than this value. If the possible to set a PIN shorter than this value. If the
'PINFormat' attribute is 'DECIMAL', 'HEXADECIMAL' or 'PINFormat' attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the number of digits/ 'ALPHANUMERIC' this value indicates the number of digits/
characters. If the 'PINFormat' attribute is 'BASE64' or characters. If the 'PINFormat' attribute is 'BASE64' or
'BINARY', this value indicates the number of bytes of the 'BINARY', this value indicates the number of bytes of the
unencoded value. unencoded value.
skipping to change at page 29, line 8 skipping to change at page 29, line 8
</pskc:Key> </pskc:Key>
</pskc:KeyPackage> </pskc:KeyPackage>
</pskc:KeyContainer> </pskc:KeyContainer>
Figure 7: Example of a PSKC Document using Encryption based on Figure 7: 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 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 8 the algorithm is set to the example shown in Figure 8 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 <KeyContainer
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
skipping to change at page 36, line 12 skipping to change at page 36, line 12
Figure 10: Bulk Provisioning Example Figure 10: 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 'Version' attribute, as described in Section 4,
Section 4, and rules for extensibililty are defined in Section 12. and rules for extensibililty are defined in Section 12.
New XML Elements: The usage of the XML schema and the available New XML Elements: The usage of the XML schema and the available
extension points allows new XML elements to be added. Depending extension points allows new XML elements to be added. Depending
of type of XML elements different ways for extensibility are of type of XML elements different ways for extensibility are
offered. In some places the <Extensions> element can be used and offered. In some places the <Extensions> element can be used and
elsewhere the "<xs:any namespace="##other" processContents="lax" elsewhere the "<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>" XML extension point is minOccurs="0" maxOccurs="unbounded"/>" XML extension point is
utilized. utilized.
New XML Attributes: The XML schema allows new XML attributes to be New XML Attributes: The XML schema allows new XML attributes to be
skipping to change at page 37, line 13 skipping to change at page 37, line 13
described in Section 12. described in Section 12.
10. PSKC Algorithm Profile 10. PSKC Algorithm Profile
10.1. HOTP 10.1. HOTP
Common Name: HOTP Common Name: HOTP
Class: OTP Class: OTP
URN: urn:ietf:params:xml:ns:keyprov:pskc#hotp URI: urn:ietf:params:xml:ns:keyprov:pskc#hotp
Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt Algorithm Definition: [HOTP]
Identifier Definition: (this RFC) Identifier Definition: (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Deprectaed: FALSE
Profiling: Profiling:
The <KeyPackage> element MUST be present and the The <KeyPackage> element MUST be present and the
<ResponseFormat> element, which is a child element of the <ResponseFormat> element, which is a child element of the
<AlgorithmParameters> element, MUST be used to indicate the OTP <AlgorithmParameters> element, MUST be used to indicate the OTP
length and the value format. length and the value format.
The <Counter> element (see Section 4.1) MUST be provided as The <Counter> element (see Section 4.1) MUST be provided as
meta-data for the key. meta-data for the key.
skipping to change at page 37, line 47 skipping to change at page 38, line 4
+ 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 (inclusive). indicate a length value between 6 and 9 (inclusive).
+ 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 3. An example can be found in Figure 3.
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 URI: urn:ietf:params:xml:ns:keyprov:pskc#pin
Algorithm Definition: (this document) Algorithm Definition: (this document)
Identifier Definition (this document) Identifier Definition (this document)
Registrant Contact: IESG Registrant Contact: IESG
Deprectaed: FALSE
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.1) MUST be provided. The <Secret> element (see Section 4.1) MUST be provided.
See the example in Figure 5 See the example in Figure 5
skipping to change at page 46, line 17 skipping to change at page 46, line 17
12.1. Content-type registration for 'application/pskc+xml' 12.1. Content-type registration for 'application/pskc+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [RFC4288] and guidelines in according to the procedures of RFC 4288 [RFC4288] and guidelines in
RFC 3023 [RFC3023]. RFC 3023 [RFC3023].
MIME media type name: application MIME media type name: application
MIME subtype name: pskc+xml MIME subtype name: pskc+xml
Mandatory parameters: none Required parameters: There is no required parameter.
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [RFC3023], Section 3.2. 3023 [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry PSKC Security considerations: Please refer to Section 13 of RFCXXXX [NOTE
protocol payloads. TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of
this specification.]
Interoperability considerations: None Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.] replace XXXX with the RFC number of this specification.]
Applications which use this media type: This MIME type is being used Applications which use this media type: This MIME type is being used
as a symmetric key container format for transport and provisioning as a symmetric key container format for transport and provisioning
of symmetric keys (One Time Password (OTP) shared secrets or of symmetric keys (One Time Password (OTP) shared secrets or
symmetric cryptographic keys) to different types of strong symmetric cryptographic keys) to different types of strong
skipping to change at page 47, line 5 skipping to change at page 47, line 5
systems. systems.
Additional information: Additional information:
Magic Number: None Magic Number: None
File Extension: .pskcxml File Extension: .pskcxml
Macintosh file type code: 'TEXT' Macintosh file type code: 'TEXT'
Personal and email address for further information: Philip Hoyer, Personal and email address to contact for further information:
Philip.Hoyer@actividentity.com Philip Hoyer, Philip.Hoyer@actividentity.com
Intended usage: LIMITED USE Intended usage: LIMITED USE
Restrictions on usage: None
Author: This specification is a work item of the IETF KEYPROV Author: This specification is a work item of the IETF KEYPROV
working group, with mailing list address <keyprov@ietf.org>. working group, with mailing list address <keyprov@ietf.org>.
Change controller: The IESG <iesg@ietf.org> Change controller: The IESG <iesg@ietf.org>
12.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
skipping to change at page 48, line 42 skipping to change at page 48, line 42
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Common Name: The name by which the PSKC algorithm profile is Common Name: The name by which the PSKC algorithm profile is
generally referred. generally referred.
Class: The type of PSKC algorithm profile registry entry being Class: The type of PSKC algorithm profile registry entry being
created, such as encryption, Message Authentication Code (MAC), created, such as encryption, Message Authentication Code (MAC),
One Time Password (OTP), Digest. One Time Password (OTP), Digest.
URN: The URN to be used to identify the profile. URI: The URI to be used to identify the profile.
Identifier Definition: IANA will be asked to add a pointer to the Identifier Definition: IANA will be asked to add a pointer to the
specification containing information about the PSKC algorithm specification containing information about the PSKC algorithm
profile registration. profile registration.
Algorithm Definition: A reference to the stable document in which Algorithm Definition: A reference to the stable document in which
the algorithm being used with the PSKC is defined. the algorithm being used with the PSKC is defined.
Registrant Contact: Contact information about the party submitting Registrant Contact: Contact information about the party submitting
the registration request. the registration request.
Deprecated: TRUE if based on expert approval this entry has been
deprecated and SHOULD not be used in any new implementations.
Otherwise FALSE.
PSKC Profiling: Information about PSKC XML elements and attributes PSKC Profiling: Information about PSKC XML elements and attributes
being used (or not used) with this specific profile of PSKC. being used (or not used) with this specific profile of PSKC.
PSKC algorithm profile identifier registrations are to be subject to PSKC algorithm profile identifier registrations are to be subject to
Expert Review as per RFC 5226 [RFC5226]. Updates can be provided Expert Review as per RFC 5226 [RFC5226]. Updates can be provided
based on expert approval only. Based on expert approval, it is based on expert approval only. Based on expert approval, it is
possible to mark entries as "deprecated". A designated expert will possible to mark entries as "deprecated". A designated expert will
be appointed by the IESG. be appointed by the IESG.
IANA is asked to add an initial value to the registry based on the IANA is asked to add an initial value to the registry based on the
skipping to change at page 50, line 4 skipping to change at page 50, line 19
| Encrypt | [Section 5 of this document] | Encrypt | [Section 5 of this document]
| Integrity | [Section 5 of this document] | Integrity | [Section 5 of this document]
| Verify | [Section 5 of this document] | Verify | [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] | Unwrap | [Section 5 of this document]
| Derive | [Section 5 of this document] | Derive | [Section 5 of this document]
| Generate | [Section 5 of this document] | Generate | [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 deprecate, delete, or Using the same procedure it is possible to deprecate, delete, or
modify existing key usage tokens. A designated expert will be modify existing key usage tokens. A designated expert will be
appointed by the IESG. appointed by the IESG.
13. Security Considerations 13. Security Considerations
The portable key container carries sensitive information (e.g., The portable symmetric key container (PSKC) carries sensitive
cryptographic keys) and may be transported across the boundaries of information (e.g., cryptographic keys) and may be transported across
one secure perimeter to another. For example, a container residing the boundaries of one secure perimeter to another. For example, a
within the secure perimeter of a back-end provisioning server in a container residing within the secure perimeter of a back-end
secure room may be transported across the internet to an end-user provisioning server in a secure room may be transported across the
device attached to a personal computer. This means that special care internet to an end-user device attached to a personal computer. This
must be taken to ensure the confidentiality, integrity, and means that special care MUST be taken to ensure the confidentiality,
authenticity of the information contained within. integrity, and authenticity of the information contained within.
13.1. Payload Confidentiality 13.1. PSKC Confidentiality
By design, the container allows two main approaches to guaranteeing By design, the container allows two main approaches to guaranteeing
the confidentiality of the information it contains while transported. the confidentiality of the information it contains while transported.
First, the container key data payload may be encrypted. First, the container key data payload may be encrypted.
In this case no transport layer security is required. However, In this case no transport layer security is required. However,
standard security best practices apply when selecting the strength of standard security best practices apply when selecting the strength of
the cryptographic algorithm for payload encryption. Symmetric the cryptographic algorithm for key data payload encryption.
cryptographic cipher should be used - the longer the cryptographic Symmetric cryptographic cipher SHOULD be used - the longer the
key, the stronger the protection. Please see Section 6.1 for cryptographic key, the stronger the protection. Please see
recommendations of payload protection using symmetric cryptographic Section 6.1 for recommendations of key data payload protection using
ciphers. In cases where the exchange of key encryption keys between symmetric cryptographic ciphers. In cases where the exchange of key
the sender and the receiver is not possible, asymmetric encryption of encryption keys between the sender and the receiver is not possible,
the secret key payload may be employed, see Section 6.3 . Similarly asymmetric encryption of the key data payload may be employed, see
to symmetric key cryptography, the stronger the asymmetric key, the Section 6.3 . Similarly to symmetric key cryptography, the stronger
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 key data payload is encrypted with a method that uses one of
password-based encryption methods provided above, the payload may be the password-based encryption methods (PBE methods) detailed in
subjected to password dictionary attacks to break the encryption Section 6.2, the key data payload may be subjected to password
password and recover the information. Standard security best dictionary attacks to break the encryption password and recover the
practices for selection of strong encryption passwords apply. information. Standard security best practices for selection of
strong encryption passwords apply.
Practical implementations should use PBESalt and PBEIterationCount Additionally, it is strongly RECOMMENDED that practical
when PBE encryption is used. Different PBESalt value per key implementations use PBESalt and PBEIterationCount when PBE encryption
container should be used for best protection. is used. A different PBESalt value per PSKC 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 key data
is based on using transport layer security. The secure channel payload is based on using transport layer security. The secure
established between the source secure perimeter (the provisioning channel established between the source secure perimeter (the
server from the example above) and the target perimeter (the device provisioning server from the example above) and the target perimeter
attached to the end-user computer) utilizes encryption to transport (the device attached to the end-user computer) utilizes encryption to
the messages that travel across. No payload encryption is required transport the messages that travel across. No key data payload
in this mode. Secure channels that encrypt and digest each message encryption is required in this mode. Secure channels that encrypt
provide an extra measure of security, especially when the signature and digest each message provide an extra measure of security.
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 PSKC is protected only by the
the transport layer security, practical implementation must ensure transport layer security, practical implementation MUST ensure
protection against man-in-the-middle attacks. Validating the secure protection against man-in-the-middle attacks. Authenticating the
channel end-points is critically important for eliminating intruders secure channel end-points is critically important for eliminating
that may compromise the confidentiality of the payload. intruders that may compromise the confidentiality of the PSKC.
13.2. Payload Integrity 13.2. PSKC Integrity
The portable symmetric key container provides a mean to guarantee the The PSKC provides a mean to guarantee the integrity of the
integrity of the information it contains through digital signatures. information it contains through digital signatures. It is
For best security practices, the digital signature of the container RECOMMENDED that for best security practices, the digital signature
should encompass the entire payload. This provides assurances for of the container encompasses the entire PSKC.This provides assurances
the integrity of all attributes. It also allows verification of the for the integrity of all attributes. It also allows verification of
integrity of a given payload even after the container is delivered the integrity of a given PSKC 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
message integrity check is no longer possible. message integrity check is no longer possible.
13.3. Payload Authenticity 13.3. PSKC Authenticity
The digital signature of the payload is the primary way of showing The digital signature of the PSKC is the primary way of showing its
its authenticity. The recipient of the container may use the public authenticity. The recipient of the container SHOULD use the public
key associated with the signature to assert the authenticity of the key associated with the signature to assert the authenticity of the
sender by tracing it back to a preloaded public key or certificate. sender by tracing it back to a preloaded public key or certificate.
Note that the digital signature of the payload can be checked even Note that the digital signature of the PSKC can be checked even after
after the container has been delivered through the secure channel of the container has been delivered through the secure channel of
communication. communication.
A weaker payload authenticity guarantee may be provided by the A weaker payload authenticity guarantee may be provided by the
transport layer if it is configured to digest each message it transport layer if it is configured to digest each message it
transports. However, no authenticity verification is possible once transports. However, no authenticity verification is possible once
the container is delivered at the recipient end. This approach may the container is delivered at the recipient end. This approach may
be useful in cases where the digital signature of the container does be useful in cases where the digital signature of the container does
not encompass the entire payload. not encompass the entire PSKC.
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 feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson,
skipping to change at page 55, line 9 skipping to change at page 55, line 9
computation. 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
[AESKWPAD]
Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", March 2009, <http:
//www.ietf.org/internet-drafts/
draft-housley-aes-key-wrap-with-pad-02.txt>.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, December 2005.
[ISOIEC7812]
ISO, "ISO/IEC 7812-1:2006 Identification cards --
Identification of issuers -- Part 1: Numbering system",
October 2006, <http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)",
April 2009,
<http://www.openauthentication.org/oath-id/prefixes/>.
[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.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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.
[XMLENC11] [XMLENC11]
Eastlake, D., "XML Encryption Syntax and Processing Eastlake, D., "XML Encryption Syntax and Processing
Version 1.1.", Version 1.1.",
URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730, URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730,
W3C Recommendation, July 2009. W3C Recommendation, July 2009.
16.2. Informative References 16.2. Informative References
[AESKWPAD]
Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", March 2009, <http:
//www.ietf.org/internet-drafts/
draft-housley-aes-key-wrap-with-pad-02.txt>.
[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-07.txt, internet-drafts/draft-ietf-keyprov-dskpp-07.txt,
February 2009. February 2009.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, December 2005.
[LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048,
August 1960, <http://patft.uspto.gov/netacgi/
nph-Parser?patentnumber=2950048>.
[NIST800-57] [NIST800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"NIST Special Publication 800-57, Recommendation for Key "NIST Special Publication 800-57, Recommendation for Key
Management - Part 1: General (Revised)", NIST Special Management - Part 1: General (Revised)", NIST Special
Publication 800-57, March 2007. 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.
[PSKC-ALGORITHM-PROFILES] [PSKC-ALGORITHM-PROFILES]
Hoyer, P., Pei, M., Machani, S., and A. Doherty, Hoyer, P., Pei, M., Machani, S., and A. Doherty,
"Additional Portable Symmetric Key Container (PSKC) "Additional Portable Symmetric Key Container (PSKC)
Algorithm Profiles", Internet Draft Informational, URL: Algorithm Profiles", Internet Draft Informational, URL:
http://tools.ietf.org/html/ http://www.ietf.org/id/
draft-hoyer-keyprov-pskc-algorithm-profiles-00, draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt,
December 2008. May 2010.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986, Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005. January 2005.
[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.
[XMLNS] "Namespaces in XML", W3C Recommendation , [XMLNS] "Namespaces in XML", W3C Recommendation ,
 End of changes. 58 change blocks. 
138 lines changed or deleted 185 lines changed or added

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