draft-ietf-keyprov-pskc-09.txt   rfc6030.txt 
keyprov P. Hoyer Internet Engineering Task Force (IETF) P. Hoyer
Internet-Draft ActivIdentity Request for Comments: 6030 ActivIdentity
Intended status: Standards Track M. Pei Category: Standards Track M. Pei
Expires: February 3, 2011 VeriSign ISSN: 2070-1721 VeriSign
S. Machani S. Machani
Diversinet Diversinet
August 2, 2010 October 2010
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-09
Abstract Abstract
This document specifies a symmetric key format for transport and This document specifies a symmetric key format for the transport and
provisioning of symmetric keys to different types of crypto modules. provisioning of symmetric keys to different types of crypto modules.
For example, One Time Password (OTP) shared secrets or symmetric For example, One-Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. A standard key cryptographic keys to strong authentication devices. A standard key
transport format enables enterprises to deploy best-of-breed transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same solutions combining components from different vendors into the same
infrastructure. infrastructure.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 3, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6030.
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 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Key Words ..................................................4
1.2. Version Support . . . . . . . . . . . . . . . . . . . . . 4 1.2. Version Support ............................................4
1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 5 1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 5 1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5 1.3.2. Referenced Identifiers ..............................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships . . 8 3. Portable Key Container Entities Overview and Relationships ......6
4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 10 4. <KeyContainer> Element: The Basics ..............................8
4.1. <Key>: Embedding Keying Material and Key Related 4.1. <Key>: Embedding Keying Material and Key-Related
Information . . . . . . . . . . . . . . . . . . . . . . . 10 Information ................................................8
4.2. Key Value Encoding . . . . . . . . . . . . . . . . . . . . 12 4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding . . . . . . . . . . . . . . . . 13 4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple DES Key Value Encoding . . . . . . . . . . . . 13 4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of supplementary Information . . . . . . . . 14 4.3. Transmission of Supplementary Information .................12
4.3.1. <DeviceInfo> Element: Unique Device Identification . . 15 4.3.1. <DeviceInfo> Element: Unique Device
4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification .....................................13
Identification . . . . . . . . . . . . . . . . . . . . 17 4.3.2. <CryptoModuleInfo> Element: CryptoModule
4.3.3. <UserId> Element: User Identification . . . . . . . . 17 Identification .....................................15
4.3.4. <AlgorithmParameters> Element: Supplementary 4.3.3. <UserId> Element: User Identification ..............15
Information for OTP and CR Algorithms . . . . . . . . 17 4.3.4. <AlgorithmParameters> Element:
4.4. Transmission of Key Derivation Values . . . . . . . . . . 19 Supplementary Information for OTP and CR Algorithms 15
5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Transmission of Key Derivation Values .....................17
5.1. PIN Algorithm definition . . . . . . . . . . . . . . . . . 26 5. Key Policy .....................................................19
6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 27 5.1. PIN Algorithm Definition ..................................23
6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 27 6. Key Protection Methods .........................................23
6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Encryption Based on Pre-Shared Keys .......................24
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 30 6.1.1. MAC Method .........................................26
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 33 6.2. Encryption Based on Passphrase-Based Keys .................27
6.4. Padding of Encrypted Values for Non-Padded Encryption 6.3. Encryption Based on Asymmetric Keys .......................29
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 34 6.4. Padding of Encrypted Values for Non-Padded
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 35 Encryption Algorithms .....................................31
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 37 7. Digital Signature ..............................................31
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 40 8. Bulk Provisioning ..............................................33
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 41 9. Extensibility ..................................................35
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 10. PSKC Algorithm Profile ........................................36
10.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.1. HOTP .....................................................36
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.2. PIN ......................................................37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 11. XML Schema ....................................................38
12.1. Content-type registration for 'application/pskc+xml' . . . 50 12. IANA Considerations ...........................................44
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 51 12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 51 12.2. XML Schema Registration ..................................45
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 52 12.3. URN Sub-Namespace Registration ...........................46
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 53 12.4. PSKC Algorithm Profile Registry ..........................46
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 53 12.5. PSKC Version Registry ....................................47
13. Security Considerations . . . . . . . . . . . . . . . . . . . 55 12.6. Key Usage Registry .......................................47
13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 55 13. Security Considerations .......................................48
13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 56 13.1. PSKC Confidentiality .....................................49
13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 56 13.2. PSKC Integrity ...........................................50
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.3. PSKC Authenticity ........................................50
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 14. Contributors ..................................................50
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 15. Acknowledgements ..............................................50
16.1. Normative References . . . . . . . . . . . . . . . . . . . 59 16. References ....................................................51
16.2. Informative References . . . . . . . . . . . . . . . . . . 60 16.1. Normative References .....................................51
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 62 16.2. Informative References ...................................52
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 62 Appendix A. Use Cases ............................................54
A.1.1. Transport of keys from Server to Cryptographic A.1. Online Use Cases ..........................................54
Module . . . . . . . . . . . . . . . . . . . . . . . . 62 A.1.1. Transport of Keys from Server to Cryptographic
A.1.2. Transport of keys from Cryptographic Module to Module ................................................54
Cryptographic Module . . . . . . . . . . . . . . . . . 62 A.1.2. Transport of Keys from Cryptographic Module to
A.1.3. Transport of keys from Cryptographic Module to Cryptographic Module ..................................54
Server . . . . . . . . . . . . . . . . . . . . . . . . 63 A.1.3. Transport of Keys from Cryptographic Module to
A.1.4. Server to server Bulk import/export of keys . . . . . 63 Server ................................................55
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 63 A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2.1. Server to server Bulk import/export of keys . . . . . 63 A.2. Offline Use Cases .........................................55
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 65 A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Appendix B. Requirements .........................................56
1. Introduction 1. Introduction
With increasing use of symmetric key based systems, such as With the 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,
authentication, such as those based on one-time-password (OTP) and such as those based on One-Time Password (OTP) and Challenge/Response
challenge response (CR) mechanisms, there is a need for vendor (CR) mechanisms, there is a need for vendor interoperability and a
interoperability and a standard format for importing and exporting standard format for importing and exporting (provisioning) symmetric
(provisioning) symmetric keys. For instance, traditionally, vendors keys. For instance, traditionally, vendors of authentication servers
of authentication servers and service providers have used proprietary and service providers have used proprietary formats for importing and
formats for importing and exporting these keys into their systems, exporting these keys into their systems, thus making it hard to use
thus making it hard to use tokens from two different vendors. 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 metadata. 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
HMAC-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 creates an IANA registry for algorithm profiles where algorithms,
where algorithms, their meta-data and PSKC transmission profile can their metadata and PSKC transmission profile can be recorded for a
be recorded for centralised standardised reference. centralized, standardized 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].
1.2. Version Support 1.2. Version Support
There is a provision made in the syntax for an explicit version There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified. number. Only version "1.0" is currently specified.
The numbering scheme for PSKC versions is "<major>.<minor>". The The numbering scheme for PSKC versions is "<major>.<minor>". The
major and minor numbers MUST be treated as separate integers and each major and minor numbers MUST be treated as separate integers and each
number MAY be incremented higher than a single digit. Thus, "PSKC number MAY be incremented higher than a single digit. Thus, "PSKC
2.4" would be a lower version than "PSKC 2.13", which in turn would 2.4" would be a lower version than "PSKC 2.13", which in turn would
be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be
ignored by recipients and MUST NOT be sent. ignored by recipients and MUST NOT be sent.
The major version number should be incremented only if the message The major version number should be incremented only if the message
format (E.g. Element structure) has changed so dramatically that an format (e.g., element structure) has changed so dramatically that an
older version implementation would not be able to interoperate with a older version implementation would not be able to interoperate with a
newer version. The minor version number indicates new capabilities, newer version. The minor version number indicates new capabilities,
and MUST be ignored by an entity with a smaller minor version number, and it MUST be ignored by an entity with a smaller minor version
but used for informational purposes by the entity with the larger number but used for informational purposes by the entity with the
minor version number. larger minor version number.
1.3. Namespace Identifiers 1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers [RFC3986] to identify This document uses Uniform Resource Identifiers (URIs) [RFC3986] to
resources, algorithms, and semantics. identify 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:
"urn:ietf:params:xml:ns:keyprov:pskc" "urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined in this References to qualified elements in the PSKC schema defined in this
specification and used in the example use the prefix "pskc" (defined specification and used in the example use the prefix "pskc" (defined
as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc") . It is as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"). It is
RECOMMENDED to use this namespace in implementations. 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#"
skipping to change at page 5, line 44 skipping to change at page 5, line 44
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the References to the XML Encryption namespace are represented by the
prefix "xenc". prefix "xenc".
When protecting keys in transport with passphrase-based keys, PSKC When protecting keys in transport with passphrase-based keys, PSKC
also relies on the derived key element defined in the XML Encryption also relies on the derived key element defined in the XML Encryption
Version 1.1 [XMLENC11] namespace: Version 1.1 [XMLENC11] namespace:
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
References to the XML Encryption Version 1.1 namespace are References to the XML Encryption Version 1.1 namespace are
represented by the prefix "xenc11". represented by the prefix "xenc11".
When protecting keys in transport with passphrase-based keys, PSKC When protecting keys in transport with passphrase-based keys, PSKC
also relies on algorithm identifiers and elements defined in the also relies on algorithm identifiers and elements defined in the PKCS
PKCS#5 [PKCS5] namespace: #5 [PKCS5] namespace:
xmlns:pkcs5= xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
References to the PKCS#5 namespace are represented by the prefix References to the PKCS #5 namespace are represented by the prefix
"pkcs5". "pkcs5".
2. Terminology 2. Terminology
NOTE: In subsequent sections of the document we highlight NOTE: In subsequent sections of the document, we highlight
**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. A valid container MUST carry at least 1 number of KeyPackage entities. A valid container MUST carry at
KeyPackage. least one KeyPackage entity.
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 identify uniquely 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 to which they are
provisioned.
5. Key entity - representing the key transported or provisioned 5. Key entity - representing the key transported or provisioned.
6. Data entity - representing a list of meta-data related to the 6. Data entity - representing a list of metadata related to the key,
key, where the element name is the name of the meta-data and its where the element name is the name of the metadata and its
associated value is either in encrypted form (for example for associated value is either in encrypted (for example, for <Data>
Data element <Secret>) or plaintext (for example the Data element element <Secret>) or plaintext (for example, the <Data> element
<Counter>) <Counter>) form.
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 |
| ... | | ... |
----------------- -----------------
skipping to change at page 9, line 44 skipping to change at page 7, line 44
/|\ 0..n /|\ 0..n
--------------------------------------- - - --------------------------------------- - -
| | | | | |
------------------ ---------------- -------- - - ------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other | Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - - |----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue | | EncryptedValue | | PlainValue |
| ValueMAC | ---------------- | ValueMAC | ----------------
------------------ ------------------
Figure 1: PSKC data elements relationship diagram Figure 1: PSKC Data Elements Relationship Diagram
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 its most basic form, a PSKC document uses the top-level element In its most basic form, a PSKC document uses the top-level element
<KeyContainer> and a single <KeyPackage> element to carry key <KeyContainer> and a single <KeyPackage> element to carry key
information. information.
The following example shows such a simple PSKC document. We will use The following example shows a simple PSKC document. We will use it
it to describe the structure of the <KeyContainer> element and its to describe the structure of the <KeyContainer> element and its child
child elements. elements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
Id="exampleID1" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage> <KeyPackage>
<Key Id="12345678" <Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer-A</Issuer> <Issuer>Issuer-A</Issuer>
<Data> <Data>
skipping to change at page 10, line 38 skipping to change at page 8, line 38
</Data> </Data>
</Key> </Key>
</KeyPackage> </KeyPackage>
</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
semantics: semantics:
'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.0") of the PSKC schema. This attribute MUST initial version ("1.0") of the PSKC schema. This attribute MUST
be included. be included.
'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 container. As such, it helps to identify a specific key container
in cases when multiple containers are embedded in larger xml in cases in which multiple containers are embedded in larger XML
documents. documents.
4.1. <Key>: Embedding Keying Material and Key Related Information 4.1. <Key>: Embedding Keying Material and Key-Related Information
The following attributes of the <Key> element MUST be included at a The following attributes of the <Key> element MUST be included at a
minimum: minimum:
'Id': This attribute carries a unique identifier for the symmetric 'Id': This attribute carries a unique identifier for the symmetric
key in the context of key provisioning exchanges between two key in the context of key provisioning exchanges between two
parties. This means that if PSKC is used in multiple interactions parties. This means that if PSKC is used in multiple interactions
between a sending and receiving party, using different containers between a sending and receiving party, using different containers
referencing the same keys, the KeyId MUST use the same KeyId referencing the same keys, the 'Id' attribute of <Key> MUST use
values (e.g. after initial provisioning, if a system wants to the same value (e.g., after initial provisioning, if a system
update key meta data values in the other system the KeyId value of wants to update key metadata values in the other system, the value
the key where the meta data is to be updates MUST be the same of of the 'Id' attribute of the <Key> where the metadata is to be
the original KeyId value provisioned). The identifier is defined updated MUST be the same of the original 'Id' attribute value
as a string of alphanumeric characters. provisioned). The identifier is defined as a string of
alphanumeric characters.
'Algorithm': This attribute contains a unique identifier for the 'Algorithm': This attribute contains a unique identifier for the
PSKC algorithm profile. This profile associates specific PSKC algorithm profile. This profile associates specific
semantics to the elements and attributes contained in the <Key> semantics to the elements and attributes contained in the <Key>
element. This document describes profiles for open standards element. This document describes profiles for open standards
algorithms in Section 10. Additional profiles are defined in the algorithms in Section 10. Additional profiles are defined in the
following information draft [PSKC-ALGORITHM-PROFILES]. following informative document: [PSKC-ALGORITHM-PROFILES].
The <Key> element has a number of optional child elements. An The <Key> element has a number of optional child elements. An
initial set is described below: initial set is described below:
<Issuer>: This element represents the name of the party that issued <Issuer>: This element represents the name of the party that issued
the key. For example, a bank "Foobar Bank Inc." issuing hardware the key. For example, a bank "Foobar Bank, Inc." issuing hardware
tokens to their retail banking users may set this element to tokens to their retail banking users may set this element to
"Foobar Bank Inc.". 'Foobar Bank, Inc.'.
<FriendlyName>: A human readable name for the secret key for easier <FriendlyName>: A human-readable name for the secret key for easier
reference. This element serves informational purposes only. This reference. This element serves informational purposes only. This
element is a language dependent string hence it SHOULD have an element is a language-dependent string; hence, it SHOULD have an
attribute xml:lang="xx" where xx is the language identifier as attribute xml:lang="xx" where xx is the language identifier as
specified in [RFC4646]. If no xml:lang attribute is present specified in [RFC5646]. If no xml:lang attribute is present,
implementations MUST assume the language to be English as defined implementations MUST assume the language to be English as defined
by setting the attribute value to "en" (e.g. xml:lang="en"). by setting the attribute value to 'en' (e.g., xml:lang="en").
<AlgorithmParameters>: This element carries parameters that <AlgorithmParameters>: This element carries parameters that
influence the result of the algorithmic computation, for example influence the result of the algorithmic computation, for example,
response truncation and format in OTP and CR algorithms. A more response truncation and format in OTP and CR algorithms. A more
detailed discussion of the element can be found in Section 4.3.4. detailed discussion of the element can be found in Section 4.3.4.
<Data>: This element carries data about and related to the key. The <Data>: This element carries data about and related to the key. The
following child elements are defined for the <Data> element: following child elements are defined for the <Data> element:
<Secret>: This element carries the value of the key itself in a <Secret>: This element carries the value of the key itself in a
binary representation, please see Section 4.2 for more details binary representation. Please see Section 4.2 for more details
on Key Value Encoding. on Key Value Encoding.
<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 intervals are 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 it is algorithm dependent).
<TimeInterval>: This element carries the time interval value for <TimeInterval>: This element carries the time interval value for
time based OTP algorithms in seconds (typical value for this time-based OTP algorithms in seconds (a typical value for this
would be 30 indicating a time interval of 30 seconds). 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 integer value (positive or for time-based OTP algorithms. The integer value (positive or
negative drift) that indicates the number of time intervals negative drift) that indicates the number of time intervals
that a validation server has established the device clock that a validation server has established the device clock
drifted after the last succssful authentication. So for drifted after the last successful authentication. So, for
example if the last successful authentication established a example, if the last successful authentication established a
device time value of 8 intervals from a specific start date but device time value of 8 intervals from a specific start date but
the validation server determines the time value at 9 intervals, the validation server determines the time value at 9 intervals,
the server SHOULD record the drift as -1. 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 a plaintext value
is typed, for example to xs:integer. that is typed, for example, to xs:integer.
Encrypted: The <EncryptedValue> element carries encrypted value. Encrypted: The <EncryptedValue> element carries an encrypted
value.
ValueMAC: The <ValueMAC> element is populated with a MAC ValueMAC: The <ValueMAC> element is populated with a Message
generated from the encrypted value in case the encryption Authentication Code (MAC) generated from the encrypted value in
algorithm does not support integrity checks. The example shown case the encryption algorithm does not support integrity
at Figure 2 illustrates the usage of the <Data> element with checks. The example shown in Figure 2 illustrates the usage of
two child elements, namely <Secret> and <Counter>. Both the <Data> element with two child elements, namely <Secret> and
elements carry plaintext value within the <PlainValue> child <Counter>. Both elements carry a plaintext value within the
element. <PlainValue> child element.
4.2. Key Value Encoding 4.2. Key Value Encoding
Two parties receiving the same key value OCTET STRING, resulting in Two parties receiving the same key value OCTET STRING, resulting in
decoding the xs:base64Binary, inside the <PlainValue> or decoding the xs:base64Binary, inside the <PlainValue> or
<EncryptedValue> elements, must make use of the key in exactly the <EncryptedValue> elements, must make use of the key in exactly the
same way in order to interoperate. To ensure that, it is necessary same way in order to interoperate. To ensure that, it is necessary
to define a correspondence between the OCTET STRING and the notation to define a correspondence between the OCTET STRING and the notation
in the standard algorithm description that defines how the key is in the standard algorithm description that defines how the key is
used. The next sections establish that correspondence for the used. The next sections establish that correspondence for the AES
algorithms AES [FIPS197] and TDEA [SP800-67]. Unless otherwise algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or
specified for a specific algorithm the OCTET STRING encoding MUST Triple DES) [SP800-67]. Unless otherwise specified for a specific
follow the AES Key Value Encoding. algorithm, the OCTET STRING encoding MUST follow the AES Key Value
Encoding.
4.2.1. AES Key Value Encoding 4.2.1. AES Key Value Encoding
[FIPS197] section 5.2, titled Key Expansion, uses the input key as an [FIPS197], Section 5.2, titled "Key Expansion", uses the input key as
array of bytes indexed starting at 0. The first octet of OCTET an array of bytes indexed starting at 0. The first octet of the
STRING SHALL become the key byte in AES labeled index 0 in [FIPS197]; OCTET STRING SHALL become the key byte in the AES, labeled index 0 in
the succeeding octets of OCTET STRING SHALL become key bytes in AES [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key
in increasing index order. bytes in AES, in increasing index order.
Proper parsing and key load of the contents of OCTET STRING for AES Proper parsing and key load of the contents of the OCTET STRING for
SHALL be determined by using the following value for the <PlainValue> AES SHALL be determined by using the following value for the
element (binaryBase64 encoded) to generate and match the key <PlainValue> element (binaryBase64-encoded) to generate and match the
expansion test vectors in [FIPS197] Appendix A for AES key expansion test vectors in [FIPS197], Appendix A, for AES
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
... ...
<PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue> <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue>
... ...
4.2.2. Triple DES Key Value Encoding 4.2.2. Triple-DES Key Value Encoding
A Triple-DES key consists of three keys for the cryptographic engine A Triple-DES key consists of three keys for the cryptographic engine
(Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8
parity bits); the three keys are also collectively referred to as a parity bits); the three keys are also collectively referred to as a
key bundle [SP800-67]. A key bundle may employ either two or three key bundle [SP800-67]. A key bundle may employ either two or three
independent keys. When only two independent keys are employed independent keys. When only two independent keys are employed
(called two-key Triple DES), then the same value is used for Key1 and (called two-key Triple DES), the same value is used for Key1 and
Key3. Key3.
Each key in a Triple-DES key bundle is expanded into a key schedule Each key in a Triple-DES key bundle is expanded into a key schedule
according to a procedure defined in [SP800-67] Appendix A. That according to a procedure defined in [SP800-67], Appendix A. That
procedure numbers the bits in the key from 1 to 64, with number 1 procedure numbers the bits in the key from 1 to 64, with number 1
being the left-most, or most significant bit (MSB). The first octet being the leftmost, or most significant bit (MSB). The first octet
of OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1 being of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1
the MSB. The second octet of OCTET STRING SHALL be bits 9 through 16 being the MSB. The second octet of the OCTET STRING SHALL be bits 9
of Key1, and so forth, so that the trailing octet of OCTET STRING through 16 of Key1, and so forth, so that the trailing octet of the
SHALL be bits 57 through 64 of Key3 (or Key2 for two-key Triple DES). OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key
Triple DES).
Proper parsing and key load of the contents of OCTET STRING for Proper parsing and key load of the contents of the OCTET STRING for
Triple-DES SHALL be determined by using the following <PlainValue> Triple DES SHALL be determined by using the following <PlainValue>
element (binaryBase64 encoded) to generate and match the key element (binaryBase64-encoded) to generate and match the key
expansion test vectors in [SP800-67] appendix B for the key bundle: expansion test vectors in [SP800-67], Appendix B, for the key bundle:
Key1 = 0123456789ABCDEF Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01 Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123 Key3 = 456789ABCDEF0123
... ...
<PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue> <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue>
... ...
4.3. Transmission of supplementary Information 4.3. Transmission of Supplementary Information
A PSKC document can contain a number of additional information A PSKC document can contain a number of additional information
regarding device identification, cryptomodule identification, user regarding device identification, cryptographic module identification,
identification and parameters for usage with OTP and CR algorithms. user identification, and parameters for usage with OTP and CR
The following example, see Figure 3, is used as a reference for the algorithms. The following example, see Figure 3, is used as a
subsequent sub-sections. reference for the subsequent sub-sections.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
Id="exampleID1" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage> <KeyPackage>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
<UserId>DC=example-bank,DC=net</UserId> <UserId>DC=example-bank,DC=net</UserId>
skipping to change at page 15, line 42 skipping to change at page 13, line 42
</Data> </Data>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId> <UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 3: PSKC Key Container Example with Supplementary Data Figure 3: PSKC Key Container Example with Supplementary Data
4.3.1. <DeviceInfo> Element: Unique Device Identification 4.3.1. <DeviceInfo> Element: Unique Device Identification
The <DeviceInfo> element uniquely identifies the device the The <DeviceInfo> element uniquely identifies the device to which the
<KeyPackage> is provisioned to. Since devices can come in different <KeyPackage> is provisioned. Since devices can come in different
form factors, such as hardware tokens, smart-cards, soft tokens in a form factors, such as hardware tokens, smart-cards, soft tokens in a
mobile phone or as a PC, this element allows different child element mobile phone, or as a PC, this element allows different child element
combinations to be used. When combined, the values of the child combinations to be used. When combined, the values of the child
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. Values for Manufacturer MUST be taken from either device. Values for the <Manufacturer> element MUST be taken from
[OATHMAN] prefixes (i.e., the left column) or from IANA Private either [OATHMAN] prefixes (i.e., the left column) or from the IANA
Enterprise Number Registry [IANAPENREG], using the Organisation Private Enterprise Number Registry [IANAPENREG], using the
value. When the value is taken from [OATHMAN] "oath." MUST be Organization value. When the value is taken from [OATHMAN],
prepended to the value (e.g. "oath.<prefix value from "oath." MUST be prepended to the value (e.g., "oath.<prefix value
[OATHMAN]>"). When the value is taken from [IANAPENREG] "iana." from [OATHMAN]>"). When the value is taken from [IANAPENREG],
MUST be prepended to the value (e.g. "iana.<Organisation value "iana." MUST be prepended to the value (e.g., "iana.<Organization
from [IANAPENREG]>"). value from [IANAPENREG]>").
<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 there are
with the same serial number that are distinguished by different devices with the same serial number so that they can be
issue numbers. distinguished by different issue numbers.
<DeviceBinding>: This element allows a provisioning server to ensure <DeviceBinding>: This element allows a provisioning server to ensure
that the key is going to be loaded into the device for which the that the key is going to be loaded into the device for which the
key provisioning request was approved. The device is bound to the key provisioning request was approved. The device is bound to the
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 as a dateTime in "canonical representation" expressed as a dateTime value in "canonical representation"
[W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
on time resolution finer than milliseconds and MUST NOT generate on time resolution finer than milliseconds and MUST NOT generate
time instants that specify leap seconds. Keys that reside on the time instants that specify leap seconds. Keys that reside on the
device SHOULD only be used when the current date is after the device SHOULD only be used when the current date is after the
<StartDate> and before the <ExpiryDate>. Note that usage <StartDate> and before the <ExpiryDate>. Note that usage
enforcement of the keys with respective to the dates MAY only enforcement of the keys with respect to the dates MAY only happen
happen on the validation server as some devices such as smart on the validation server, as some devices such as smart cards do
cards do not have an internal clock. Systems thus SHOULD NOT rely not have an internal clock. Systems thus SHOULD NOT rely upon the
upon the device to enforce key usage date restrictions. 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.3.2. <CryptoModuleInfo> Element: CryptoModule Identification 4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification
The <CryptoModuleInfo> element identifies the cryptographic module to The <CryptoModuleInfo> element identifies the cryptographic module to
which the symmetric keys are or have been provisioned to. This which the symmetric keys are or have been provisioned. This allows
allows the identification of the specific cases where a device MAY the identification of the specific cases where a device MAY contain
contain more than one crypto module (e.g. a PC hosting a TPM and a more than one crypto module (e.g., a PC hosting a TPM and a connected
connected token). token).
The <CryptoModuleInfo> element has a single child element that MUST The <CryptoModuleInfo> element has a single child element that MUST
be included: be included:
<Id>: This element carries a unique identifier for the CryptoModule <Id>: This element carries a unique identifier for the CryptoModule
and is implementation specific. As such, it helps to identify a and is implementation specific. As such, it helps to identify a
specific CryptoModule to which the key is being or was specific CryptoModule to which the key is being or was
proivisioned. provisioned.
4.3.3. <UserId> Element: User Identification 4.3.3. <UserId> Element: User Identification
The <UserId> element identifies the user using a distinguished name, The <UserId> element identifies the user of a distinguished name, as
as defined in [RFC4514]. For example: UID=jsmith,DC=example,DC=net. defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.
Although the syntax of the user identifier is defined, there are no Although the syntax of the user identifier is defined, there are no
semantics associated with this element, i.e., there are no checks semantics associated with this element, i.e., there are no checks
enforcing that only a specific user can use this key. As such, this enforcing that only a specific user can use this key. As such, this
element is for informational purposes only. element is for informational purposes only.
This element may appear in two places, namely as a child element of This element may appear in two places, namely as a child element of
the <Key> element where it indicates the user with whom the key is the <Key> element, where it indicates the user with whom the key is
associated with and as a child element of the <DeviceInfo> element associated, and as a child element of the <DeviceInfo> element, where
where it indicates the user the device is associated with. it indicates the user with whom the device is associated.
4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP 4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP
and CR Algorithms and CR Algorithms
The <AlgorithmParameters> element is a child element of the <Key> The <AlgorithmParameters> element is a child element of the <Key>
element and this document defines three child elements: <Suite>, element, and this document defines three child elements: <Suite>,
<ChallengeFormat> and <ResponseFormat> <ChallengeFormat>, and <ResponseFormat>.
<Suite>: <Suite>:
The optional <Suite> element defines additional characteristics of The optional <Suite> element defines additional characteristics of
the algorithm used, which are algorithm specific. For example in the algorithm used, which are algorithm specific. For example, in
HMAC based OTP algorithm it could designate the strength of the an HMAC-based (Hashed MAC) OTP algorithm, it could designate the
hash algorithm used (SHA1, SHA256, etc). Please refer to strength of the hash algorithm used (SHA1, SHA256, etc.). Please
algorithm profile specification Section 10 for the exact semantic refer to the algorithm profile section, Section 10, for the exact
of the value for each algorithm profile. semantics of the value for each algorithm profile.
<ChallengeFormat>: <ChallengeFormat>:
The <ChallengeFormat> element defines the characteristics of the The <ChallengeFormat> element defines the characteristics of the
challenge in a CR usage scenario whereby the following attributes challenge in a CR usage scenario whereby the following attributes
are defined: are defined:
'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, as defined in Section 4 of [RFC4648]
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 check the appended Luhn check digit, as defined in
[ISOIEC7812], contained in a challenge. This is only valid if [ISOIEC7812], contained in a challenge. This is only valid if
the 'Encoding' attribute is 'DECIMAL'. A value of TRUE the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE
indicates that the device will check the appended Luhn check indicates that the device will check the appended Luhn check
digit in a provided challenge. A value of FALSE indicates that digit in a provided challenge. A value of FALSE indicates that
the device will not check the appended Luhn check digit in the the device will not check the appended Luhn check digit in the
challenge. 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 set to '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 set to
'BINARY', this value indicates the minimum number of bytes of 'BASE64' or 'BINARY', this value indicates the minimum number
the unencoded value. of bytes of the unencoded value.
'Max': This attribute defines the maximum size of the challenge 'Max': This attribute defines the maximum 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 set to 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC' this value indicates the maximum number of 'ALPHANUMERIC', this value indicates the maximum number of
digits/characters. If the 'Encoding' attribute is 'BASE64' or digits/characters. If the 'Encoding' attribute is set to
'BINARY', this value indicates the maximum number of bytes of 'BASE64' or 'BINARY', this value indicates the maximum number
the unencoded value. of bytes of the unencoded value.
<ResponseFormat>: <ResponseFormat>:
The <ResponseFormat> element defines the characteristics of the The <ResponseFormat> element defines the characteristics of the
result of a computation and defines the format of the OTP or the result of a computation and defines the format of the OTP or the
response to a challenge. For cases where the key is a PIN value, response to a challenge. For cases in which the key is a PIN
this element contains the format of the PIN itself (e.g., DECIMAL, value, this element contains the format of the PIN itself (e.g.,
length 4 for a 4 digit PIN). The following attributes are DECIMAL, length 4 for a 4-digit PIN). The following attributes
defined: are 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 [ISOIEC7812], to to append a Luhn check digit, as defined in [ISOIEC7812], to
the response. This is only valid if the 'Encoding' attribute the response. This is only valid if the 'Encoding' attribute
is 'DECIMAL'. If the value is TRUE then the device will append is set to 'DECIMAL'. If the value is TRUE, then the device
a Luhn check digit to the response. If the value is FALSE, will append a Luhn check digit to the response. If the value
then the device will not append a Luhn check digit to the is FALSE, then the device will not append a Luhn check digit to
response. 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 set to '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 set to '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.4. Transmission of Key Derivation Values 4.4. Transmission of Key Derivation Values
<KeyProfileId> element, which is a child element of the <Key> <KeyProfileId> element, which is a child element of the <Key>
element, carries a unique identifier used between the sending and element, carries a unique identifier used between the sending and
receiving parties to establish a set of key attribute values that are receiving parties to establish a set of key attribute values that are
not transmitted within the container but agreed between the two not transmitted within the container but are agreed upon between the
parties out of band. This element will then represent the unique two parties out of band. This element will then represent the unique
reference to a set of key attribute values. (For example, a smart reference to a set of key attribute values. (For example, a smart
card application personalisation profile id related to specific card application personalization profile id related to specific
attribute values present on a smart card application, that have attribute values present on a smart card application that have
influence when computing a response.). influence when computing a response).
For example, in the case of MasterCard's Chip Authentication Program For example, in the case of MasterCard's Chip Authentication Program
[CAP], the sending and the receiving party would agree that [CAP], the sending and the receiving party would agree that
KeyProfileId='1' represents a certain set of values (e.g., Internet KeyProfileId='1' represents a certain set of values (e.g., Internet
Authentication Flag IAF set to a specific value). During Authentication Flag (IAF) set to a specific value). During
transmission of the KeyContainer, these values would not be transmission of the <KeyContainer>, these values would not be
transmitted as key attributes but only referred to via the transmitted as key attributes but would only be referred to via the
<KeyProfileId> element set to the specific agreed profile (in this <KeyProfileId> element set to the specific agreed-upon profile (in
case '1'). The receiving party can then associate all relevant key this case '1'). The receiving party can then associate all relevant
attributes contained in the out of band agreed profile with the key attributes contained in the profile that was agreed upon out of
imported keys. Often this methodology is used between a band with the imported keys. Often, this methodology is used between
manufacturing service, run by company A and the validation service a manufacturing service, run by company A, and the validation
run by company B, to avoid repeated transmission of the same set of service, run by company B, to avoid repeated transmission of the same
key attribute values. set of key attribute values.
The <KeyReference> element contains a reference to an external key to The <KeyReference> element contains a reference to an external key to
be used with a key derivation scheme and no specific key value be used with a key derivation scheme. In this case, the parent <Key>
(secret) is transported but only the reference to the external master element will not contain the <Secret> subelement of <Data>, in which
key is used (e.g., the PKCS#11 key label). the key value (secret) is transported; only the reference to the
external master key is transported (e.g., a PKCS #11 key label).
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" Id="exampleID1" <KeyContainer Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage> <KeyPackage>
<DeviceInfo> <DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer> <Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo> <SerialNo>987654321</SerialNo>
</DeviceInfo> </DeviceInfo>
<CryptoModuleInfo> <CryptoModuleInfo>
skipping to change at page 20, line 49 skipping to change at page 18, line 50
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
<Policy> <Policy>
<KeyUsage>OTP</KeyUsage> <KeyUsage>OTP</KeyUsage>
</Policy> </Policy>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 4: Example of a PSKC Document transmitting a HOTP key via key Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key
derivation values Derivation Values
The key value will be derived using the value of the <SerialNo> The key value will be derived using the value of the <SerialNo>
element, values agreed between the sending and the receiving parties element, values agreed upon between the sending and the receiving
and identified by the KeyProfile 'keyProfile1' and an externally parties and identified by the <KeyProfile> 'keyProfile1', and an
agreed key referenced by the label 'MasterKeyLabel'. externally agreed-upon key referenced by the label 'MasterKeyLabel'.
5. Key Policy 5. Key Policy
This section illustrates the functionality of the <Policy> element This section illustrates the functionality of the <Policy> element
within PSKC that allows a key usage and key PIN protection policy to within PSKC, which allows a key usage and key PIN protection policy
be attached to a specific key and its related meta data. This to be attached to a specific key and its related metadata. This
element is a child element of the <Key> element. element is a child element of the <Key> element.
If the <Policy> element contains child elements or values within If the <Policy> element contains child elements or values within
elements/attributes that are not understood by the recipient of the elements/attributes that are not understood by the recipient of the
PSKC document then the recipient MUST assume that key usage is not PSKC document, then the recipient MUST assume that key usage is not
permitted. This statement ensures that the lack of understanding of permitted. This statement ensures that the lack of understanding of
certain extensions does not lead to unintended key usage. certain extensions 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 <KeyContainer
Version="1.0" Id="exampleID1" Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
skipping to change at page 23, line 31 skipping to change at page 20, line 38
</AlgorithmParameters> </AlgorithmParameters>
<Data> <Data>
<Secret> <Secret>
<PlainValue>MTIzNA==</PlainValue> <PlainValue>MTIzNA==</PlainValue>
</Secret> </Secret>
</Data> </Data>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 5: Non-Encrypted HOTP Secret Key protected by PIN Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN
This document defines the following Policy child elements: This document defines the following <Policy> child elements:
<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 date MUST be between the start and the end date (inclusive). The date MUST be
expressed as a dateTime in "canonical representation" expressed as a dateTime value in "canonical representation"
[W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
on time resolution finer than milliseconds and MUST NOT generate on time resolution finer than milliseconds and MUST NOT generate
time instants that specify leap seconds. When this element is time instants that specify leap seconds. When this element is
absent the current time is assumed as the start time. absent, the current time is assumed as the start time.
<NumberOfTransactions>: The value in this element indicates the <NumberOfTransactions>: The value in this element indicates the
maximum number of times a key carried within the PSKC document can maximum number of times a key carried within the PSKC document can
be used by an application after having received it.. When this be used by an application after having received it. When this
element is omitted then there is no restriction regarding the element is omitted, there is no restriction regarding the number
number of times a key can be used. of times a key can be 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.
Integrity: The key MUST only be used to generate a keyed message Integrity: The key MUST only be used to generate a keyed message
digest for data integrity or authentication purposes. digest for data integrity or authentication purposes.
Verify: The key MUST only be used to verify a keyed message Verify: The key MUST only be used to verify a keyed message
digest for data integrity or authentication purposes. (this is digest for data integrity or authentication purposes (this is
the vice versa of Integrity) the opposite key usage of 'Integrity').
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 where a user has locked the device by Response in the case where a user has locked the device by
entering a wrong PIN too many times (for devices with PIN-input entering a 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. Unwrap: The key MUST only be used for key unwrap purposes.
Derive: The key MUST only be used with a key derivation function Derive: The key MUST only be used with a key derivation function
to derive a new key (see also Section 8.2.4 of [NIST800-57]). to derive a new key (see also Section 8.2.4 of [NIST800-57]).
Generate: The key MUST only be used to generate a new key based 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 on a random number and the previous value of the key (see also
Section 8.1.5.2.1 of[NIST800-57]). Section 8.1.5.2.1 of [NIST800-57]).
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, no key usage constraint
constraint is assumed, i.e., the key MAY be utilized for every 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 carries the unique 'Id' attribute vale
held within this container that contains the value of the PIN of the <Key> element held within this <KeyContainer> that
that protects the key. contains the value of the PIN that protects the key.
'PINUsageMode': This mandatory attribute indicates the way the 'PINUsageMode': This mandatory attribute indicates the way the
PIN is used during the usage of the key. The following values PIN is used during the usage of the key. The following values
are defined: are defined:
Local: This value indicates that the PIN is checked locally on Local: This value indicates that the PIN is checked locally on
the device before allowing the key to be used in executing the device before allowing the key to be used in executing
the algorithm. the algorithm.
Prepend: This value indicates that the PIN is prepended to the Prepend: This value indicates that the PIN is prepended 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.
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 (typical reasonable values are possible to use the key anymore (typical reasonable values are
in the positive integer range of at least 2 and no more than in the positive integer range of at least 2 and no more than
10). 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 set to '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 set to '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.
'MaxLength': This attribute indicates the maximum length of a PIN 'MaxLength': This attribute indicates the maximum length of a PIN
that can be set to protect this key. It MUST NOT be possible that can be set to protect this key. It MUST NOT be possible
to set a PIN longer than this value. If the 'PINFormat' to set a PIN longer than this value. If the 'PINFormat'
attribute is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this attribute is set to 'DECIMAL', 'HEXADECIMAL', or
value indicates the number of digits/characters. If the 'ALPHANUMERIC', this value indicates the number of digits/
'PINFormat' attribute is 'BASE64' or 'BINARY', this value characters. If the 'PINFormat' attribute is set to 'BASE64' or
indicates the number of bytes of the unencoded value. 'BINARY', this value indicates the number of bytes of the
unencoded value.
'PINEncoding': This attribute indicates the encoding of the PIN 'PINEncoding': This attribute indicates the encoding of the PIN
and MUST be one of the values: DECIMAL, HEXADECIMAL, and MUST be one of the values: DECIMAL, HEXADECIMAL,
ALPHANUMERIC, BASE64, or BINARY. ALPHANUMERIC, BASE64, or BINARY.
If the 'PinUsageMode' attribute is set to "Local" then the device If the 'PinUsageMode' attribute is set to 'Local', then the device
MUST enforce the restriction indicated in the 'MaxFailedAttempts', MUST enforce the restriction indicated in the 'MaxFailedAttempts',
'MinLength', 'MaxLength' and 'PINEncoding' attribute, otherwise it 'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise,
MUST be enforced on the server side. it MUST be enforced on the server side.
5.1. PIN Algorithm definition 5.1. PIN Algorithm Definition
The PIN algorithm is defined as: The PIN algorithm is defined as:
boolean = comparePIN(K,P) boolean = comparePIN(K,P)
Where: Where:
'K': Is the stored symmetric credential (PIN) in binary format. 'K' is the stored symmetric credential (PIN) in binary format.
'P': Is the proposed PIN to be compared in binary format. 'P' is the proposed PIN to be compared in binary format.
The function comparePIN is a straight octet comparison of K and P. The function comparePIN is a straight octet comparison of K and P.
Such comparison MUST yield TRUE (credentials matched) when the the Such a comparison MUST yield a value of TRUE (credentials matched)
octet length of K is the same as the octet length of P and all octets when the octet length of K is the same as the octet length of P and
comprising K are the same as the octets comprising P. all octets comprising K are the same as the octets comprising P.
6. Key Protection Methods 6. Key Protection Methods
With the functionality described in the previous sections, With the functionality described in the previous sections,
information related to keys had to be transmitted in clear text. information related to keys had to be transmitted in cleartext. With
With the help of the <EncryptionKey> element, which is a child the help of the <EncryptionKey> element, which is a child element of
element of the <KeyContainer> element, it is possible to encrypt keys the <KeyContainer> element, it is possible to encrypt keys and
and associated information. The level of encryption is applied to associated information. The level of encryption is applied to the
the value of individual elements and the applied encryption algorithm value of individual elements and the applied encryption algorithm
MUST be the same for all encrypted elements. Keys are protected MUST be the same for all encrypted elements. Keys are protected
using the following methods: pre-shared keys, passphrase-based keys, using the following methods: pre-shared keys, passphrase-based keys,
and asymmetric keys. When encryption algorithms are used that make and asymmetric keys. When encryption algorithms are used that make
use of Initialisation Vectors (IV), for example AES128-CBC, then a use of Initialization Vectors (IVs), for example, AES-128-CBC, a
random IV value MUST be generated for each value to be encrypted and random IV value MUST be generated for each value to be encrypted and
it MUST be prepended to the resulting encrypted value as specified in it MUST be prepended to the resulting encrypted value as specified in
[XMLENC]. [XMLENC].
6.1. Encryption based on Pre-Shared Keys 6.1. Encryption Based on Pre-Shared Keys
Figure 6 shows an example that illustrates the encryption of the Figure 6 shows an example that illustrates the encryption of the
content of the <Secret> element using AES128-CBC and PKCS5 Padding. content of the <Secret> element using AES-128-CBC and PKCS #5
The plaintext value of <Secret> is Padding. The plaintext value of <Secret> is
'3132333435363738393031323334353637383930'. The name of the pre- '3132333435363738393031323334353637383930'. The name of the pre-
shared secret is "Pre-shared-key", as set in the <KeyName> element shared secret is "Pre-shared-key", as set in the <KeyName> element
(which is a child element of the <EncryptionKey> element). The value (which is a child element of the <EncryptionKey> element). The value
of the encryption key used is '12345678901234567890123456789012'. of the encryption key used is '12345678901234567890123456789012'.
The IV for the MAC key is '11223344556677889900112233445566' and the The IV for the MAC key is '11223344556677889900112233445566', and the
IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'. IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
As AES128-CBC does not provide integrity checks a keyed MAC is As AES-128-CBC does not provide integrity checks, a keyed MAC is
applied to the encrypted value using a MAC key and a MAC algorithm as applied to the encrypted value using a MAC key and a MAC algorithm as
declared in the <MACMethod> element (in our example declared in the <MACMethod> element (in our example,
"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the
algorithm and the value of the MAC key is randomly generated, in our algorithm and the value of the MAC key is randomly generated, in our
case '1122334455667788990011223344556677889900', and encrypted with case '1122334455667788990011223344556677889900', and encrypted with
the above encryption key). The result of the keyed MAC computation the above encryption key). The result of the keyed-MAC computation
is placed in the <ValueMAC> child element of <Secret>. is placed in the <ValueMAC> child element of <Secret>.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey> <EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName> <ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey> </EncryptionKey>
skipping to change at page 29, line 4 skipping to change at page 25, line 35
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1 Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
When protecting the payload with pre-shared keys implementations MUST
set the name of the specific pre-shared key in the <KeyName> element
inside the <EncryptionKey> element. When the encryption method uses
a CBC mode that requires an explicit initialization vector (IV), the
IV MUST be passed by prepending it to the encrypted value.
For systems implementing PSKC it is RECOMMENDED to support AES-128- When protecting the payload with pre-shared keys, implementations
CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and MUST set the name of the specific pre-shared key in the <KeyName>
KW-AES128 (with the URI of element inside the <EncryptionKey> element. When the encryption
http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW- method uses a CBC mode that requires an explicit initialization
AES128 requires that the key to be protected must be a multiple of 8 vector (IV), the IV MUST be passed by prepending it to the encrypted
bytes in length. Hence, if keys of a different length have to be value.
protected then the usage of the key wrap algorithm with padding, as
described in [AESKWPAD] is RECOMMENDED. Some of the encryption For systems implementing PSKC, it is RECOMMENDED to support
AES-128-CBC (with the URI of
http://www.w3.org/2001/04/xmlenc#aes128-cbc) and 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 in length. Hence, if keys of a different length have to be
protected, then the usage of the key-wrap algorithm with padding, as
described in [RFC5649] is RECOMMENDED. Some of the encryption
algorithms that can optionally be implemented are: algorithms that can optionally be implemented are:
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
skipping to change at page 29, line 39 skipping to change at page 26, line 24
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
6.1.1. MAC Method 6.1.1. MAC Method
When algorithms without integrity checks are used, such as AES-128- When algorithms without integrity checks are used, such as AES-128-
CBC, a keyed MAC value MUST be placed in the <ValueMAC> element of CBC, a keyed-MAC value MUST be placed in the <ValueMAC> element of
the <Data> element. In this case the MAC algorithm type MUST be set the <Data> element. In this case, the MAC algorithm type MUST be set
in the <MACMethod> element of the <KeyContainer> element. The MAC in the <MACMethod> element of the <KeyContainer> element. The MAC
key MUST be a randomly generated key by the sender, be pre-agreed key MUST be a randomly generated key by the sender, be pre-agreed
between the receiver and the sender, or be set by the application upon between the receiver and the sender, or be set by the
protocol that carries the PSKC document. It is RECOMMENDED that the application protocol that carries the PSKC document. It is
sender generates a random MAC key. When the sender generates such a RECOMMENDED that the sender generate a random MAC key. When the
random MAC key, the MAC key material MUST be encrypted with the same sender generates such a random MAC key, the MAC key material MUST be
encryption key specified in <EncryptionKey> element of the key encrypted with the same encryption key specified in <EncryptionKey>
container. The encryption method and encrypted value MUST be set element of the key container. The encryption method and encrypted
respectively in the <EncryptionMethod> element and the <CipherData> value MUST be set in the <EncryptionMethod> element and the
element of the <MACKey> element in the <MACMethod> element. The <CipherData> element, respectively, of the <MACKey> element in the
<MACKeyReference> element of the <MACMethod> element MAY be used to <MACMethod> element. The <MACKeyReference> element of the
indicate a pre-shared MAC key or a provisioning protocol derived MAC <MACMethod> element MAY be used to indicate a pre-shared MAC key or a
key. For systems implementing PSKC it is RECOMMENDED to implement provisioning protocol derived MAC key. For systems implementing
the HMAC-SHA1 (with the URI of PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of
'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC 'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC
algorithms that can optionally be implemented are: algorithms that can optionally be implemented are:
Algorithm | Uniform Resource Locator (URL) Algorithm | Uniform Resource Locator (URL)
---------------+----------------------------------------------------- ---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224 HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
6.2. Encryption based on Passphrase-based Keys 6.2. Encryption Based on Passphrase-Based Keys
Figure 7 shows an example that illustrates the encryption of the Figure 7 shows an example that illustrates the encryption of the
content of the <Secret> element using passphrase based key derivation content of the <Secret> element using passphrase-based key derivation
(PBKDF2) to derive the encryption key as defined in [PKCS5]. When (PBKDF2) to derive the encryption key as defined in [PKCS5]. When
using passphrase based key derivation, the <DerivedKey> element using passphrase-based key derivation, the <DerivedKey> element
defined in XML Encryption v1.1 [XMLENC11] MUST be used to specify the defined in XML Encryption Version 1.1 [XMLENC11] MUST be used to
passphrased-based key. A <DerivedKey> element is set as the child specify the passphrased-based key. A <DerivedKey> element is set as
element of <EncryptionKey> element of the key container. the child element of <EncryptionKey> element of the key container.
The <DerivedKey> element is used to specify the key derivation The <DerivedKey> element is used to specify the key derivation
function and related parameters. The encryption algorithm, in this function and related parameters. The encryption algorithm, in this
example AES-128-CBC ( URI example, AES-128-CBC (URI
'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the
'Algorithm' attribute of <EncryptionMethod> element used inside the 'Algorithm' attribute of <EncryptionMethod> element used inside the
encrypted data elements. encrypted data elements.
When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11: When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11:
KeyDerivationMethod> element MUST be set to the URI KeyDerivationMethod> element MUST be set to the URI
'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The
<xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params> <xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params>
child element to indicate the PBKDF2 parameters, such as salt and child element to indicate the PBKDF2 parameters, such as salt and
iteration count. iteration count.
skipping to change at page 31, line 18 skipping to change at page 27, line 48
Iteration Count: 1000 Iteration Count: 1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581 MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
OTP Secret: 12345678901234567890 OTP Secret: 12345678901234567890
The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41". The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41".
The initialization vector (IV) is The initialization vector (IV) is
"0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to "0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to
encrypt the randomly chosen MAC key. A different IV can be used, encrypt the randomly chosen MAC key. A different IV can be used, say
say, "0xd864d39cbc0cdc8e1ee483b9164b9fa0" in the example. The "0xd864d39cbc0cdc8e1ee483b9164b9fa0", in the example. The encryption
encryption with algorithm "AES-128-CBC" follows the specification with algorithm "AES-128-CBC" follows the specification defined in
defined in [XMLENC]. [XMLENC].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer <pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
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#" Version="1.0"> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey> <pskc:EncryptionKey>
<xenc11:DerivedKey> <xenc11:DerivedKey>
skipping to change at page 32, line 48 skipping to change at page 29, line 29
</xenc:CipherData> </xenc:CipherData>
</pskc:EncryptedValue> </pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w= <pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC> </pskc:ValueMAC>
</pskc:Secret> </pskc:Secret>
</pskc:Data> </pskc:Data>
</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"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001" id="KC0001"
Version="1.0"> Version="1.0">
<EncryptionKey> <EncryptionKey>
<ds:X509Data> <ds:X509Data>
skipping to change at page 34, line 22 skipping to change at page 30, line 51
</EncryptedValue> </EncryptedValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 8: Example of a PSKC Document using Encryption based on Figure 8: Example of a PSKC Document Using Encryption Based on
Asymmetric Keys Asymmetric Keys
For systems implementing PSKC it is RECOMMENDED to implement the For systems implementing PSKC, it is RECOMMENDED to implement the
RSA-1.5 algorithm, identified by the URI RSA-1.5 algorithm, identified by the URI
'http://www.w3.org/2001/04/xmlenc#rsa-1_5'. 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
Some of the asymmetric encryption algorithms that can optionally be Some of the asymmetric encryption algorithms that can optionally be
implemented are: implemented are:
Algorithm | Uniform Resource Locator (URL) Algorithm | Uniform Resource Locator (URL)
------------------+------------------------------------------------- ------------------+-------------------------------------------------
RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
6.4. Padding of Encrypted Values for Non-Padded Encryption Algorithms 6.4. Padding of Encrypted Values for Non-Padded Encryption Algorithms
Padding of encrypted values (for example the key secret value) is Padding of encrypted values (for example, the key secret value) is
required when key protection algorithms are used that do not support required when key protection algorithms are used that do not support
embedded padding and the value to be encrypted is not a multiple of embedded padding and the value to be encrypted is not a multiple of
the encryption algorithm cypher block length. the encryption algorithm cipher block length.
For example, when transmitting a HOTP key (20 bytes long) protected For example, when transmitting an HOTP key (20 bytes long) protected
with the AES algorithm in CBC mode (8 byte block cypher), padding is with the AES algorithm in CBC mode (8-byte block cipher), padding is
required since 20 bytes are not a multiple of the 8 byte block required since its length is not a multiple of the 8-byte block
length. length.
In these cases, for systems implementing PSKC it is RECOMMENDED to In these cases, for systems implementing PSKC, it is RECOMMENDED to
pad the value before encryption using PKCS5 padding as described in pad the value before encryption using PKCS #5 padding as described in
[PKCS5]. [PKCS5].
7. Digital Signature 7. Digital Signature
PSKC allows a digital signature to be added to the XML document, as a PSKC allows a digital signature to be added to the XML document, as a
child element of the <KeyContainer> element. The description of the child element of the <KeyContainer> element. The description of the
XML digital signature can be found in [XMLDSIG]. XML digital signature can be found in [XMLDSIG].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer <KeyContainer
skipping to change at page 37, line 9 skipping to change at page 33, line 9
</ds:KeyInfo> </ds:KeyInfo>
</Signature> </Signature>
</KeyContainer> </KeyContainer>
Figure 9: Digital Signature Example Figure 9: Digital Signature Example
8. Bulk Provisioning 8. Bulk Provisioning
The functionality of bulk provisioning can be accomplished by The functionality of bulk provisioning can be accomplished by
repeating the <KeyPackage> element multiple times within the repeating the <KeyPackage> element multiple times within the
<KeyContainer> element indicating that multiple keys are provided to <KeyContainer> element, indicating that multiple keys are provided to
different devices or cryptomodules. The <EncryptionKey> element then different devices or cryptographic modules. The <EncryptionKey>
applies to all <KeyPackage> elements. When provisioning multiple element then applies to all <KeyPackage> elements. When provisioning
keys to the same device the <KeyPackage> element is repeated but the multiple keys to the same device, the <KeyPackage> element is
enclosed <DeviceInfo> element will contain the same sub-elements that repeated, but the enclosed <DeviceInfo> element will contain the same
uniquely identify the single device (for example the keys for the sub-elements that uniquely identify the single device (for example,
device identified by SerialNo='9999999' in the example below). the keys for the device identified by SerialNo='9999999' in the
example below).
Figure 10 shows an example utilizing these capabilities. Figure 10 shows an example utilizing these capabilities.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage> <KeyPackage>
<DeviceInfo> <DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer> <Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo> <SerialNo>654321</SerialNo>
skipping to change at page 40, line 10 skipping to change at page 35, line 46
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
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, a new version number has to be allocated to
refer to the new specification version. The version number is refer to the new specification. The version number is carried
carried inside the 'Version' attribute, as described in Section 4, inside the 'Version' attribute, as described in Section 4, the
the numbering scheme MUST follow Section 1.2, and rules for numbering scheme MUST follow Section 1.2, and rules for
extensibililty are defined in Section 12. extensibility 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 on the type of XML element, 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
added where XML extension points have been defined (see "<xs: added where XML extension points have been defined (see "<xs:
anyAttribute namespace="##other"/>" in Section 11). anyAttribute namespace="##other"/>" in Section 11).
New PSKC Algorithm Profiles: This document defines two PSKC New PSKC Algorithm Profiles: This document defines two PSKC
algorithm profiles, see Section 10. The following informational algorithm profiles, see Section 10. The following informational
document describes additional profiles [PSKC-ALGORITHM-PROFILES]. document describes additional profiles [PSKC-ALGORITHM-PROFILES].
Further PSKC algorithm profiles can be registered as described in Further PSKC algorithm profiles can be registered as described in
Section 12.4. Section 12.4.
Algorithm URIs: Section 6 defines how keys and related data can be Algorithm URIs: Section 6 defines how keys and related data can be
protected. A number of algorithms can be used. The use of new protected. A number of algorithms can be used. New algorithms
algorithms can be used by pointing to a new algorithm URI. can be used by pointing to a new algorithm URI.
Policy: Section 5 defines policies that can be attached to a key and Policy: Section 5 defines policies that can be attached to a key and
keying related data. The <Policy> element is one such item that keying-related data. The <Policy> element is one such item that
allows to restrict the use of the key to certain functions, such allows implementers to restrict the use of the key to certain
as "OTP usage only". Further values may be registered as functions, such as "OTP usage only". Further values may be
described in Section 12. registered as 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
URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
Algorithm Definition: [HOTP] Algorithm Definition: [HOTP]
Identifier Definition: (this RFC) Identifier Definition: (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Deprectaed: FALSE Deprecated: 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. metadata for the key.
The following additional constraints apply: The following additional constraints apply:
+ The value of the <Secret> element MUST contain key material + The value of the <Secret> element MUST contain key material
with a length of at least 16 octets (128 bits), if it is with a length of at least 16 octets (128 bits), if it is
present. present.
+ The <ResponseFormat> element MUST have the 'Format' + The <ResponseFormat> element MUST have the 'Format'
attribute set to "DECIMAL", and the 'Length' attribute MUST attribute set to "DECIMAL", and the 'Length' attribute MUST
indicate a length value between 6 and 9 (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. PIN 10.2. PIN
Common Name: PIN Common Name: PIN
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
Algorithm Definition: (this RFC) Section 5.1 Algorithm Definition: (this RFC) Section 5.1
Identifier Definition (this RFC) Identifier Definition (this RFC)
skipping to change at page 42, line 16 skipping to change at page 37, line 43
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
Algorithm Definition: (this RFC) Section 5.1 Algorithm Definition: (this RFC) Section 5.1
Identifier Definition (this RFC) Identifier Definition (this RFC)
Registrant Contact: IESG Registrant Contact: IESG
Deprectaed: FALSE Deprecated: 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
11. XML Schema 11. XML Schema
This section defines the XML schema for PSKC. This section defines the XML schema for PSKC.
skipping to change at page 50, line 4 skipping to change at page 44, line 23
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
</xs:choice> </xs:choice>
<xs:any namespace="##other" <xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/> processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
<xs:element name="KeyContainer" <xs:element name="KeyContainer"
type="pskc:KeyContainerType"/> type="pskc:KeyContainerType"/>
</xs:schema> </xs:schema>
12. IANA Considerations 12. IANA Considerations
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 contains the registration of a new media 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
Required parameters: There is no required parameter. 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: Please refer to Section 13 of RFCXXXX [NOTE Security considerations: Please refer to Section 13 of RFC 6030.
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of
this specification.]
Interoperability considerations: None Interoperability considerations: None
Published specification: RFC 6030.
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Applications which use this media type: This media type is being
replace XXXX with the RFC number of this specification.] used as a symmetric key container format for transport and
provisioning of symmetric keys (One-Time Password (OTP) shared
Applications which use this media type: This MIME type is being used secrets or symmetric cryptographic keys) to different types of
as a symmetric key container format for transport and provisioning strong authentication devices. As such, it is used for key
of symmetric keys (One Time Password (OTP) shared secrets or provisioning systems.
symmetric cryptographic keys) to different types of strong
authentication devices. As such, it is used for key provisioning
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 to contact for further information: Personal and email address to contact for further information:
skipping to change at page 51, line 32 skipping to change at page 45, line 48
URI: urn:ietf:params:xml:schema:keyprov:pskc URI: urn:ietf:params:xml:schema:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer
(Philip.Hoyer@actividentity.com). (Philip.Hoyer@actividentity.com).
XML Schema: The XML schema to be registered is contained in XML Schema: The XML schema to be registered is contained in
Section 11. Its first line is Section 11. Its first line is
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
and its last line is and its last line is
</xs:schema> </xs:schema>
12.3. URN Sub-Namespace Registration 12.3. URN Sub-Namespace Registration
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:keyprov:pskc URI: urn:ietf:params:xml:ns:keyprov:pskc
skipping to change at page 52, line 18 skipping to change at page 46, line 31
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title> <title>PSKC Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for PSKC</h1> <h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2> <h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt">
[NOTE TO IANA/RFC-EDITOR: RFC 6030</a>.</p>
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body> </body>
</html> </html>
END END
12.4. PSKC Algorithm Profile Registry 12.4. PSKC Algorithm Profile Registry
This specification requests the creation of a new IANA registry for IANA has created a registry for PSKC algorithm profiles in accordance
PSKC algorithm profiles in accordance with the principles set out in with the principles set out in RFC 5226 [RFC5226].
RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry, IANA maintains 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.
URI: The URI 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 add a pointer to the specification
specification containing information about the PSKC algorithm containing information about the PSKC algorithm profile
profile registration. 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: TRUE if this entry has been deprecated based on expert
deprecated and SHOULD not be used in any new implementations. approval and SHOULD not be used in any new implementations.
Otherwise FALSE. 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) 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
Specification Required as per RFC 5226 [RFC5226]. Updates can be Specification Required as per RFC 5226 [RFC5226]. Updates can be
provided based on expert approval only. Based on expert approval, it provided based on expert approval only. Based on expert approval, it
is possible to mark entries as "deprecated". A designated expert is possible to mark entries as "deprecated". A designated expert
will be appointed by the IESG. will be appointed by the IESG.
IANA is asked to add two initial values to the registry based on the IANA has added two initial values to the registry based on the
algorithm profiles described in Section 10. algorithm profiles described in Section 10.
12.5. PSKC Version Registry 12.5. PSKC Version Registry
IANA is requested to create a registry for PSKC version numbers. The IANA has created a registry for PSKC version numbers. The registry
registry has the following structure: has the following structure:
PSKC Version | Specification PSKC Version | Specification
+---------------------------+---------------- +---------------------------+----------------
| 1.0 | [This document] | 1.0 | RFC 6030
Standards action is required to define new versions of PSKC. It is Standards action is required to define new versions of PSKC. It is
not envisioned to deprecate, delete, or modify existing PSKC not envisioned to deprecate, delete, or modify existing PSKC
versions. versions.
12.6. Key Usage Registry 12.6. Key Usage Registry
IANA is requested to create a registry for key usage. A description IANA has created a registry for key usage. A description of the
of the 'KeyUsage' element can be found in Section 5. <KeyUsage> element can be found in Section 5.
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Key Usage: The identifier of the Key Usage. Key Usage: The identifier of the Key Usage.
Specification: IANA will be asked to add a pointer to the Specification: IANA will add a pointer to the specification
specification containing information about the semantics of a new containing information about the semantics of a new Key Usage
Key Usage registration. registration.
Deprecated: TRUE if based on expert approval this entry has been Deprecated: TRUE if this entry has been deprecated based on expert
deprecated and SHOULD not be used in any new implementations. approval and SHOULD not be used in any new implementations.
Otherwise FALSE. Otherwise, FALSE.
ANA is asked to add an initial value to the registry: IANA has added these initial values to the registry:
Key Usage | Specification | Deprecated Key Usage | Specification | Deprecated
+---------------+------------------------------+----------- +---------------+------------------------------+-----------
| OTP | [Section 5 of this document] | FALSE | OTP | [Section 5 of this document] | FALSE
| CR | [Section 5 of this document] | FALSE | CR | [Section 5 of this document] | FALSE
| Encrypt | [Section 5 of this document] | FALSE | Encrypt | [Section 5 of this document] | FALSE
| Integrity | [Section 5 of this document] | FALSE | Integrity | [Section 5 of this document] | FALSE
| Verify | [Section 5 of this document] | FALSE | Verify | [Section 5 of this document] | FALSE
| Unlock | [Section 5 of this document] | FALSE | Unlock | [Section 5 of this document] | FALSE
| Decrypt | [Section 5 of this document] | FALSE | Decrypt | [Section 5 of this document] | FALSE
skipping to change at page 55, line 12 skipping to change at page 48, line 49
entries as "deprecated". A designated expert will be appointed by entries as "deprecated". A designated expert will be appointed by
the IESG. the IESG.
13. Security Considerations 13. Security Considerations
The portable symmetric key container (PSKC) carries sensitive The portable symmetric key container (PSKC) carries sensitive
information (e.g., cryptographic keys) and may be transported across information (e.g., cryptographic keys) and may be transported across
the boundaries of one secure perimeter to another. For example, a the boundaries of one secure perimeter to another. For example, a
container residing within the secure perimeter of a back-end container residing within the secure perimeter of a back-end
provisioning server in a secure room may be transported across the provisioning server in a secure room may be transported across the
internet to an end-user device attached to a personal computer. This Internet to an end-user device attached to a personal computer. This
means that special care MUST be taken to ensure the confidentiality, means that special care MUST be taken to ensure the confidentiality,
integrity, and authenticity of the information contained within. integrity, and authenticity of the information contained within.
13.1. PSKC 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 key data payload encryption. the cryptographic algorithm for key data payload encryption. A
Symmetric cryptographic cipher SHOULD be used - the longer the symmetric cryptographic cipher SHOULD be used -- the longer the
cryptographic key, the stronger the protection. Please see cryptographic key, the stronger the protection. Please see
Section 6.1 for recommendations of key data payload protection using Section 6.1 for recommendations of key data payload protection using
symmetric cryptographic ciphers. In cases where the exchange of key symmetric cryptographic ciphers. In cases where the exchange of key
encryption keys between the sender and the receiver is not possible, encryption keys between the sender and the receiver is not possible,
asymmetric encryption of the key data payload may be employed, see asymmetric encryption of the key data payload may be employed, see
Section 6.3 . Similarly to symmetric key cryptography, the stronger Section 6.3. Similar to symmetric key cryptography, the stronger the
the asymmetric key, the more secure the protection is. asymmetric key, the more secure the protection.
If the key data payload is encrypted with a method that uses one of If the key data payload is encrypted with a method that uses one of
the password-based encryption methods (PBE methods) detailed in the password-based encryption methods (PBE methods) detailed in
Section 6.2, the key data payload may be subjected to password Section 6.2, the key data payload may be subjected to password
dictionary attacks to break the encryption password and recover the dictionary attacks to break the encryption password and recover the
information. Standard security best practices for selection of information. Standard security best practices for selection of
strong encryption passwords apply. strong encryption passwords apply.
Additionally, it is strongly RECOMMENDED that practical Additionally, it is strongly RECOMMENDED that practical
implementations use PBESalt and PBEIterationCount when PBE encryption implementations use PBESalt and PBEIterationCount when PBE encryption
is used. A different PBESalt value per PSKC SHOULD be used for best is used. A different PBESalt value per PSKC SHOULD be used for best
protection. protection.
The second approach to protecting the confidentiality of the key data The second approach to protecting the confidentiality of the key data
is based on using lower layer security mechanisms (e.g., [TLS], is based on using lower-layer security mechanisms (e.g., [TLS],
[IPSec]). The secure connection established between the source [IPsec]). The secure connection established between the source
secure perimeter (the provisioning server from the example above) and secure perimeter (the provisioning server from the example above) and
the target perimeter (the device attached to the end-user computer) the target perimeter (the device attached to the end-user computer)
utilizes encryption to protect the messages that travel across that utilizes encryption to protect the messages that travel across that
connection. No key data payload encryption is required in this mode. connection. No key data payload encryption is required in this mode.
Secure connections that encrypt and digest each message provide an Secure connections that encrypt and digest each message provide an
extra measure of security. extra measure of security.
Because of the fact that the plain text PSKC is protected only by the Because of the fact that the plaintext PSKC is protected only by the
transport layer security, practical implementation MUST ensure transport layer security, practical implementation MUST ensure
protection against man-in-the-middle attacks. Authenticating the protection against man-in-the-middle attacks. Authenticating the
secure channel end-points is critically important for eliminating secure channel endpoints is critically important for eliminating
intruders that may compromise the confidentiality of the PSKC. intruders that may compromise the confidentiality of the PSKC.
13.2. PSKC Integrity 13.2. PSKC Integrity
The PSKC provides a mean to guarantee the integrity of the The PSKC provides means to guarantee the integrity of the information
information it contains through digital signatures. It is it contains through the use of digital signatures. It is RECOMMENDED
RECOMMENDED that for best security practices, the digital signature that for best security practices, the digital signature of the
of the container encompasses the entire PSKC.This provides assurances container encompasses the entire PSKC. This provides assurances for
for the integrity of all attributes. It also allows verification of the integrity of all attributes. It also allows verification of the
the integrity of a given PSKC even after the container is delivered 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. PSKC Authenticity 13.3. PSKC Authenticity
The digital signature of the PSKC is the primary way of showing its The digital signature of the PSKC is the primary way of showing its
authenticity. The recipient of the container SHOULD 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 pre-loaded public key or certificate.
Note that the digital signature of the PSKC can be checked even after Note that the digital signature of the PSKC can be checked even after
the container has been delivered through the secure channel of the container has been delivered through the secure channel of
communication. communication.
Authenticity guarantee may be provided by [TLS] or [IPSec]. However, Authenticity guarantee may be provided by [TLS] or [IPsec]. However,
no authenticity verification is possible once the container is no authenticity verification is possible once the container is
delivered at the recipient end. Since the TLS endpoints could differ delivered at the recipient end. Since the TLS endpoints could differ
from the key provisioning endpoints, this solution is weaker than the from the key provisioning endpoints, this solution is weaker than the
previous solution that relies on a digital signature of the PSKC. previous solution that relies on a digital signature of the 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 document 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 Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea Siddhart Bajaj, Stu Vaeth, 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 review in January 2009.
2009. We would also like to thank Anders Rundgren for triggering the We would also like to thank Anders Rundgren for triggering the
discussion regarding to the selection of encryption algorithms (KW- discussion regarding to the selection of encryption algorithms
AES-128 vs. AES-128-CBC) and his input on the keyed message digest (KW-AES-128 vs. AES-128-CBC) and his input on the keyed message
computation. 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
[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>.
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced [FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced
Encryption Standard (AES)", November 2001. Encryption Standard (AES)", November 2001.
[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and [HOTP] M'Raihi, 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.
[IANAPENREG] [IANAPENREG]
IANA, "IANA Private Enterprise Number Registry", IANA, "Private Enterprise Numbers", <http://www.iana.org>.
April 2009,
<http://www.iana.org/assignments/enterprise-numbers/>.
[ISOIEC7812] [ISOIEC7812]
ISO, "ISO/IEC 7812-1:2006 Identification cards -- ISO, "ISO/IEC 7812-1:2006 Identification cards --
Identification of issuers -- Part 1: Numbering system", Identification of issuers -- Part 1: Numbering system",
October 2006, <http://www.iso.org/iso/iso_catalogue/ October 2006, <http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=39698>. catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", [OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)",
April 2009, April 2009,
<http://www.openauthentication.org/oath-id/prefixes/>. <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, March 1999,
URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999. <http://www.rsasecurity.com/rsalabs/pkcs/>.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement 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.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
September 2009.
[SP800-67] [SP800-67]
National Institute of Standards, "NIST Special Publication National Institute of Standards, "NIST Special Publication
800-67 Version 1.1: Recommendation for the Triple Data 800-67 Version 1.1: Recommendation for the Triple Data
Encryption Algorithm (TDEA) Block Cipher", NIST Special Encryption Algorithm (TDEA) Block Cipher", NIST Special
Publication 800-67, May 2008. Publication 800-67, May 2008.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", [XMLDSIG] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, Syntax and Processing", World Wide Web Consortium
W3C Recommendation, February 2002. FirstEdition REC-xmldsig-core-20020212, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, W3C Recommendation, December 2002,
W3C Recommendation, December 2002. <http://www.w3.org/TR/xmlenc-core/>.
[XMLENC11] [XMLENC11]
Eastlake, D., "XML Encryption Syntax and Processing Reagle, J. and D. Eastlake, "XML Encryption Syntax and
Version 1.1.", Processing Version 1.1", World Wide Web Consortium WD WD-
URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730, xmlenc-core1-20090730, July 2009,
W3C Recommendation, July 2009. <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.
16.2. Informative References 16.2. Informative References
[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, [IPsec] Kent, S. and K. Seo, "Security Architecture for the
"Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/
internet-drafts/draft-ietf-keyprov-dskpp-07.txt,
February 2009.
[IPSec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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. <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", Work in Progress, May 2010.
http://www.ietf.org/id/
draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt,
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 Identifier (URI): Generic Syntax", STD 66,
January 2005. RFC 3986, 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.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[XMLNS] "Namespaces in XML", W3C Recommendation , [XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in
URL: http://www.w3.org/TR/1999/REC-xml-names-19990114, XML", World Wide Web Consortium FirstEdition REC-xml-
January 1999. names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
Appendix A. Use Cases Appendix A. Use Cases
This section describes a comprehensive list of use cases that This section describes a comprehensive list of use cases that
inspired the development of this specification. These requirements inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design. were used to derive the primary requirement that drove the design.
These requirements are covered in the next section. These requirements are covered in the next section.
These use cases also help in understanding the applicability of this These use cases also help in understanding the applicability of this
specification to real world situations. specification to real-world situations.
A.1. Online Use Cases A.1. Online Use Cases
This section describes the use cases related to provisioning the keys This section describes the use cases related to provisioning the keys
using an online provisioning protocol such as [DSKPP]. using an online provisioning protocol.
A.1.1. Transport of keys from Server to Cryptographic Module A.1.1. Transport of Keys from Server to Cryptographic Module
For example, a mobile device user wants to obtain a symmetric key for For example, a mobile device user wants to obtain a symmetric key for
use with a Cryptographic Module on the device. The Cryptographic use with a cryptographic module on the device. The cryptographic
Module from vendor A initiates the provisioning process against a module from vendor A initiates the provisioning process against a
provisioning system from vendor B using a standards-based provisioning system from vendor B using a standards-based
provisioning protocol such as [DSKPP]. The provisioning entity provisioning protocol. The provisioning entity delivers one or more
delivers one or more keys in a standard format that can be processed keys in a standard format that can be processed by the mobile device.
by the mobile device.
For example, in a variation of the above, instead of the user's For example, in a variation of the above, instead of the user's
mobile phone, a key is provisioned in the user's soft token mobile phone, a key is provisioned in the user's soft token
application on a laptop using a network-based online protocol. As application on a laptop using a network-based online protocol. As
before, the provisioning system delivers a key in a standard format before, the provisioning system delivers a key in a standard format
that can be processed by the soft token on the PC. that can be processed by the soft token on the PC.
For example, the end-user or the key issuer wants to update or For example, the end user or the key issuer wants to update or
configure an existing key in the Cryptographic Module and requests a configure an existing key in the cryptographic module and requests a
replacement key container. The container may or may not include a replacement key container. The container may or may not include a
new key and may include new or updated key attributes such as a new new key and may include new or updated key attributes such as a new
counter value in HOTP key case, a modified response format or length, counter value in HOTP key case, a modified response format or length,
a new friendly name, etc. a new friendly name, etc.
A.1.2. Transport of keys from Cryptographic Module to Cryptographic A.1.2. Transport of Keys from Cryptographic Module to Cryptographic
Module Module
For example, a user wants to transport a key from one Cryptographic For example, a user wants to transport a key from one cryptographic
Module to another. There may be two cryptographic modules, one on a module to another. There may be two cryptographic modules, one on a
computer one on a mobile phone, and the user wants to transport a key computer and one on a mobile phone, and the user wants to transport a
from the computer to the mobile phone. The user can export the key key from the computer to the mobile phone. The user can export the
and related data in a standard format for input into the other key and related data in a standard format for input into the other
Cryptographic Module. cryptographic module.
A.1.3. Transport of keys from Cryptographic Module to Server A.1.3. Transport of Keys from Cryptographic Module to Server
For example, a user wants to activate and use a new key and related For example, a user wants to activate and use a new key and related
data against a validation system that is not aware of this key. This data against a validation system that is not aware of this key. This
key may be embedded in the Cryptographic Module (e.g. SD card, USB key may be embedded in the cryptographic module (e.g., a Secure
drive) that the user has purchased at the local electronics retailer. Digital (SD) card, USB drive) that the user has purchased at the
Along with the Cryptographic Module, the user may get the key on a CD local electronics retailer. Along with the cryptographic module, the
or a floppy in a standard format. The user can now upload via a user may get the key on a CD or a floppy in a standard format. The
secure online channel or import this key and related data into the user can now upload via a secure online channel or import this key
new validation system and start using the key. and related data into the new validation system and start using the
key.
A.1.4. Server to server Bulk import/export of keys A.1.4. Server-to-Server Bulk Import/Export of Keys
From time to time, a key management system may be required to import From time to time, a key management system may be required to import
or export keys in bulk from one entity to another. or export keys in bulk from one entity to another.
For example, instead of importing keys from a manufacturer using a For example, instead of importing keys from a manufacturer using a
file, a validation server may download the keys using an online file, a validation server may download the keys using an online
protocol. The keys can be downloaded in a standard format that can protocol. The keys can be downloaded in a standard format that can
be processed by a validation system. be processed by a validation system.
For example, in a variation of the above, an Over-The-Air (OTA) key For example, in a variation of the above, an Over-The-Air (OTA) key
provisioning gateway that provisions keys to mobile phones may obtain provisioning gateway that provisions keys to mobile phones may obtain
key material from a key issuer using an online protocol. The keys key material from a key issuer using an online protocol. The keys
are delivered in a standard format that can be processed by the key are delivered in a standard format that can be processed by the key
provisioning gateway and subsequently sent to the end-user's mobile provisioning gateway and subsequently sent to the mobile phone of the
phone. end user.
A.2. Offline Use Cases A.2. Offline Use Cases
This section describes the use cases relating to offline transport of This section describes the use cases relating to offline transport of
keys from one system to another, using some form of export and import keys from one system to another, using some form of export and import
model. model.
A.2.1. Server to server Bulk import/export of keys A.2.1. Server-to-Server Bulk Import/Export of Keys
For example, Cryptographic Modules such as OTP authentication tokens, For example, cryptographic modules, such as OTP authentication
may have their symmetric keys initialized during the manufacturing tokens, may have their symmetric keys initialized during the
process in bulk, requiring copies of the keys and algorithm data to manufacturing process in bulk, requiring copies of the keys and
be loaded into the authentication system through a file on portable algorithm data to be loaded into the authentication system through a
media. The manufacturer provides the keys and related data in the file on portable media. The manufacturer provides the keys and
form of a file containing records in standard format, typically on a related data in the form of a file containing records in standard
CD. Note that the token manufacturer and the vendor for the format, typically on a CD. Note that the token manufacturer and the
validation system may be the same or different. Some crypto modules vendor for the validation system may be the same or different. Some
will allow local PIN management (the device will have a PIN pad) crypto modules will allow local PIN management (the device will have
hence random initial PINs set at manufacturing should be transmitted a PIN pad); hence, random initial PINs set at manufacturing should be
together with the respective keys they protect. transmitted together with the respective keys they protect.
For example, an enterprise wants to port keys and related data from For example, an enterprise wants to port keys and related data from
an existing validation system A into a different validation system B. an existing validation system A into a different validation system B.
The existing validation system provides the enterprise with a The existing validation system provides the enterprise with a
functionality that enables export of keys and related data (e.g. for functionality that enables export of keys and related data (e.g., for
OTP authentication tokens) in a standard format. Since the OTP OTP authentication tokens) in a standard format. Since the OTP
tokens are in the standard format, the enterprise can import the tokens are in the standard format, the enterprise can import the
token records into the new validation system B and start using the token records into the new validation system B and start using the
existing tokens. Note that the vendors for the two validation existing tokens. Note that the vendors for the two validation
systems may be the same or different. systems may be the same or different.
Appendix B. Requirements Appendix B. Requirements
This section outlines the most relevant requirements that are the This section outlines the most relevant requirements that are the
basis of this work. Several of the requirements were derived from basis of this work. Several of the requirements were derived from
use cases described above. use cases described above.
R1: The format MUST support transport of multiple types of R1: The format MUST support the transport of multiple types of
symmetric keys and related attributes for algorithms including symmetric keys and related attributes for algorithms including
HOTP, other OTP, challenge-response, etc. HOTP, other OTP, Challenge/Response, etc.
R2: The format MUST handle the symmetric key itself as well of R2: The format MUST handle the symmetric key itself as well of
attributes that are typically associated with symmetric keys. attributes that are typically associated with symmetric keys.
Some of these attributes may be Some of these attributes may be
* Unique Key Identifier * Unique Key Identifier
* Issuer information * Issuer information
* Algorithm ID * Algorithm ID
skipping to change at page 65, line 36 skipping to change at page 56, line 46
* Issuer Name * Issuer Name
* Key friendly name * Key friendly name
* Event counter value (moving factor for OTP algorithms) * Event counter value (moving factor for OTP algorithms)
* Time value * Time value
R3: The format SHOULD support both offline and online scenarios. R3: The format SHOULD support both offline and online scenarios.
That is it should be serializable to a file as well as it That is, it should be serializable to a file as well as it
should be possible to use this format in online provisioning should be possible to use this format in online provisioning
protocols such as [DSKPP] protocols.
R4: The format SHOULD allow bulk representation of symmetric keys R4: The format SHOULD allow bulk representation of symmetric keys.
R5: The format SHOULD allow bulk representation of PINs related to R5: The format SHOULD allow bulk representation of PINs related to
specific keys specific keys.
R6: The format SHOULD be portable to various platforms. R6: The format SHOULD be portable to various platforms.
Furthermore, it SHOULD be computationally efficient to process. Furthermore, it SHOULD be computationally efficient to process.
R7: The format MUST provide appropriate level of security in terms R7: The format MUST provide an appropriate level of security in
of data encryption and data integrity. terms of data encryption and data integrity.
R8: For online scenarios the format SHOULD NOT rely on transport R8: For online scenarios, the format SHOULD NOT rely on transport
level security (e.g., SSL/TLS) for core security requirements. layer security (e.g., Secure Socket Layer/Transport Layer
Security (SSL/TLS)) for core security requirements.
R9: The format SHOULD be extensible. It SHOULD enable extension R9: The format SHOULD be extensible. It SHOULD enable extension
points allowing vendors to specify additional attributes in the points allowing vendors to specify additional attributes in the
future. future.
R10: The format SHOULD allow for distribution of key derivation data R10: The format SHOULD allow for distribution of key derivation data
without the actual symmetric key itself. This is to support without the actual symmetric key itself. This is to support
symmetric key management schemes that rely on key derivation symmetric key management schemes that rely on key derivation
algorithms based on a pre-placed master key. The key algorithms based on a pre-placed master key. The key
derivation data typically consists of a reference to the key, derivation data typically consists of a reference to the key,
rather than the key value itself. rather than the key value itself.
R11: The format SHOULD allow for additional lifecycle management R11: The format SHOULD allow for additional life cycle management
operations such as counter resynchronization. Such processes operations such as counter resynchronization. Such processes
require confidentiality between client and server, thus could require confidentiality between client and server, thus could
use a common secure container format, without the transfer of use a common secure container format, without the transfer of
key material. key material.
R12: The format MUST support the use of pre-shared symmetric keys to R12: The format MUST support the use of pre-shared symmetric keys to
ensure confidentiality of sensitive data elements. ensure confidentiality of sensitive data elements.
R13: The format MUST support a password-based encryption (PBE) R13: The format MUST support a password-based encryption (PBE)
[PKCS5] scheme to ensure security of sensitive data elements. [PKCS5] scheme to ensure security of sensitive data elements.
skipping to change at page 67, line 14 skipping to change at page 58, line 14
Authors' Addresses Authors' Addresses
Philip Hoyer Philip Hoyer
ActivIdentity, Inc. ActivIdentity, Inc.
117 Waterloo Road 117 Waterloo Road
London, SE1 8UL London, SE1 8UL
UK UK
Phone: +44 (0) 20 7960 0220 Phone: +44 (0) 20 7960 0220
Email: phoyer@actividentity.com EMail: phoyer@actividentity.com
Mingliang Pei Mingliang Pei
VeriSign, Inc. VeriSign, Inc.
487 E. Middlefield Road 487 E. Middlefield Road
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 650 426 5173 Phone: +1 650 426 5173
Email: mpei@verisign.com EMail: mpei@verisign.com
Salah Machani Salah Machani
Diversinet, Inc. Diversinet, Inc.
2225 Sheppard Avenue East 2225 Sheppard Avenue East
Suite 1801 Suite 1801
Toronto, Ontario M2J 5C2 Toronto, Ontario M2J 5C2
Canada Canada
Phone: +1 416 756 2324 Ext. 321 Phone: +1 416 756 2324 Ext. 321
Email: smachani@diversinet.com EMail: smachani@diversinet.com
 End of changes. 231 change blocks. 
592 lines changed or deleted 574 lines changed or added

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