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