draft-ietf-keyprov-pskc-04.txt   draft-ietf-keyprov-pskc-05.txt 
keyprov P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: April 26, 2010 VeriSign Expires: July 9, 2010 VeriSign
S. Machani S. Machani
Diversinet Diversinet
October 23, 2009 January 5, 2010
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-04 draft-ietf-keyprov-pskc-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010. This Internet-Draft will expire on July 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4.1. <Key>: Embedding Keying Material and Key Related 4.1. <Key>: Embedding Keying Material and Key Related
Information . . . . . . . . . . . . . . . . . . . . . . . 9 Information . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Transmission of supplementary Information . . . . . . . . 11 4.2. Transmission of supplementary Information . . . . . . . . 11
4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12 4.2.1. <DeviceInfo> Element: Unique Device Identification . . 12
4.2.2. <CryptoModuleInfo> Element: CryptoModule 4.2.2. <CryptoModuleInfo> Element: CryptoModule
Identification . . . . . . . . . . . . . . . . . . . . 13 Identification . . . . . . . . . . . . . . . . . . . . 13
4.2.3. <UserId> Element: User Identification . . . . . . . . 14 4.2.3. <UserId> Element: User Identification . . . . . . . . 14
4.2.4. <AlgorithmParameters> Element: Supplementary 4.2.4. <AlgorithmParameters> Element: Supplementary
Information for OTP and CR Algorithms . . . . . . . . 14 Information for OTP and CR Algorithms . . . . . . . . 14
4.3. Transmission of Key Derivation Values . . . . . . . . . . 16 4.3. Transmission of Key Derivation Values . . . . . . . . . . 16
5. Key policy - transmission of key usage policies and key 5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
PIN protection policy . . . . . . . . . . . . . . . . . . . . 18 6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 23
6. Key protection methods . . . . . . . . . . . . . . . . . . . . 23
6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23
6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29
6.4. Padding of encrypted values for non-padded encryption 6.4. Padding of Encrypted Values for Non-Padded Encryption
algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12.1. Content-type registration for 'application/pskc+xml' . . . 46 12.1. Content-type registration for 'application/pskc+xml' . . . 46
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49
13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 51 13.1. Payload Confidentiality . . . . . . . . . . . . . . . . . 51
13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 52 13.2. Payload Integrity . . . . . . . . . . . . . . . . . . . . 52
13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 52 13.3. Payload Authenticity . . . . . . . . . . . . . . . . . . . 52
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. Normative References . . . . . . . . . . . . . . . . . . . 55 16.1. Normative References . . . . . . . . . . . . . . . . . . . 55
16.2. Informative References . . . . . . . . . . . . . . . . . . 55 16.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57
A.1.1. Transport of keys from Server to Cryptographic A.1.1. Transport of keys from Server to Cryptographic
Module . . . . . . . . . . . . . . . . . . . . . . . . 57 Module . . . . . . . . . . . . . . . . . . . . . . . . 57
A.1.2. Transport of keys from Cryptographic Module to A.1.2. Transport of keys from Cryptographic Module to
skipping to change at page 4, line 8 skipping to change at page 4, line 8
Server . . . . . . . . . . . . . . . . . . . . . . . . 58 Server . . . . . . . . . . . . . . . . . . . . . . . . 58
A.1.4. Server to server Bulk import/export of keys . . . . . 58 A.1.4. Server to server Bulk import/export of keys . . . . . 58
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58
A.2.1. Server to server Bulk import/export of keys . . . . . 58 A.2.1. Server to server Bulk import/export of keys . . . . . 58
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
With increasing use of symmetric key based systems, such as With increasing use of symmetric key based systems, such as
encryption of data at rest or systems used for strong authentication encryption of data at rest, or systems used for strong
such as those based on one-time-password (OTP) and challenge response authentication, such as those based on one-time-password (OTP) and
(CR) mechanisms, there is a need for vendor interoperability and a challenge response (CR) mechanisms, there is a need for vendor
standard format for importing and exporting (provisioning) symmetric interoperability and a standard format for importing and exporting
keys. Traditionally, for example, vendors of authentication servers (provisioning) symmetric keys. For instance, traditionally, vendors
and service providers have used proprietary formats for importing and of authentication servers and service providers have used proprietary
exporting these keys into their systems, thus making it hard to use formats for importing and exporting these keys into their systems,
tokens from vendor "Foo" with a server from vendor "Bar". thus making it hard to use tokens from two different vendors.
This document defines a standardized XML-based key container, called This document defines a standardized XML-based key container, called
Portable Symmetric Key Container (PSKC), for transporting symmetric Portable Symmetric Key Container (PSKC), for transporting symmetric
keys and key related meta data. The document also specifies the keys and key related meta data. The document also specifies the
information elements that may be required when the symmetric key is information elements that are required when the symmetric key is
utilized for specific purposes, such as the initial counter in the utilized for specific purposes, such as the initial counter in the
MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also
requests the creation of an IANA registry for algorithm profiles requests the creation of an IANA registry for algorithm profiles
where algorithms, their related meta-data and PSKC transmission where algorithms, their meta-data and PSKC transmission profile can
profile can be recorded for centralised standardised reference. be recorded for centralised standardised reference.
1.1. Key Words 1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Versions 1.2. Versions
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.
1.3. Namespace Identifiers 1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers [RFC2396] to identify This document uses Uniform Resource Identifiers [RFC3986] to identify
resources, algorithms, and semantics. resources, algorithms, and semantics.
1.3.1. Defined Identifiers 1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined herein References to qualified elements in the PSKC schema defined herein
use the prefix "pskc". use the prefix "pskc".
skipping to change at page 7, line 28 skipping to change at page 7, line 28
and criteria to uniquely identify the device and criteria to uniquely identify the device
4. CryptoModuleInfo entity - representing the information about the 4. CryptoModuleInfo entity - representing the information about the
CryptoModule where the keys reside or are provisioned to CryptoModule where the keys reside or are provisioned to
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 meta-data related to the
key, where the element name is the name of the meta-data and its key, where the element name is the name of the meta-data and its
associated value is either in encrypted form (for example for associated value is either in encrypted form (for example for
Data element 'SECRET') or plaintext (for example for the Data Data element <Secret>) or plaintext (for example the Data element
element 'COUNTER') <Counter>)
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 8, line 44 skipping to change at page 8, 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 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.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
<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>
</DeviceInfo> </DeviceInfo>
<CryptoModuleInfo> <CryptoModuleInfo>
<Id>CM_ID_001</Id> <Id>CM_ID_001</Id>
</CryptoModuleInfo> </CryptoModuleInfo>
<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</Issuer> <Issuer>Issuer</Issuer>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
<AlgorithmParameters> <AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/> <ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters> </AlgorithmParameters>
<Data> <Data>
<Secret> <Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue> </PlainValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
<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.2.1. <DeviceInfo> Element: Unique Device Identification 4.2.1. <DeviceInfo> Element: Unique Device Identification
The <DeviceInfo> element uniquely identifies the device the The <DeviceInfo> element uniquely identifies the device the
<KeyPackage> is provisioned to. Since devices can come in different <KeyPackage> is provisioned to. Since devices can come in different
skipping to change at page 13, line 22 skipping to change at page 13, line 22
<Model>: This element describes the model of the device (e.g., one- <Model>: This element describes the model of the device (e.g., one-
button-HOTP-token-V1). button-HOTP-token-V1).
<IssueNo>: This element contains the issue number in case devices <IssueNo>: This element contains the issue number in case devices
with the same serial number that are distinguished by different with the same serial number that are distinguished by different
issue numbers. issue numbers.
<DeviceBinding>: This element 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 IMEI for the phone, or request using a device identifier, e.g., an International Mobile
an identifier for a class of identifiers, e.g., those for which Equipment Identity (IMEI) for the phone, or an identifier for a
the keys are protected by a TPM. class of identifiers, e.g., those for which the keys are protected
by a Trusted Platform Module (TPM).
<StartDate>: and <ExpiryDate>: These two elements indicate the start <StartDate>: and <ExpiryDate>: These two elements indicate the start
and end date of a device (such as the one on a payment card, used and end date of a device (such as the one on a payment card, used
when issue numbers are not printed on cards). The date MUST be when issue numbers are not printed on cards). The date MUST be
expressed in UTC form with no timezone component. Implementations expressed in UTC form with no timezone component. Implementations
SHOULD NOT rely on time resolution finer than milliseconds and SHOULD NOT rely on time resolution finer than milliseconds and
MUST NOT generate time instants that specify leap seconds. MUST NOT generate time instants that specify leap seconds.
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
skipping to change at page 16, line 21 skipping to change at page 16, line 21
unencoded value. unencoded value.
4.3. Transmission of Key Derivation Values 4.3. 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 agreed between the two
parties out of band. This element will then represent the unique 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 attributes card application personalisation profile id related to specific
present on a smart card application that have influence when attribute values present on a smart card application, that have
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], sending and receiving party would agree that KeyProfileId='1' [CAP], the sending and the receiving party would agree that
represents a certain set of values (e.g., Internet Authentication KeyProfileId='1' represents a certain set of values (e.g., Internet
Flag IAF set to a specific value). During transmission of the Authentication Flag IAF set to a specific value). During
KeyContainer, these values would not be transmitted as key attributes transmission of the KeyContainer, these values would not be
but only referred to via the <KeyProfileId> element set to the transmitted as key attributes but only referred to via the
specific agreed profile (in this case '1'). The receiving party can <KeyProfileId> element set to the specific agreed profile (in this
then associate all relevant key attributes contained in the out of case '1'). The receiving party can then associate all relevant key
band agreed profile with the imported keys. Often this methodology attributes contained in the out of band agreed profile with the
is used between a manufacturing service, run by company A and the imported keys. Often this methodology is used between a
validation service run by company B, to avoid repeated transmission manufacturing service, run by company A and the validation service
of the same set of key attribute values. run by company B, to avoid repeated transmission of the same 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 and no specific key value
(secret) is transported but only the reference to the external master (secret) is transported but only the reference to the external master
key is used (e.g., the PKCS#11 key label). key is used (e.g., the 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>
<Id>CM_ID_001</Id> <Id>CM_ID_001</Id>
</CryptoModuleInfo> </CryptoModuleInfo>
<Key Id="12345678" <Key Id="12345678"
skipping to change at page 17, line 41 skipping to change at page 17, line 41
<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 a 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 sending and receiving parties and element, values agreed between the sending and the receiving parties
identified by the KeyProfile 'keyProfile1' and an external agreed key and identified by the KeyProfile 'keyProfile1' and an externally
referenced by the label 'MasterKeyLabel'. agreed key referenced by the label 'MasterKeyLabel'.
5. Key policy - transmission of key usage policies and key PIN 5. Key Policy
protection policy
This section illustrates the functionality of the <Policy> element This section illustrates the functionality of the <Policy> element
within PSKC that allows policy to be attached to a key and its within PSKC that allows a key usage and key PIN protection policy to
related meta data. This element is a child element of the <Key> be attached to a specific key and its related meta data. This
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.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
'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' attribute, otherwise it
MUST be enforced on the server side. MUST be enforced on the server side.
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 clear text.
With the help of the <EncryptionKey> element, which is a child With the help of the <EncryptionKey> element, which is a child
element of the <KeyContainer> element, it is possible to encrypt keys element of the <KeyContainer> element, it is possible to encrypt keys
and associated information. The level of encryption is applied to and associated information. The level of encryption is applied to
the value of individual elements and the applied encryption algorithm the 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
skipping to change at page 23, line 27 skipping to change at page 23, line 27
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 AES128-CBC and PKCS5 Padding.
The plaintext value of <Secret> is The plaintext value of <Secret> is
'3132333435363738393031323334353637383930'. The name of the pre- '3132333435363738393031323334353637383930'. The name of the pre-
shared secret is "Example-Key1", 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 AES128-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
skipping to change at page 24, line 39 skipping to change at page 24, line 39
<Secret> <Secret>
<EncryptedValue> <EncryptedValue>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</EncryptedValue> </EncryptedValue>
<ValueMAC>aSRlEG1agUo0CS2dt/OvIAqQ6Co= <ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc=
</ValueMAC> </ValueMAC>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
skipping to change at page 25, line 42 skipping to change at page 25, line 42
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, a pre-shared one key MUST be a randomly generated key by the sender, be pre-agreed
between the receiver and the sender, or one set by an application between the receiver and the sender, or be set by the application
protocol that uses KeyContainer. It is recommended that a sender protocol that carries the PSKC document. It is RECOMMENDED that the
generates a random MAC key. When the sender generates such a random sender generates a random MAC key. When the sender generates such a
MAC key, the MAC key material MUST be encrypted with the same random MAC key, the MAC key material MUST be encrypted with the same
encryption key specified in <EncryptionKey> element of the key encryption key specified in <EncryptionKey> element of the key
container. The encryption method and encrypted value MUST be set container. The encryption method and encrypted value MUST be set
respectively in the <EncryptionMethod> element and the <CipherData> respectively in the <EncryptionMethod> element and the <CipherData>
element of the <MACKey> element in the <MACMethod> element. The element of the <MACKey> element in the <MACMethod> element. The
<MACKeyReference> element of the <MACMethod> element MAY be used to <MACKeyReference> element of the <MACMethod> element MAY be used to
indicate a pre-shared MAC key or a provisioning protocol derived MAC indicate a pre-shared MAC key or a provisioning protocol derived MAC
key. For systems implementing PSKC it is RECOMMENDED to implement key. For systems implementing PSKC it is RECOMMENDED to implement
the HMAC-SHA1 (with the URI of 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:
skipping to change at page 26, line 35 skipping to change at page 26, line 35
passphrased-based key. A <DerivedKey> element is set as the child passphrased-based key. A <DerivedKey> element is set as the child
element of <EncryptionKey> element of the key container. 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 attribute "Algorithm" of the element When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11:
<xenc11:KeyDerivationMethod> 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
element <xenc11:KeyDerivationMethod> 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.
When the encryption method uses a CBC mode that uses an explicit When the encryption method uses a CBC mode that uses an explicit
initialization vector (IV) other than a derived one, the IV MUST be initialization vector (IV) other than a derived one, the IV MUST be
passed by prepending it to the encrypted value. passed by prepending it to the encrypted value.
In the example below, the following data is used. In the example below, the following data is used.
Password: qwerty Password: qwerty
skipping to change at page 28, line 9 skipping to change at page 28, line 9
<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName> <xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
</xenc11:DerivedKey> </xenc11:DerivedKey>
</pskc:EncryptionKey> </pskc:EncryptionKey>
<pskc:MACMethod <pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey> <pskc:MACKey>
<xenc:EncryptionMethod <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData> <xenc:CipherData>
<xenc:CipherValue> <xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ 2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
SWJblA7Dzi031L6FNnUrcjsGGcQ==
</xenc:CipherValue> </xenc:CipherValue>
</xenc:CipherData> </xenc:CipherData>
</pskc:MACKey> </pskc:MACKey>
</pskc:MACMethod> </pskc:MACMethod>
<pskc:KeyPackage> <pskc:KeyPackage>
<pskc:DeviceInfo> <pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo> <pskc:SerialNo>987654321</pskc:SerialNo>
</pskc:DeviceInfo> </pskc:DeviceInfo>
<pskc:CryptoModuleInfo> <pskc:CryptoModuleInfo>
skipping to change at page 30, line 36 skipping to change at page 30, line 36
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 cypher block length.
For example, when transmitting a HOTP key (20 bytes long) protected For example, when transmitting a HOTP key (20 bytes long) protected
with the AES algorithm in CBC mode (8 byte block cypher), since 20 with the AES algorithm in CBC mode (8 byte block cypher), padding is
bytes are not a multiple of the 8 byte block length, padding is required since 20 bytes are not a multiple of the 8 byte block
required. 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 PKCS5 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].
skipping to change at page 33, line 13 skipping to change at page 33, line 13
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 cryptomodules. The <EncryptionKey> element then
applies to all <KeyPackage> elements. When provisioning multiple applies to all <KeyPackage> elements. When provisioning multiple
keys to the same device the <KeyPackage> element is repeated but the keys to the same device the <KeyPackage> element is repeated but the
enclosed <DeviceInfo> element will contain the same sub elements that enclosed <DeviceInfo> element will contain the same sub-elements that
uniquely identify the single device. uniquely identify the single device (for example 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 34, line 52 skipping to change at page 35, line 4
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue> </PlainValue>
</Secret> </Secret>
<Counter> <Counter>
<PlainValue>0</PlainValue> <PlainValue>0</PlainValue>
</Counter> </Counter>
</Data> </Data>
<Policy> <Policy>
<StartDate>2006-03-01T00:00:00Z</StartDate> <StartDate>2006-03-01T00:00:00Z</StartDate>
<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate> <ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
</Policy>
</Policy>
</Key> </Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="4" <Key Id="4"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp"> Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
<Issuer>Issuer</Issuer> <Issuer>Issuer</Issuer>
<AlgorithmParameters> <AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/> <ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters> </AlgorithmParameters>
<Data> <Data>
<Secret> <Secret>
<PlainValue> <PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
skipping to change at page 36, line 29 skipping to change at page 36, line 29
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
draft 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. The use of new
algorithms can be used by pointing to a new algorithm URI. algorithms 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 to restrict the use of the key to certain functions, such
skipping to change at page 37, line 29 skipping to change at page 37, line 29
Registrant Contact: IESG Registrant Contact: IESG
Profiling: Profiling:
The <KeyPackage> element MUST be present and the The <KeyPackage> element MUST be present and the
<ResponseFormat> element, which is a child element of the <ResponseFormat> element, which is a child element of the
<AlgorithmParameters> element, MUST be used to indicate the OTP <AlgorithmParameters> element, MUST be used to indicate the OTP
length and the value format. length and the value format.
The <Counter> element (see Section 4.1) MUST be provided as The <Counter> element (see Section 4.1) MUST be provided as
meta data for the key. meta-data for the key.
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. indicate a length value between 6 and 9 (inclusive).
+ The <PINPolicy> element MAY be present but the + The <PINPolicy> element MAY be present but the
'PINUsageMode' attribute cannot be set to "Algorithmic". 'PINUsageMode' attribute cannot be set to "Algorithmic".
An example can be found in Figure 3. An example can be found in Figure 3.
10.2. KEYPROV-PIN 10.2. KEYPROV-PIN
Common Name: KEYPROV-PIN Common Name: KEYPROV-PIN
Class: Symmetric static credential comparison Class: Symmetric static credential comparison
skipping to change at page 47, line 20 skipping to change at page 47, line 20
Author: This specification is a work item of the IETF KEYPROV Author: This specification is a work item of the IETF KEYPROV
working group, with mailing list address <keyprov@ietf.org>. working group, with mailing list address <keyprov@ietf.org>.
Change controller: The IESG <iesg@ietf.org> Change controller: The IESG <iesg@ietf.org>
12.2. XML Schema Registration 12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns: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
skipping to change at page 49, line 12 skipping to change at page 49, line 12
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.
PSKC Profiling: Information about PSKC XML elements and attributes PSKC Profiling: Information about PSKC XML elements and attributes
being used (or not used) with this specific profile of PSKC. being used (or not used) with this specific profile of PSKC.
PSKC algorithm profile identifier registrations are to be subject to PSKC algorithm profile identifier registrations are to be subject to
Expert Review as per RFC 5226 [RFC5226]. Expert Review as per RFC 5226 [RFC5226]. Updates can be provided
based on expert approval only. Based on expert approval, it is
possible to mark entries as "deprecated". A designated expert will
be appointed by the IESG.
IANA is asked to add an initial value to the registry based on the IANA is asked to add an initial value to the registry based on the
PSKC HOTP algorithm profile described in Section 10. PSKC HOTP algorithm profile 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 is requested to create a registry for PSKC version numbers. The
registry has the following structure: registry has the following structure:
PSKC Version | Specification PSKC Version | Specification
skipping to change at page 49, line 50 skipping to change at page 50, line 4
| Encrypt | [Section 5 of this document] | Encrypt | [Section 5 of this document]
| Integrity | [Section 5 of this document] | Integrity | [Section 5 of this document]
| Verify | [Section 5 of this document] | Verify | [Section 5 of this document]
| Unlock | [Section 5 of this document] | Unlock | [Section 5 of this document]
| Decrypt | [Section 5 of this document] | Decrypt | [Section 5 of this document]
| KeyWrap | [Section 5 of this document] | KeyWrap | [Section 5 of this document]
| Unwrap | [Section 5 of this document] | Unwrap | [Section 5 of this document]
| Derive | [Section 5 of this document] | Derive | [Section 5 of this document]
| Generate | [Section 5 of this document] | Generate | [Section 5 of this document]
+---------------------------+------------------------------- +---------------------------+-------------------------------
Expert Review is required to define new key usage tokens. Each Expert Review is required to define new key usage tokens. Each
registration request has to provide a description of the semantic. registration request has to provide a description of the semantic.
Using the same procedure it is possible to deprecate, delete, or Using the same procedure it is possible to deprecate, delete, or
modify existing key usage tokens. modify existing key usage tokens. A designated expert will be
appointed by the IESG.
13. Security Considerations 13. Security Considerations
The portable key container carries sensitive information (e.g., The portable key container carries sensitive information (e.g.,
cryptographic keys) and may be transported across the boundaries of cryptographic keys) and may be transported across the boundaries of
one secure perimeter to another. For example, a container residing one secure perimeter to another. For example, a container residing
within the secure perimeter of a back-end provisioning server in a within the secure perimeter of a back-end provisioning server in a
secure room may be transported across the internet to an end-user secure room may be transported across the internet to an end-user
device attached to a personal computer. This means that special care device attached to a personal computer. This means that special care
must be taken to ensure the confidentiality, integrity, and must be taken to ensure the confidentiality, integrity, and
authenticity of the information contained within. authenticity of the information contained within.
13.1. Payload confidentiality 13.1. Payload Confidentiality
By design, the container allows two main approaches to guaranteeing By design, the container allows two main approaches to guaranteeing
the confidentiality of the information it contains while transported. the confidentiality of the information it contains while transported.
First, the container key data payload may be encrypted. First, the container key data payload may be encrypted.
In this case no transport layer security is required. However, In this case no transport layer security is required. However,
standard security best practices apply when selecting the strength of standard security best practices apply when selecting the strength of
the cryptographic algorithm for payload encryption. Symmetric the cryptographic algorithm for payload encryption. Symmetric
cryptographic cipher should be used - the longer the cryptographic cryptographic cipher should be used - the longer the cryptographic
skipping to change at page 52, line 12 skipping to change at page 52, line 12
in this mode. Secure channels that encrypt and digest each message in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature provide an extra measure of security, especially when the signature
of the payload does not encompass the entire payload. of the payload does not encompass the entire payload.
Because of the fact that the plain text payload is protected only by Because of the fact that the plain text payload is protected only by
the transport layer security, practical implementation must ensure the transport layer security, practical implementation must ensure
protection against man-in-the-middle attacks. Validating the secure protection against man-in-the-middle attacks. Validating the secure
channel end-points is critically important for eliminating intruders channel end-points is critically important for eliminating intruders
that may compromise the confidentiality of the payload. that may compromise the confidentiality of the payload.
13.2. Payload integrity 13.2. Payload Integrity
The portable symmetric key container provides a mean to guarantee the The portable symmetric key container provides a mean to guarantee the
integrity of the information it contains through digital signatures. integrity of the information it contains through digital signatures.
For best security practices, the digital signature of the container For best security practices, the digital signature of the container
should encompass the entire payload. This provides assurances for should encompass the entire payload. This provides assurances for
the integrity of all attributes. It also allows verification of the the integrity of all attributes. It also allows verification of the
integrity of a given payload even after the container is delivered integrity of a given payload even after the container is delivered
through the communication channel to the target perimeter and channel through the communication channel to the target perimeter and channel
message integrity check is no longer possible. message integrity check is no longer possible.
13.3. Payload authenticity 13.3. Payload Authenticity
The digital signature of the payload is the primary way of showing The digital signature of the payload is the primary way of showing
its authenticity. The recipient of the container may use the public its authenticity. The recipient of the container may use the public
key associated with the signature to assert the authenticity of the key associated with the signature to assert the authenticity of the
sender by tracing it back to a preloaded public key or certificate. sender by tracing it back to a preloaded public key or certificate.
Note that the digital signature of the payload can be checked even Note that the digital signature of the payload can be checked even
after the container has been delivered through the secure channel of after the container has been delivered through the secure channel of
communication. communication.
A weaker payload authenticity guarantee may be provided by the A weaker payload authenticity guarantee may be provided by the
skipping to change at page 56, line 36 skipping to change at page 56, line 36
URL: http://www.openauthentication.org. URL: http://www.openauthentication.org.
[PSKC-ALGORITHM-PROFILES] [PSKC-ALGORITHM-PROFILES]
Hoyer, P., Pei, M., Machani, S., and A. Doherty, Hoyer, P., Pei, M., Machani, S., and A. Doherty,
"Additional Portable Symmetric Key Container (PSKC) "Additional Portable Symmetric Key Container (PSKC)
Algorithm Profiles", Internet Draft Informational, URL: Algorithm Profiles", Internet Draft Informational, URL:
http://tools.ietf.org/html/ http://tools.ietf.org/html/
draft-hoyer-keyprov-pskc-algorithm-profiles-00, draft-hoyer-keyprov-pskc-algorithm-profiles-00,
December 2008. December 2008.
[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Masinter, "Uniform Resource Identifiers (URI): Generic Resource Identifiers (URI): Generic Syntax", RFC 3986,
Syntax", BCP 26, RFC 2396, August 1998. January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[XMLNS] "Namespaces in XML", W3C Recommendation , [XMLNS] "Namespaces in XML", W3C Recommendation ,
URL: http://www.w3.org/TR/1999/REC-xml-names-19990114, URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
January 1999. January 1999.
Appendix A. Use Cases Appendix A. Use Cases
skipping to change at page 62, line 13 skipping to change at page 62, line 13
key encryption key is difficult to use. key encryption key is difficult to use.
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 7744 6455 Phone: +44 (0) 20 7960 0220
Email: Philip.Hoyer@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
 End of changes. 49 change blocks. 
91 lines changed or deleted 99 lines changed or added

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