draft-ietf-keyprov-symmetrickeyformat-11.txt   rfc6031.txt 
KEYPROV Working Group Sean Turner
Internet Draft IECA
Intended Status: Standards Track Russ Housley
Expires: February 9, 2010 Vigil Security
August 9, 2010
Symmetric Key Package Content Type Internet Engineering Task Force (IETF) S. Turner
draft-ietf-keyprov-symmetrickeyformat-11.txt Request for Comments: 6031 IECA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
December 2010
Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type
Abstract Abstract
This document defines the symmetric key format content type. It is This document defines the symmetric key format content type. It is
transport independent. The Cryptographic Message Syntax can be used transport independent. The Cryptographic Message Syntax (CMS) can be
to digitally sign, digest, authenticate, or encrypt this content used to digitally sign, digest, authenticate, or encrypt this content
type. type.
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 9, 2010. 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/rfc6031.
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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Requirements Terminology..................................3 1.1. Requirements Terminology..................................3
1.2. ASN.1 Syntax Notation.....................................3 1.2. ASN.1 Syntax Notation.....................................3
2. Symmetric Key Package Content Type.............................3 2. Symmetric Key Package Content Type.............................3
3. PSKC Attributes................................................5 3. PSKC Attributes................................................4
3.1. PSKC Key Package Attributes...............................5 3.1. PSKC Key Package Attributes...............................5
3.1.1. Device Information Attributes........................5 3.1.1. Device Information Attributes........................5
3.1.2. Cryptographic Module Information Attributes..........8 3.1.2. Cryptographic Module Information Attributes..........8
3.2. PSKC Key Attributes.......................................8 3.2. PSKC Key Attributes.......................................8
3.2.1. Key Identifier.......................................9 3.2.1. Key Identifier.......................................8
3.2.2. Algorithm............................................9 3.2.2. Algorithm............................................9
3.2.3. Issuer...............................................9 3.2.3. Issuer...............................................9
3.2.4. Key Profile Identifier...............................9 3.2.4. Key Profile Identifier...............................9
3.2.5. Key Reference Identifier............................10 3.2.5. Key Reference Identifier.............................9
3.2.6. Friendly Name.......................................10 3.2.6. Friendly Name.......................................10
3.2.7. Algorithm Parameters................................10 3.2.7. Algorithm Parameters................................10
3.2.8. Counter.............................................13 3.2.8. Counter.............................................12
3.2.9. Time................................................13 3.2.9. Time................................................13
3.2.10. Time Interval......................................13 3.2.10. Time Interval......................................13
3.2.11. Time Drift.........................................13 3.2.11. Time Drift.........................................13
3.2.12. Value MAC..........................................14 3.2.12. Value MAC..........................................13
3.2.13. Key User Id........................................14 3.2.13. Key User Id........................................14
3.3. Key Policy Attributes....................................15 3.3. Key Policy Attributes....................................14
3.3.1. Key Start Date......................................15 3.3.1. Key Start Date......................................14
3.3.2. Key Expiry Date.....................................15 3.3.2. Key Expiry Date.....................................15
3.3.3. Number of Transactions..............................15 3.3.3. Number of Transactions..............................15
3.3.4. Key Usage...........................................16 3.3.4. Key Usage...........................................15
3.3.5. PIN Policy..........................................17 3.3.5. PIN Policy..........................................16
4. Key Encoding..................................................18 4. Key Encoding..................................................18
4.1. AES Key Encoding.........................................18 4.1. AES Key Encoding.........................................18
4.2. Triple DES Key Encoding..................................18 4.2. Triple-DES Key Encoding..................................18
5. Security Considerations.......................................19 5. Security Considerations.......................................19
6. IANA Considerations...........................................19 6. IANA Considerations...........................................19
7. References....................................................20 7. References....................................................19
7.1. Normative References.....................................20 7.1. Normative References.....................................19
7.2. Informative References...................................22 7.2. Informative References...................................21
APPENDIX A: ASN.1 Module.........................................22 Appendix A. ASN.1 Module.........................................22
A.1. Symmetric Key Package ASN.1 Module.......................22 A.1. Symmetric Key Package ASN.1 Module.......................22
A.2. PSKC ASN.1 Module........................................24 A.2. PSKC ASN.1 Module........................................23
1. Introduction 1. Introduction
This document defines the symmetric key format content type. It is This document defines the symmetric key format content type. It is
transport independent. The Cryptographic Message Syntax (CMS) transport independent. The Cryptographic Message Syntax (CMS)
[RFC5652] can be used to digitally sign, digest, authenticate, or [RFC5652] can be used to digitally sign, digest, authenticate, or
encrypt this content type. encrypt this content type.
The use cases that motivated the attributes in this work are The use cases that motivated the attributes in this work are
elaborated in [PSKC]. They are omitted to avoid duplication. elaborated in [RFC6030]. They are omitted to avoid duplication.
This document also includes Abstract Syntax Notation One (ASN.1) This document also includes ASN.1 definitions of the Extensible
definitions of the Extensible Markup Language (XML) element and Markup Language (XML) element and attributes defined in [RFC6030].
attributes defined in [PSKC].
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. ASN.1 Syntax Notation 1.2. ASN.1 Syntax Notation
The key package is defined using the ASN.1 [X.680], [X.681], [X.682], The key package is defined using the ASN.1 in [X.680], [X.681],
and [X.683]. [X.682], and [X.683].
2. Symmetric Key Package Content Type 2. Symmetric Key Package Content Type
The symmetric key package content type is used to transfer one or The symmetric key package content type is used to transfer one or
more plaintext symmetric keys from one party to another. A symmetric more plaintext symmetric keys from one party to another. A symmetric
key package MAY be encapsulated in one or more CMS protecting content key package MAY be encapsulated in one or more CMS protecting content
types. This content type MUST be Distinguished Encoding Rules (DER) types. This content type MUST be Distinguished Encoding Rules (DER)
encoded [X.690]. encoded [X.690].
The symmetric key package content type has the following syntax: The symmetric key package content type has the following syntax:
ct-symmetric-key-package CONTENT-TYPE ::= ct-symmetric-key-package CONTENT-TYPE ::=
{ SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } { TYPE SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage }
id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 25 } smime(16) ct(1) 25 }
SymmetricKeyPackage ::= SEQUENCE { SymmetricKeyPackage ::= SEQUENCE {
version KeyPkgVersion DEFAULT v1, version KeyPkgVersion DEFAULT v1,
sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute
{{ SKeyPkgAttributes }} OPTIONAL, {{ SKeyPkgAttributes }} OPTIONAL,
sKeys SymmetricKeys, sKeys SymmetricKeys,
... } ... }
SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey
skipping to change at page 4, line 29 skipping to change at page 4, line 18
sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute
{{ SKeyAttributes }} OPTIONAL, {{ SKeyAttributes }} OPTIONAL,
sKey OCTET STRING OPTIONAL } sKey OCTET STRING OPTIONAL }
( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } |
WITH COMPONENTS { ..., sKey PRESENT } ) WITH COMPONENTS { ..., sKey PRESENT } )
KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... )
The SymmetricKeyPackage fields are used as follows: The SymmetricKeyPackage fields are used as follows:
- version identifies version of the symmetric key package content - version identifies the version of the symmetric key package content
structure. For this version of the specification, the default structure. For this version of the specification, the default
value, v1, MUST be used. value, v1, MUST be used.
- sKeyPkgAttrs optionally provides attributes that apply to all of - sKeyPkgAttrs optionally provides attributes that apply to all of
the symmetric keys in the package. The SKeyPkgAttributes the symmetric keys in the package. The SKeyPkgAttributes
information object set restricts the attributes allowed in information object set restricts the attributes allowed in
sKeyPkgAttrs. If an attribute appears here, then it MUST NOT also sKeyPkgAttrs. If an attribute appears here, then it MUST NOT also
be included in sKeyAttrs. be included in sKeyAttrs.
- sKeys contains a sequence of OneSymmetricKey values. This - sKeys contains a sequence of OneSymmetricKey values. This
structure is discussed below. structure is discussed below.
The OneSymmetricKey fields are used as follows: The OneSymmetricKey fields are used as follows:
- sKeyAttrs optionally provides attributes that apply to one - sKeyAttrs optionally provides attributes that apply to one
symmetric key. The SKeyAttributes information object set symmetric key. The SKeyAttributes information object set restricts
restricts the attributes permitted in sKeyAttrs. If an attribute the attributes permitted in sKeyAttrs. If an attribute appears
appears here, then it MUST NOT also be included in sKeyPkgAttrs. here, then it MUST NOT also be included in sKeyPkgAttrs.
- sKey optionally contains the key value encoded as an OCTET STRING. - sKey optionally contains the key value encoded as an OCTET STRING.
The OneSymmetricKey field MUST include either sKeyAttrs, or sKey, or The OneSymmetricKey field MUST include sKeyAttrs, sKey, or sKeyAttrs
sKeyAttrs and sKey. and sKey.
3. PSKC Attributes 3. PSKC Attributes
The following attributes are defined to assist those using the The following attributes are defined to assist those using the
symmetric key package defined in this document as part of a Dynamic symmetric key package defined in this document as part of a Dynamic
Symmetric Key Provision Protocol (DSKPP) [DSKPP] with Portable Symmetric Key Provision Protocol (DSKPP) [RFC6063] with Portable
Symmetric Key Container (PSKC) attributes. [PSKC] should be Symmetric Key Container (PSKC) attributes. [RFC6030] should be
consulted for the definitive attribute descriptions. The attributes consulted for the definitive attribute descriptions. The attributes
fall in to three categories. The first category includes attributes fall into three categories. The first category includes attributes
that apply to a key package, and these attributes will generally that apply to a key package, and these attributes will generally
appear in sKeyPkgAttrs. The second category includes attributes that appear in sKeyPkgAttrs. The second category includes attributes that
apply to a particular key, and these attributes will generally appear apply to a particular key, and these attributes will generally appear
in sKeyAttrs. The third category includes attributes that apply to a in sKeyAttrs. The third category includes attributes that apply to a
key policy. Of the attributes defined, only the Key Identifier key policy. Of the attributes defined, only the Key Identifier
(Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be
included. All other attributes are OPTIONAL. included. All other attributes are OPTIONAL.
Like PSKC, the Symmetric Key Content Type supports extensibility. Like PSKC, the Symmetric Key Content Type supports extensibility.
Primarily this is accomplished through the definition and inclusion Primarily, this is accomplished through the definition and inclusion
of new attributes, but in some instances where the attribute contains of new attributes, but in some instances in which the attribute
more than one type the ASN.1 "..." extensibility mechanism is contains more than one type, the ASN.1 "..." extensibility mechanism
employed. is employed.
A straightforward approach to conversion from XML types to ASN.1 is A straightforward approach to conversion from XML types to ASN.1 is
employed. The <xs:string> type converts to UTF8String; the XML employed. The <xs:string> type converts to UTF8String; the XML
<xs:dateTime> type converts to GeneralizedTime; and the XML integer <xs:dateTime> type converts to GeneralizedTime; and the XML integer
types convert to INTEGER or BinaryTime [RFC4049]. types convert to INTEGER or BinaryTime [RFC6019].
3.1. PSKC Key Package Attributes 3.1. PSKC Key Package Attributes
PSKC key package attributes apply to an entire key package. These PSKC key package attributes apply to an entire key package. These
attributes can be categorized by two different attribute collections: attributes can be categorized by two different attribute collections:
device information and cryptographic module attributes. All of these device information and cryptographic module attributes. All of these
key package attributes are OPTIONAL. key package attributes are OPTIONAL.
3.1.1. Device Information Attributes 3.1.1. Device Information Attributes
Device Information attributes when taken together MUST uniquely Device Information attributes, when taken together, MUST uniquely
identify a device to which the Symmetric Key Package is provisioned. identify a device to which the Symmetric Key Package is provisioned.
3.1.1.1. Manufacturer 3.1.1.1. Manufacturer
The Manufacturer attribute indicates the manufacturer of the device. The Manufacturer attribute indicates the manufacturer of the device.
Values for Manufacturer MUST be taken from either [OATHMAN] prefixes Values for Manufacturer MUST be taken from either [OATHMAN] prefixes
(i.e., the left column) or from IANA Private Enterprise Number (i.e., the left column) or from the IANA Private Enterprise Number
Registry [IANAPENREG], using the Organisation value. When the value Registry [IANAPENREG], using the Organization value. When the value
is taken from [OATHMAN] "oath." MUST be prepended to the value (e.g., is taken from [OATHMAN] "oath." MUST be prepended to the value (e.g.,
"oath.<values from [OATHMAN]>"). When the value is taken from "oath.<values from [OATHMAN]>"). When the value is taken from
[IANAPENREG] "iana." MUST be prepended to the value (e.g., [IANAPENREG], "iana." MUST be prepended to the value (e.g.,
"iana.<ORganisation value from [IANAPENREG]>"). The attribute "iana.<Organization value from [IANAPENREG]>"). The attribute
definition is as follows: definition is as follows:
at-pskc-manufacturer ATTRIBUTE ::= { at-pskc-manufacturer ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }
id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 }
3.1.1.2. Serial Number 3.1.1.2. Serial Number
The Serial Number attribute indicates the serial number of the The Serial Number attribute indicates the serial number of the
device. The attribute definition is as follows: device. The attribute definition is as follows:
at-pskc-serialNo ATTRIBUTE ::= { at-pskc-serialNo ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } TYPE UTF8String IDENTIFIED BY id-pskc-serialNo }
id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 }
3.1.1.3. Model 3.1.1.3. Model
The Model attribute indicates the model of the device. The attribute The Model attribute indicates the model of the device. The attribute
definition is as follows: definition is as follows:
at-pskc-model ATTRIBUTE ::= { at-pskc-model ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-model } TYPE UTF8String IDENTIFIED BY id-pskc-model }
id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 }
3.1.1.4. Issue Number 3.1.1.4. Issue Number
The Issue Number attribute contains an issue number to distinguish The Issue Number attribute contains an issue number to distinguish
between two devices with the same serial number. The attribute between two devices with the same serial number. The attribute
definition is as follows: definition is as follows:
at-pskc-issueNo ATTRIBUTE ::= { at-pskc-issueNo ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } TYPE UTF8String IDENTIFIED BY id-pskc-issueNo }
id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 }
3.1.1.5. Device Binding 3.1.1.5. Device Binding
The Device Binding attribute provides an opaque identifier that The Device Binding attribute provides an opaque identifier that
allows keys to be bound to the device or to a class of devices. allows keys to be bound to the device or to a class of devices.
When loading keys into a device, the attribute's value MUST be When loading keys into a device, the attribute's value MUST be
checked against information provided to the user via out-of-band checked against information provided to the user via out-of-band
mechanisms. The implementation then ensures that the correct device mechanisms. The implementation then ensures that the correct device
or class of device is being used with respect to the provisioned key. or class of device is being used with respect to the provisioned key.
at-pskc-deviceBinding ATTRIBUTE ::= { at-pskc-deviceBinding ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding }
id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 }
3.1.1.6. Device Start Date 3.1.1.6. Device Start Date
When included in sKeyPkgAttrs, the Device Start Date attribute When included in sKeyPkgAttrs, the Device Start Date attribute
indicates the start date for a device. The date MUST be represented indicates the start date for a device. The date MUST be represented
in a form that matches the dateTime production in "canonical in a form that matches the dateTime production in "canonical
representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds. Keys that are on the device instants that specify leap seconds. Keys that are on the device
SHOULD only be used when the current date is on or after the device SHOULD only be used when the current date is on or after the device
start date. The attribute definition is as follows: start date. The attribute definition is as follows:
at-pskc-deviceStartDate ATTRIBUTE ::= { at-pskc-deviceStartDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate }
id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 }
Note that usage enforcement of the keys with respect to the dates MAY Note that usage enforcement of the keys with respect to the dates MAY
only happen on the validation server as some devices such as smart only happen on the validation server as some devices, such as smart
cards do not have an internal clock. Systems thus SHOULD NOT rely cards, do not have an internal clock. Systems thus SHOULD NOT rely
upon the device to enforce key usage date restrictions. upon the device to enforce key usage date restrictions.
3.1.1.7. Device Expiry Date 3.1.1.7. Device Expiry Date
When included in sKeyPkgAttrs, the Device Expiry Date attribute When included in sKeyPkgAttrs, the Device Expiry Date attribute
indicates the expiry date for a device. The date MUST be represented indicates the expiry date for a device. The date MUST be represented
in a form that matches the dateTime production in "canonical in a form that matches the dateTime production in "canonical
representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds. Keys that are on the device instants that specify leap seconds. Keys that are on the device
SHOULD only be used when the current date is before the device expiry SHOULD only be used when the current date is before the device expiry
date. The attribute definition is as follows: date. The attribute definition is as follows:
at-pskc-deviceExpiryDate ATTRIBUTE ::= { at-pskc-deviceExpiryDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate }
id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } Note
Note that usage enforcement of the keys with respect to the dates MAY that usage enforcement of the keys with respect to the dates MAY only
only happen on the validation server as some devices such as smart happen on the validation server as some devices, such as smart cards,
cards do not have an internal clock. Systems thus SHOULD NOT rely do 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.
3.1.1.8. Device User Id 3.1.1.8. Device User Id
The Device User Id attribute indicates the user with whom the device The Device User Id attribute indicates the user with whom the device
is associated with using a distinguished name, as defined in is associated using a distinguished name, as defined in [RFC4514].
[RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute For example: UID=jsmith,DC=example,DC=net. The attribute definition
definition is as follows: is as follows:
at-pskc-deviceUserId ATTRIBUTE ::= { at-pskc-deviceUserId ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId } TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId }
id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 } id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 }
As specified in [PSKC], there are no semantics associated with this As specified in [RFC6030], there are no semantics associated with
element, i.e., there are no checks enforcing that only a specific this element, i.e., there are no checks enforcing that only a
user can use this device. As such, this element is for informational specific user can use this device. As such, this element is for
purposes only. informational purposes only.
3.1.2. Cryptographic Module Information Attributes 3.1.2. Cryptographic Module Information Attributes
Cryptographic Module attributes uniquely identify a cryptographic Cryptographic Module attributes uniquely identify a cryptographic
module. This is useful when the device contains more than one module. This is useful when the device contains more than one
cryptographic module. At this time only one attribute is defined. cryptographic module. At this time, only one attribute is defined.
3.1.2.1. Cryptographic Module Identifier 3.1.2.1. Cryptographic Module Identifier
When included in sKeyPkgAttrs, the Cryptographic Module Identifier When included in sKeyPkgAttrs, the Cryptographic Module Identifier
attribute uniquely identifies the cryptographic module to which the attribute uniquely identifies the cryptographic module to which the
key is being or was provisioned. The attribute definition is as key is being or was provisioned. The attribute definition is as
follows: follows:
at-pskc-moduleId ATTRIBUTE ::= { at-pskc-moduleId ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } TYPE UTF8String IDENTIFIED BY id-pskc-moduleId }
id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 }
3.2. PSKC Key Attributes 3.2. PSKC Key Attributes
PSKC key attributes apply to a specific key. As noted earlier, the PSKC key attributes apply to a specific key. As noted earlier, the
Key Identifier (Sec 3.2.1) and Algorithm (Sec 3.2.2) key attributes Key Identifier (Section 3.2.1) and Algorithm (Section 3.2.2) key
are REQUIRED. All other attributes are OPTIONAL. attributes are REQUIRED. All other attributes are OPTIONAL.
3.2.1. Key Identifier 3.2.1. Key Identifier
When included in sKeyAttrs, the Key Identifier attribute identifies When included in sKeyAttrs, the Key Identifier attribute identifies
the key in the context of key provisioning exchanges between two the 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 values referencing the same keys, the KeyId MUST use the same KeyId values
(e.g. after initial provisioning, if a system wants to update key (e.g., after initial provisioning, if a system wants to update key
meta data values in the other system the KeyId value of the key where metadata values in the other system, the KeyId value of the key where
the meta data is to be updates MUST be the same as the original KeyId the metadata is to be updates MUST be the same as the original KeyId
value provisioned). The attribute definition is as follows: value provisioned). The attribute definition is as follows:
at-pskc-keyId ATTRIBUTE ::= { at-pskc-keyId ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-keyId } TYPE UTF8String IDENTIFIED BY id-pskc-keyId }
id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 }
3.2.2. Algorithm 3.2.2. Algorithm
The Algorithm attribute uniquely identifies the PSKC algorithm The Algorithm attribute uniquely identifies the PSKC algorithm
profile. [PSKC] defines two algorithm profiles "HOTP" and "PIN". profile. [RFC6030] defines two algorithm profiles "HOTP" and "PIN".
The attribute definition is as follows: The attribute definition is as follows:
at-pskc-algorithm ATTRIBUTE ::= { at-pskc-algorithm ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } TYPE UTF8String IDENTIFIED BY id-pskc-algorithm }
id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 }
3.2.3. Issuer 3.2.3. Issuer
The Issuer attribute names the entity that issued the key. The The Issuer attribute names the entity that issued the key. The
attribute definition is as follows: attribute definition is as follows:
at-pskc-issuer ATTRIBUTE ::= { at-pskc-issuer ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-issuer } TYPE UTF8String IDENTIFIED BY id-pskc-issuer }
id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 }
3.2.4. Key Profile Identifier 3.2.4. Key Profile Identifier
The Key Profile Identifier attribute carries a unique identifier used The Key Profile Identifier attribute carries a unique identifier used
between the sending and receiving parties to establish a set of key between the sending and receiving parties to establish a set of key
attribute values that are not transmitted within the container but attribute values that are not transmitted within the container but
agreed between the two parties out of band. This attribute will then are agreed upon between the two parties out of band. This attribute
represent the unique reference to a set of key attribute values. will then represent the unique reference to a set of key attribute
values.
at-pskc-keyProfileId ATTRIBUTE ::= { at-pskc-keyProfileId ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId }
id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 }
3.2.5. Key Reference Identifier 3.2.5. Key Reference Identifier
The Key Reference attribute refers to an external key to be used with The Key Reference attribute refers to an external key to be used with
a key derivation scheme and no specific key value (secret) is a key derivation scheme and no specific key value (secret) is
transported but only the reference to the external master key is used transported; only the reference to the external master key is used
(e.g., the PKCS#11 key label). (e.g., the PKCS #11 key label).
at-pskc-keyReference ATTRIBUTE ::= { at-pskc-keyReference ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } TYPE UTF8String IDENTIFIED BY id-pskc-keyReference }
id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 }
3.2.6. Friendly Name 3.2.6. Friendly Name
The Friendly Name attribute contains a human readable name for the The Friendly Name attribute contains a human-readable name for the
secret key. The attribute definition is as follows: secret key. The attribute definition is as follows:
at-pskc-friendlyName ATTRIBUTE ::= { at-pskc-friendlyName ATTRIBUTE ::= {
TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName } TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName }
id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 }
The Friendly Name attribute has the following syntax: The Friendly Name attribute has the following syntax:
FriendlyName ::= SEQUENCE { FriendlyName ::= SEQUENCE {
friendlyName UTF8String, friendlyName UTF8String,
friendlyNameLangTag UTF8String OPTIONAL } friendlyNameLangTag UTF8String OPTIONAL }
The text is encoded in UTF-8 [RFC3629], which accommodates most of The text is encoded in UTF-8 [RFC3629], which accommodates most of
the world's writing systems. The friendlyNameLangTag field the world's writing systems. The friendlyNameLangTag field
identifies the language used to express the friendlyName. When identifies the language used to express the friendlyName. When the
friendlyNameLangTag is absent, English, whose associated language tag friendlyNameLangTag field is absent, English, whose associated
is "en", is used. The value of the friendlyNameLangTag MUST be a language tag is "en", is used. The value of the friendlyNameLangTag
language tag as described in [RFC5646]. field MUST be a language tag, as described in [RFC5646].
3.2.7. Algorithm Parameters 3.2.7. Algorithm Parameters
The Algorithm Parameters attribute contains parameters that influence The Algorithm Parameters attribute contains parameters that influence
the result of the algorithmic computation, for example response the result of the algorithmic computation, for example, response
truncation and format in One-Time Password (OTP) and Challenge- truncation and format in One-Time Password (OTP) and
Response (CR) algorithms. Challenge/Response (CR) algorithms.
at-pskc-algorithmParameters ATTRIBUTE ::= { at-pskc-algorithmParameters ATTRIBUTE ::= {
TYPE PSKCAlgorithmParameters TYPE PSKCAlgorithmParameters
IDENTIFIED BY id-pskc-algorithmParams } IDENTIFIED BY id-pskc-algorithmParams }
id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 } id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 }
The Algorithm Parameters attribute has the following syntax: The Algorithm Parameters attribute has the following syntax:
PSKCAlgorithmParameters ::= CHOICE { PSKCAlgorithmParameters ::= CHOICE {
suite UTF8String OPTIONAL, suite UTF8String,
challengeFormat [0] ChallengeFormat, challengeFormat [0] ChallengeFormat,
responseFormat [1] ResponseFormat, responseFormat [1] ResponseFormat,
... } ... }
ChallengeFormat ::= SEQUENCE { ChallengeFormat ::= SEQUENCE {
encoding Encoding, encoding Encoding,
checkDigit BOOLEAN DEFAULT FALSE, checkDigit BOOLEAN DEFAULT FALSE,
min INTEGER (0..MAX), min INTEGER (0..MAX),
max INTEGER (0..MAX), max INTEGER (0..MAX),
... } ... }
skipping to change at page 11, line 37 skipping to change at page 11, line 23
"ALPHANUMERIC" |"BASE64" |"BINARY") "ALPHANUMERIC" |"BASE64" |"BINARY")
ResponseFormat ::= SEQUENCE { ResponseFormat ::= SEQUENCE {
encoding Encoding, encoding Encoding,
length INTEGER (0..MAX), length INTEGER (0..MAX),
checkDigit BOOLEAN DEFAULT FALSE, checkDigit BOOLEAN DEFAULT FALSE,
... } ... }
The fields in PSKCAlgorithmParameters have the following meanings: The fields in PSKCAlgorithmParameters have the following meanings:
o Suite defines additional characteristics of the algorithm used, o Suite defines additional characteristics of the algorithm used,
which are algorithm specific. For example in HMAC based OTP which are algorithm specific. For example, in an HMAC-based
algorithm it could designate the strength of the hash algorithm (Hashed Message Authentication Code) OTP algorithm it could
used (SHA1, SHA256, etc). Please refer to algorithm profile designate the strength of the hash algorithm used (SHA1, SHA256,
specification [PSKC] for the exact semantic of the value for each etc.). Please refer to the algorithm profile specification
algorithm profile. [RFC6030] for the exact semantics of the value for each algorithm
profile.
o ChallengeFormat defines the characteristics of the challenge in a o ChallengeFormat defines the characteristics of the challenge in a
CR usage scenario whereby the following fields are defined: CR usage scenario, whereby the following fields are defined:
o encoding specifies the encoding of the challenge accepted by o encoding specifies the encoding of the challenge accepted by the
the device and MUST be one of the following values: DECIMAL, device and MUST be one of the following values: DECIMAL,
HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64
encoding is done as in Section 4 of [RFC4648]. encoding is done as in Section 4 of [RFC4648].
o checkDigit indicates whether a device needs to check the o checkDigit indicates whether a device needs to check the
appended Luhn check digit, as defined in [LUHN], contained in a appended Luhn check digit, as defined in [ISOIEC7812], contained
challenge. The checkDigit MUST NOT be present if the encoding in a challenge. The checkDigit MUST NOT be present if the
value is anything other than 'DECIMAL'. A value of TRUE encoding value is anything other than 'DECIMAL'. A value of
indicates that the device will check the appended Luhn check TRUE indicates that the device will check the appended Luhn
digit in a provided challenge. A value of FALSE indicates that check digit in a provided challenge. A value of FALSE indicates
the device will not check the appended Luhn check digit in the that the device will not check the appended Luhn check digit in
challenge. the challenge.
o min defines the minimum size of the challenge accepted by the o min defines the minimum size of the challenge accepted by the
device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC' this value indicates the minimum number of 'ALPHANUMERIC', this value indicates the minimum number of
digits/characters. If encoding is 'BASE64' or 'BINARY', this digits/characters. If encoding is 'BASE64' or 'BINARY', this
value indicates the minimum number of bytes of the unencoded value indicates the minimum number of bytes of the unencoded
value. value.
o max defines the maximum size of the challenge accepted by the o max defines the maximum size of the challenge accepted by the
device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC' this value indicates the maximum number of 'ALPHANUMERIC', this value indicates the maximum number of
digits/characters. If the encoding is 'BASE64' or 'BINARY', digits/characters. If the encoding is 'BASE64' or 'BINARY',
this value indicates the maximum number of bytes of the this value indicates the maximum number of bytes of the
unencoded value. unencoded value.
o ResponseFormat defines the characteristics of the result of a o ResponseFormat defines the characteristics of the result of a
computation and defines the format of the OTP or the response to computation and defines the format of the OTP or the response to a
a challenge. For cases where the key is a personal challenge. For cases where the key is a personal identification
identification number (PIN) value, this element contains the number (PIN) value, this element contains the format of the PIN
format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit itself (e.g., DECIMAL, length 4 for a 4 digit PIN). The following
PIN). The following fields are defined: fields are defined:
o encoding specifies the encoding of the response generated by o encoding specifies the encoding of the response generated by the
the device and MUST be one of the following values: DECIMAL, device and MUST be one of the following values: DECIMAL,
HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is defined
defined as in Section 4 of [RFC4648]. as in Section 4 of [RFC4648].
o length defines the length of the response generated by the o length defines the length of the response generated by the
device. If encoding is 'DECIMAL', 'HEXADECIMAL' or device. If encoding is 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC' this value indicates the number of 'ALPHANUMERIC', this value indicates the number of
digits/characters. If encoding is 'BASE64' or 'BINARY', this digits/characters. If encoding is 'BASE64' or 'BINARY', this
value indicates the number of bytes of the unencoded value. value indicates the number of bytes of the unencoded value.
o checkDigit indicates whether the device needs to append a Luhn o checkDigit indicates whether the device needs to append a Luhn
check digit, as defined in [LUHN], to the response. This is check digit, as defined in [ISOIEC7812], to the response. This
only valid if encoding attribute is 'DECIMAL'. If the value is is only valid if the encoding attribute is 'DECIMAL'. If the
TRUE then the device will append a Luhn check digit to the value is TRUE, then the device will append a Luhn check digit to
response. If the value is FALSE, then the device will not the response. If the value is FALSE, then the device will not
append a Luhn check digit to the response. append a Luhn check digit to the response.
3.2.8. Counter 3.2.8. Counter
The Counter attribute contains the event counter for event-based OTP The Counter attribute contains the event counter for event-based OTP
algorithms. The attribute definition is as follows: algorithms. The attribute definition is as follows:
at-pskc-counter ATTRIBUTE ::= { at-pskc-counter ATTRIBUTE ::= {
TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter } TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter }
id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 }
3.2.9. Time 3.2.9. Time
The Time attribute conveys the time for time-based OTP algorithms. The Time attribute conveys the time for time-based OTP algorithms.
If the Time Interval attribute is included, then this element carries If the Time Interval attribute is included, then this element carries
the number of time intervals passed for a specific start point. If the number of time intervals passed for a specific start point. If
time interval is used, then this element carries the number of time the time interval is used, then this element carries the number of
intervals passed from a specific start point, normally algorithm time intervals passed from a specific start point, normally it is
dependent. It uses the BinaryTime syntax from [RFC4049]. The algorithm dependent. It uses the BinaryTime syntax from [RFC6019].
attribute definition is as follows: The attribute definition is as follows:
at-pskc-time ATTRIBUTE ::= { at-pskc-time ATTRIBUTE ::= {
TYPE BinaryTime IDENTIFIED BY id-pskc-time } TYPE BinaryTime IDENTIFIED BY id-pskc-time }
id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 }
3.2.10. Time Interval 3.2.10. Time Interval
The Time Interval attribute conveys the time interval value for time- The Time Interval attribute conveys the time interval value for time-
based OTP algorithms in seconds (e.g., a value of 30 for this would based OTP algorithms in seconds (e.g., a value of 30 for this would
indicate a time interval of 30 seconds). It is an integer. The indicate a time interval of 30 seconds). It is an integer. The
attribute definition is as follows: attribute definition is as follows:
at-pskc-timeInterval ATTRIBUTE ::= { at-pskc-timeInterval ATTRIBUTE ::= {
TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval }
id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 }
3.2.11. Time Drift 3.2.11. Time Drift
The Time Drift attribute contains the device clock drift value for The Time Drift attribute contains the device clock drift value for
time-based OTP algorithms. It is an integer either positive or time-based OTP algorithms. It is an integer, either positive or
negative that indicates the number of time intervals that a negative, that indicates the number of time intervals that a
validation server has established the device clock drifted after the validation server has established that the device clock drifted after
last successful authentication. The attribute definition is as the last successful authentication. The attribute definition is as
follows: follows:
at-pskc-timeDrift ATTRIBUTE ::= { at-pskc-timeDrift ATTRIBUTE ::= {
TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift }
id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 }
3.2.12. Value MAC 3.2.12. Value MAC
The Value MAC attribute is a Message Authentication Code (MAC) The Value MAC attribute is a Message Authentication Code (MAC)
generated from the encrypted value in case the encryption algorithm generated from the encrypted value in the case that the encryption
does not support integrity checks (e.g., AES-CBC does not provide algorithm does not support integrity checks (e.g., AES-CBC does not
integrity while AES Key Wrap with MLI does). The attribute definition provide integrity while AES Key Wrap with a message length indicator
is as follows: (MLI) does). The attribute definition is as follows:
at-pskc-valueMAC ATTRIBUTE ::= { at-pskc-valueMAC ATTRIBUTE ::= {
TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC }
id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 }
ValueMac ::= SEQUENCE { ValueMac ::= SEQUENCE {
macAlgorithm UTF8String, macAlgorithm UTF8String,
mac UTF8String } mac UTF8String }
The fields in ValueMac have the following meanings: The fields in ValueMac have the following meanings:
o macAlgorithm identifies the MAC algorithm used to generate the o macAlgorithm identifies the MAC algorithm used to generate the
value placed in digest. value placed in digest.
o mac is the base64 encoded, as specified in Section 4 of [RFC4648], o mac is the base64-encoded, as specified in Section 4 of [RFC4648],
mac value. mac value.
3.2.13. Key User Id 3.2.13. Key User Id
The Key User Id attribute indicates the user with whom the key is The Key User Id attribute indicates the user with whom the key is
associated using a distinguished name, as defined in [RFC4514]. For associated using a distinguished name, as defined in [RFC4514]. For
example: UID=jsmith,DC=example,DC=net. The attribute definition is as example, UID=jsmith,DC=example,DC=net. The attribute definition is
follows: as follows:
at-pskc-keyUserId ATTRIBUTE ::= { at-pskc-keyUserId ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId } TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId }
id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 } id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 }
As specified in [PSKC], there are no semantics associated with this As specified in [RFC6030], there are no semantics associated with
element, i.e., there are no checks enforcing that only a specific this element, i.e., there are no checks enforcing that only a
user can use this key. As such, this element is for informational specific user can use this key. As such, this element is for
purposes only. informational purposes only.
3.3. Key Policy Attributes 3.3. Key Policy Attributes
Key policy attributes indicate a policy that can be attached to a Key policy attributes indicate a policy that can be attached to a
key. These attributes are defined in the subsections that follow. key. These attributes are defined in the subsections that follow.
3.3.1. Key Start Date 3.3.1. Key Start Date
When included in sKeyAttrs, the Key Start Date attribute indicates When included in sKeyAttrs, the Key Start Date attribute indicates
the start of the key's validity period. The date MUST be represented the start of the key's validity period. The date MUST be represented
in a form that matches the dateTime production in "canonical in a form that matches the dateTime production in "canonical
representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds. The attribute definition is as instants that specify leap seconds. The attribute definition is as
follows: follows:
at-pskc-keyStartDate ATTRIBUTE ::= { at-pskc-keyStartDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }
TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate }
id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 }
3.3.2. Key Expiry Date 3.3.2. Key Expiry Date
When included in sKeyAttrs, the Key Expiry Date attribute indicates When included in sKeyAttrs, the Key Expiry Date attribute indicates
the end of the key's validity period. The date MUST be represented the end of the key's validity period. The date MUST be represented
in a form that matches the dateTime production in "canonical in a form that matches the dateTime production in "canonical
representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time
resolution finer than milliseconds and MUST NOT generate time resolution finer than milliseconds and MUST NOT generate time
instants that specify leap seconds. The attribute definition is as instants that specify leap seconds. The attribute definition is as
follows: follows:
at-pskc-keyExpiryDate ATTRIBUTE ::= { at-pskc-keyExpiryDate ATTRIBUTE ::= {
TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate }
id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 }
3.3.3. Number of Transactions 3.3.3. Number of Transactions
The Number of Transactions attribute indicates the maximum number of The Number of Transactions attribute indicates the maximum number of
times a key carried within the package can be used. When this times a key carried within the package can be used. When this
element is omitted there is no restriction regarding the number of element is omitted, there is no restriction regarding the number of
times a key can be used. The attribute definition is as follows: times a key can be used. The attribute definition is as follows:
at-pskc-noOfTransactions ATTRIBUTE ::= { at-pskc-noOfTransactions ATTRIBUTE ::= {
TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions } TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions }
id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 }
3.3.4. Key Usage 3.3.4. Key Usage
The Key Usage attribute constrains the intended usage of the key. The Key Usage attribute constrains the intended usage of the key.
The recipient MUST enforce the key usage. The attribute definition The recipient MUST enforce the key usage. The attribute definition
is as follows: is as follows:
at-pskc-keyUsage ATTRIBUTE ::= { at-pskc-keyUsage ATTRIBUTE ::= {
TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages }
id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 }
PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage
PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" |
"Integrity" | "Verify" | "Unlock" | "Decrypt" | "Integrity" | "Verify" | "Unlock" | "Decrypt" |
"KeyWrap" | "Unwrap" | "Derive" | "Generate") "KeyWrap" | "Unwrap" | "Derive" | "Generate")
The fields in PSKCKeyUsage have the following meanings: The fields in PSKCKeyUsage have the following meanings:
o OTP: The key MUST only be used for OTP generation. o OTP: The key MUST only be used for OTP generation.
o CR: The key MUST only be used for Challenge/Response purposes. o CR: The key MUST only be used for Challenge/Response purposes.
o Encrypt: The key MUST only be used for data encryption purposes. o Encrypt: The key MUST only be used for data encryption purposes.
o Integrity: The key MUST only be used to generate a keyed message o 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.
o Verify: The key MUST only be used to verify a keyed message o Verify: The key MUST only be used to verify a keyed message digest
digest for data integrity or authentication purposes (is converse for data integrity or authentication purposes (is the converse of
of Integrity). Integrity).
o Unlock: The key MUST only be used for an inverse challenge o Unlock: The key MUST only be used for an inverse
response in the case where a user has locked the device by Challenge/Response in the case in which a user has locked the
entering a wrong PIN too many times (for devices with PIN-input device by entering an incorrect PIN too many times (for devices
capability). with PIN-input capability).
o Decrypt: The key MUST only be used for data decryption purposes. o Decrypt: The key MUST only be used for data decryption purposes.
o KeyWrap: The key MUST only be used for key wrap purposes. o KeyWrap: The key MUST only be used for key wrap purposes.
o Unwrap: The key MUST only be used for key unwrap purposes. o Unwrap: The key MUST only be used for key unwrap purposes.
o Derive: The key MUST only be used with a key derivation function o 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]).
o Generate: The key MUST only be used to generate a new key based o Generate: The key MUST only be used to generate a new key based on
on a random number and the previous value of the key (see also a random number and the previous value of the key (see also Section
Section 8.1.5.2.1 of [NIST800-57]). 8.1.5.2.1 of [NIST800-57]).
3.3.5. PIN Policy 3.3.5. PIN Policy
The PIN Policy attribute allows policy about the PIN usage to be The PIN Policy attribute allows policy about the PIN usage to be
associated with the key. The attribute definition is as follows: associated with the key. The attribute definition is as follows:
at-pskc-pinPolicy ATTRIBUTE ::= { at-pskc-pinPolicy ATTRIBUTE ::= {
TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy }
id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 }
PINPolicy ::= SEQUENCE { PINPolicy ::= SEQUENCE {
pinKeyId [0] UTF8String OPTIONAL, pinKeyId [0] UTF8String OPTIONAL,
pinUsageMode [1] PINUsageMode, pinUsageMode [1] PINUsageMode,
maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL,
minLength [3] INTEGER (0..MAX) OPTIONAL, minLength [3] INTEGER (0..MAX) OPTIONAL,
maxLength [4] INTEGER (0..MAX) OPTIONAL, maxLength [4] INTEGER (0..MAX) OPTIONAL,
pinEncoding [5] Encoding OPTIONAL } pinEncoding [5] Encoding OPTIONAL }
PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" | PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" |
"Algorithmic") "Algorithmic")
skipping to change at page 17, line 32 skipping to change at page 17, line 17
maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL,
minLength [3] INTEGER (0..MAX) OPTIONAL, minLength [3] INTEGER (0..MAX) OPTIONAL,
maxLength [4] INTEGER (0..MAX) OPTIONAL, maxLength [4] INTEGER (0..MAX) OPTIONAL,
pinEncoding [5] Encoding OPTIONAL } pinEncoding [5] Encoding OPTIONAL }
PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" | PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" |
"Algorithmic") "Algorithmic")
The fields in PIN Policy have the following meanings: The fields in PIN Policy have the following meanings:
o pinKeyId uniquely identifies the key held within this container o pinKeyId uniquely identifies the key held within this container
that contains the value of the PIN that protects the key. that contains the value of the PIN that protects the key.
o pinUsageMode indicates the way the PIN is used during the o pinUsageMode indicates the way the PIN is used during the usage
usage of the key. The following values are defined in [PSKC]: of the key. The following values are defined in [RFC6030]:
Local, Prepend, Append, Algorithmic. Local, Prepend, Append, and Algorithmic.
o maxFailedAttempts indicates the maximum number of times the PIN o maxFailedAttempts indicates the maximum number of times the PIN may
may be entered wrongly before it MUST NOT be possible to use the be entered incorrectly before it MUST NOT be possible to use the
key anymore (reasonable values are in the positive integer range key anymore (reasonable values are in the positive integer range of
of at least 2 and no more than 10). at least 2 and no more than 10).
o minLength indicates the minimum length of a PIN that can be set to o minLength indicates the minimum length of a PIN that can be set to
protect the associated key. It MUST NOT be possible to set a PIN protect the associated key. It MUST NOT be possible to set a PIN
shorter than this value. If pinEncoding is 'DECIMAL', shorter than this value. If pinEncoding is 'DECIMAL',
'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number
digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this of digits/ characters. If pinEncoding is 'BASE64' or 'BINARY',
value indicates the number of bytes of the unencoded value. this value indicates the number of bytes of the unencoded value.
o maxLength indicates the maximum length of a PIN that can be set to o maxLength indicates the maximum length of a PIN that can be set to
protect this key. It MUST NOT be possible to set a PIN longer protect this key. It MUST NOT be possible to set a PIN longer than
than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL' or this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC' this value indicates the number of 'ALPHANUMERIC', this value indicates the number of
digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', digits/characters. If the pinEncoding is 'BASE64' or 'BINARY',
this value indicates the number of bytes of the unencoded value. this value indicates the number of bytes of the unencoded value.
o pinEncoding is based on Encoding, which is defined in Section o pinEncoding is based on Encoding, which is defined in Section
3.2.6, and specifies encoding of the PIN and MUST be one of the 3.2.7, and specifies encoding of the PIN and MUST be one of the
following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or
BINARY. BINARY.
If pinUsageMode is set to "Local" then the device MUST enforce the If pinUsageMode is set to "Local", then the device MUST enforce the
restriction indicated in maxFailedAttempts, minLength, maxLength and restriction indicated in maxFailedAttempts, minLength, maxLength, and
pinEncoding, otherwise it MUST be enforced on the server side. pinEncoding; otherwise, it MUST be enforced on the server side.
4. Key Encoding 4. Key Encoding
Two parties receiving the same key as an sKey OCTET STRING must make Two parties receiving the same key as an sKey OCTET STRING must make
use of the key in exactly the same way in order to interoperate. To use of the key in exactly the same way in order to interoperate. To
ensure that, it is necessary to define a correspondence between the ensure that this occurs, it is necessary to define a correspondence
abstract syntax of sKey and the notation in the standard algorithm between the abstract syntax of sKey and the notation in the standard
description that defines how the key is used. The next sections algorithm description that defines how the key is used. The next
establish that correspondence for the algorithms AES [FIPS197] and sections establish that correspondence for the AES algorithm
TDEA [SP800-67]. [FIPS197] and the Triple Data Encryption Algorithm (TDEA or Triple
DES) [SP800-67].
4.1. AES Key Encoding 4.1. AES Key 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 sKey SHALL an array of bytes indexed starting at 0. The first octet of sKey
become the key byte in AES labeled index 0 in [FIPS197]; the SHALL become the key byte in the AES, labeled index 0 in [FIPS197];
succeeding octets of sKey SHALL become key bytes in AES in increasing the succeeding octets of sKey SHALL become key bytes in AES, in
index order. increasing index order.
Proper parsing and key load of the contents of sKey for AES SHALL be Proper parsing and key load of the contents of sKey for AES SHALL be
determined by using the following sKey octet string to generate and determined by using the following sKey OCTET STRING to generate and
match the key expansion test vectors in [FIPS197] Appendix A for AES match the key expansion test vectors in [FIPS197], Appendix A, for
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c AES Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Tag Length Value Tag Length Value
04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
4.2. Triple DES Key Encoding 4.2. Triple-DES Key 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 sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB.
The second octet of sKey SHALL be bits 9 through 16 of Key1, and so The second octet of sKey SHALL be bits 9 through 16 of Key1, and so
forth, so that the trailing octet of sKEY SHALL be bits 57 through 64 forth, so that the trailing octet of sKey SHALL be bits 57 through 64
of Key3 (or Key2 for two-key Triple DES). of Key3 (or Key2 for two-key Triple DES).
Proper parsing and key load of the contents of sKey for Triple-DES Proper parsing and key load of the contents of sKey for Triple DES
SHALL be determined by using the following sKey octet string to SHALL be determined by using the following sKey OCTET STRING to
generate and match the key expansion test vectors in [SP800-67] generate and match the key expansion test vectors in [SP800-67],
appendix B for the key bundle: Appendix B, for the key bundle:
Key1 = 0123456789ABCDEF Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01 Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123 Key3 = 456789ABCDEF0123
Tag Length Value Tag Length Value
04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123
5. Security Considerations 5. Security Considerations
Implementers of this protocol are strongly encouraged to consider Implementers of this protocol are strongly encouraged to consider
generally accepted principles of secure key management when generally accepted principles of secure key management when
integrating this capability within an overall security architecture. integrating this capability within an overall security architecture.
The symmetric key package contents are not protected. This content The symmetric key package contents are not protected. This content
type can be combined with a security protocol to protect the contents type can be combined with a security protocol to protect the contents
of the package. One possibility is to include this content type in of the package. One possibility is to include this content type in
place of a PSKC package in [DSKPP] exchanges. In this case, the place of a PSKC package in [RFC6063] exchanges. In this case, the
algorithm requirements are found in those documents. Another algorithm requirements are found in those documents. Another
possibility is to encapsulate this content type in a CMS [RFC5652] possibility is to encapsulate this content type in a CMS [RFC5652]
protecting content type. protecting content type.
6. IANA Considerations 6. IANA Considerations
This document makes use of object identifiers to identify a CMS This document makes use of object identifiers to identify a CMS
content type (Appendix A.1), the ASN.1 version of the PSKC attributes content type (Appendix A.1), the ASN.1 version of the PSKC attributes
(Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2. (Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2.
All OIDs are registered in an arc delegated by RSADSI to the SMIME All OIDs are registered in an arc delegated by RSADSI to the SMIME
Working Group. The current contents of the arc are located here: Working Group.
http://www.imc.org/ietf-smime/sm-oid.asn
They were obtained by sending a request to
ietf-smime-oid-reg@imc.org. When the SMIME WG closes, this arc and
registration procedures will be transferred to IANA. No further
action by IANA is necessary for this document or any anticipated
updates.
7. References 7. References
7.1. Normative References 7.1. Normative References
[FIPS197] National Institute of Standards. "FIPS Pub 197: [FIPS197] National Institute of Standards. "FIPS Pub 197:
Advanced Encryption Standard (AES)", 26 November 2001. Advanced Encryption Standard (AES)", 26 November 2001.
[IANAPENREG] IANA, "IANA Private Enterprise Number Registry", [IANAPENREG] IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers/>. <http://www.iana.org>.
[LUHN] ISO/IEC 7812-1:2006 Identification cards - [ISOIEC7812] 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/
catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April
2009, <http://www.openauthentication.org/
oath-id/prefixes>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4049] Housley, R., "BinaryTime: An Alternate Format for [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Representing Date and Time in ASN.1", RFC 4049, April Protocol (LDAP): String Representation of Distinguished
2005. Names", RFC 4514, June 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 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 [RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for
Languages", BCP 47, RFC 5646, September 2009. Identifying Languages", BCP 47, RFC 5646, September
2009.
[RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC Cryptographic Message Syntax (CMS) and S/MIME", RFC
5911, June 2010. 5911, June 2010.
[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
5912, June 2010. June 2010.
[OATHMAN] OATH Manufacturer prefixes:
http://www.openauthentication.org/oath-id/prefixes/
[PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Key Container (PSKC), draft-ietf-keyprov-pskc-07.txt, Representing Date and Time in ASN.1", RFC 6019,
work-in-progress. September 2010.
//** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and Key Container (PSKC)", RFC 6030, October 2010.
elsewhere in the document. **//
[SP800-67] National Institute of Standards and Technology, "NIST [SP800-67] National Institute of Standards and Technology, "NIST
Special Publication 800-67 Version 1.1: Recommendation Special Publication 800-67 Version 1.1: Recommendation
for the Triple Data Encryption Algorithm (TDEA) Block for the Triple Data Encryption Algorithm (TDEA) Block
Cipher", NIST Special Publication 800-67, May 2008. Cipher", NIST Special Publication 800-67, May 2008.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1:2002. Information Technology - Abstract Syntax 1:2002. Information Technology - Abstract Syntax
Notation One. Notation One.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-
2:2002. Information Technology - Abstract Syntax 2:2002. Information Technology - Abstract Syntax
Notation One: Information Object Specification. Notation One: Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-
3:2002. Information Technology - Abstract Syntax 3:2002. Information Technology - Abstract Syntax
Notation One: Constraint Specification. Notation One: Constraint Specification.
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-
4:2002. Information Technology - Abstract Syntax 4:2002. Information Technology - Abstract Syntax
Notation One: Parameterization of ASN.1 Specifications. Notation One: Parameterization of ASN.1 Specifications.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
1:2002. Information Technology - ASN.1 encoding rules: 1:2002. Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER). (DER).
[XMLSCHEMA] Biron, P., and A. Malhotra, "XML Schema Part 2: [XMLSCHEMA] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Datatypes Second Edition", Second Edition", World Wide Web Consortium
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, Recommendation REC-xmlschema-2-20041082, October 2004,
2004. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
7.2. Informative References
[DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://www.ietf.org/internet-
drafts/draft-ietf-keyprov-dskpp-10.txt, work in
progress.
//** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 7.2. Informative References
the draft-ietf-keyprov-dskpp's RFC #. Make the replacements here and
elsewhere in the document. **//
[NIST800-57] National Institute of Standards and Technology, "NIST [NIST800-57] National Institute of Standards and Technology, "NIST
Special Publication 800-57, Recommendation for Key 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.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD
5652, September 2009. 70, RFC 5652, September 2009.
APPENDIX A: ASN.1 Module [RFC6063] Doherty, A., Pei, M., Machani, S., and M. Nystrom,
"Dynamic Symmetric Key Provisioning Protocol (DSKPP)",
RFC 6063, December 2010.
Appendix A. ASN.1 Module
This appendix provides the normative ASN.1 definitions for the This appendix provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in structures described in this specification using ASN.1 as defined in
[X.680], [X.681], [X.682], and [X.683]. [X.680], [X.681], [X.682], and [X.683].
A.1. Symmetric Key Package ASN.1 Module A.1. Symmetric Key Package ASN.1 Module
SymmetricKeyPackageModulev1 SymmetricKeyPackageModulev1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) } smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- EXPORTS ALL
skipping to change at page 23, line 20 skipping to change at page 22, line 48
smime(16) modules(0) id-mod-cms-2004-02(41) } smime(16) modules(0) id-mod-cms-2004-02(41) }
; ;
ContentSet CONTENT-TYPE ::= { ContentSet CONTENT-TYPE ::= {
ct-symmetric-key-package, ct-symmetric-key-package,
... -- Expect additional content types -- ... -- Expect additional content types --
} }
ct-symmetric-key-package CONTENT-TYPE ::= ct-symmetric-key-package CONTENT-TYPE ::=
{ SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } { TYPE SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage }
id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) ct(1) 25 } smime(16) ct(1) 25 }
SymmetricKeyPackage ::= SEQUENCE { SymmetricKeyPackage ::= SEQUENCE {
version KeyPkgVersion DEFAULT v1, version KeyPkgVersion DEFAULT v1,
sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute
{{ SKeyPkgAttributes }} OPTIONAL, {{ SKeyPkgAttributes }} OPTIONAL,
sKeys SymmetricKeys, sKeys SymmetricKeys,
skipping to change at page 24, line 5 skipping to change at page 23, line 29
WITH COMPONENTS { ..., sKey PRESENT } ) WITH COMPONENTS { ..., sKey PRESENT } )
KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... )
SKeyPkgAttributes ATTRIBUTE ::= { ... } SKeyPkgAttributes ATTRIBUTE ::= { ... }
SKeyAttributes ATTRIBUTE ::= { ... } SKeyAttributes ATTRIBUTE ::= { ... }
END END
A.2. PSKC ASN.1 Module A.2. PSKC ASN.1 Module
PSKCAttributesModule PSKCAttributesModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-pskcAttributesModule(53) } smime(16) modules(0) id-mod-pskcAttributesModule(53) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- EXPORTS ALL
skipping to change at page 24, line 27 skipping to change at page 24, line 5
IMPORTS IMPORTS
-- From New PKIX ASN.1 [RFC5912] -- From New PKIX ASN.1 [RFC5912]
ATTRIBUTE ATTRIBUTE
FROM PKIX-CommonTypes-2009 FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } id-mod-pkixCommon-02(57) }
-- From BinaryTime [RFC4049] -- From BinaryTime [RFC6019]
BinaryTime BinaryTime
FROM BinarySigningTimeModule FROM BinarySigningTimeModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-binarySigningTime(27) } smime(16) modules(0) id-mod-binarySigningTime(27) }
-- From New SMIME ASN.1 [RFC5911] -- From New SMIME ASN.1 [RFC5911]
id-smime id-smime
FROM SecureMimeMessageV3dot1-2009 FROM SecureMimeMessageV3dot1-2009
skipping to change at page 25, line 4 skipping to change at page 24, line 26
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-msg-v3dot1-02(39) } smime(16) modules(0) id-mod-msg-v3dot1-02(39) }
; ;
-- --
-- PSKC Attributes OIDs are taken from the SMIME Arc. -- PSKC Attributes OIDs are taken from the SMIME Arc.
-- --
id-pskc OBJECT IDENTIFIER ::= { id-smime 12 } id-pskc OBJECT IDENTIFIER ::= { id-smime 12 }
-- --
-- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs -- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs
-- --
SKeyPkgAttributes ATTRIBUTE ::= { SKeyPkgAttributes ATTRIBUTE ::= {
at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model | at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model |
at-pskc-issueNo | at-pskc-deviceBinding | at-pskc-issueNo | at-pskc-deviceBinding |
at-pskc-deviceStartDate | at-pskc-deviceExpiryDate | at-pskc-deviceStartDate | at-pskc-deviceExpiryDate |
at-pskc-moduleId | at-deviceUserId, ... } at-pskc-moduleId | at-pskc-deviceUserId, ... }
-- --
-- Merge SKeyAttributes to the set of attributes for sKeyAttrs -- Merge SKeyAttributes to the set of attributes for sKeyAttrs
-- --
SKeyAttributes ATTRIBUTE ::= { SKeyAttributes ATTRIBUTE ::= {
at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer | at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer |
at-pskc-keyProfileId | at-pskc-keyReference | at-pskc-keyProfileId | at-pskc-keyReference |
at-pskc-friendlyName | at-pskc-algorithmParameters | at-pskc-friendlyName | at-pskc-algorithmParameters |
at-pskc-counter | at-pskc-time | at-pskc-timeInterval | at-pskc-counter | at-pskc-time | at-pskc-timeInterval |
at-pskc-timeDrift | at-pskc-valueMAC | at-keyUserId | at-pskc-timeDrift | at-pskc-valueMAC | at-pskc-keyUserId |
at-pskc-keyStartDate | at-pskc-keyExpiryDate | at-pskc-keyStartDate | at-pskc-keyExpiryDate |
at-pskc-numberOfTransactions | at-pskc-keyUsage | at-pskc-numberOfTransactions | at-pskc-keyUsage |
at-pskc-pinPolicy,... } at-pskc-pinPolicy, ... }
at-pskc-manufacturer ATTRIBUTE ::= { at-pskc-manufacturer ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer }
id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 }
at-pskc-serialNo ATTRIBUTE ::= { at-pskc-serialNo ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } TYPE UTF8String IDENTIFIED BY id-pskc-serialNo }
id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 }
skipping to change at page 27, line 20 skipping to change at page 26, line 40
friendlyName UTF8String, friendlyName UTF8String,
friendlyNameLangTag UTF8String OPTIONAL } friendlyNameLangTag UTF8String OPTIONAL }
at-pskc-algorithmParameters ATTRIBUTE ::= { at-pskc-algorithmParameters ATTRIBUTE ::= {
TYPE PSKCAlgorithmParameters TYPE PSKCAlgorithmParameters
IDENTIFIED BY id-pskc-algorithmParameters } IDENTIFIED BY id-pskc-algorithmParameters }
id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 } id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 }
PSKCAlgorithmParameters ::= CHOICE { PSKCAlgorithmParameters ::= CHOICE {
suite UTF8String OPTIONAL, suite UTF8String,
challengeFormat [0] ChallengeFormat, challengeFormat [0] ChallengeFormat,
responseFormat [1] ResponseFormat, responseFormat [1] ResponseFormat,
... } ... }
ChallengeFormat ::= SEQUENCE { ChallengeFormat ::= SEQUENCE {
encoding Encoding, encoding Encoding,
checkDigit BOOLEAN DEFAULT FALSE, checkDigit BOOLEAN DEFAULT FALSE,
min INTEGER (0..MAX), min INTEGER (0..MAX),
max INTEGER (0..MAX), max INTEGER (0..MAX),
... } ... }
skipping to change at page 29, line 36 skipping to change at page 29, line 15
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
EMail: turners@ieca.com EMail: turners@ieca.com
Russ Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 181 change blocks. 
364 lines changed or deleted 339 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/