From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6031.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc6031.txt (limited to 'doc/rfc/rfc6031.txt') 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 type converts to UTF8String; the XML + 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."). When the value is taken from + [IANAPENREG], "iana." MUST be prepended to the value (e.g., + "iana."). 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", + . + + + + + +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, . + + [OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April + 2009, . + + [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, + . + +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] + -- cgit v1.2.3